more to the point, how does building nuke plants translate into less dependence on oil?
it's not that it can't happen, but it will require a lot more than just building lots of nuke plants. e.g. we'll need electric cars that can be recharged, or we'll need to use a lot of that electricity to produce hydrogen for hydrogen cars.
native at home and at work, 6to4 to tunnel between them. it was a great way to get around the exorbitant fees my ISP wanted to charge me to get more than a single static IPv4 address at home.
OSes (windows, mac, linux, *bsd, and most *ixen) have been shipping with IPv6 support for years.
most "real" (not SOHO) routers have IPv6 support, though upgrades may be needed to switch IPv6 in hardware.
apps are less of an issue than it might seem. the point of IPv6 is to enable new apps and new networks - to extend the capability of the net beyond what you can reasonably do with IPv4 and NAT. the well-established apps, and those that can work well with NATs, will be the last to move. so it doesn't make sense to watch web and email (for instance) for signs of early IPv6 adoption.
biggest pacing item these days for IPv6 adoption seems to be things like high-speed firewalls and intrusion detection systems.
Obviously I can't prove it to you. But I do consider being told personally by a person who was part of the decision making process to be reliable evidence.
Yes, willful negligence. I was an active participant in the IETF working group that wrote the MIME standard. Before MIME, Internet mail was only capable of sending plain ASCII text, MIME was adding the ability to send text in other character sets as well as attachments of arbitrary types. I was concerned about the security risks of sending around arbitrary attachments. Other working group participants actually doubted that such risks existed. So I wrote some exploits in three of the formats we thought people would use for attachments - TeX, troff, and PostScript - and sent them to the working group mailing list. The exploits didn't actually compromise the affected systems, but they demonstrated that such compromise was feasible.
As a result of my efforts, we got some rules put into the MIME standard. One was that mail readers should not by default display message contents without a reasonable belief that it was safe. Another was that a mail reader shouldn't let the author of a message specify what program would be used to display a particular attachment. Another was that new content-types had to have documented security considerations. Another was that objects using the generic content-type (application/octet-stream) should not be presented, the mail reader should just offer to save them. And since HTTP ended up using MIME's content-type system, those rules applied to the web also.
For many years, MS mail readers and web browsers violated all of those rules, and they continue to violate some of them today. They didn't bother registering content-types for their proprietary data formats or analyzing them for security risks. They didn't label attachments in outgoing mail with meaningful content-types, instead labeling everything as "application/octet-stream" even for contents clearly expected to be presented "inline" as part of the message - expecting the recipient to make sense of the filename suffix. On receipt, their mail readers would ignore the content-type and look at only the filename suffix, thus giving the author of a message the ability to send attachments to any application on the recipient's machine that had a filename suffix associated with it. Vendors of competing products more-or-less had to follow suit in order to make their products "usable" by those used to the MS behavior.
In 1996 I was having a discussion with the manager for Microsoft's Exchange product about this, and I said "you really need to fix these problems." He replied that these were deliberate design choices that MS made because they felt that such choices would give them a competitive advantage. When I asked him about the harm this would do to their customers' security, he replied that MS had decided it was worth the risk.
bingo. Microsoft's willful negligence in making their email readers and web browsers insecure has cost consumers hundreds of billions of dollars, and they're doing their best to cripple their customers computers in order to extort more money from them. They still manage to effectively impose a significant tax on the vast majority of computers sold, even if the consumer never uses Windows.
There seems to be something in American culture that causes many people here to reserve their greatest admiration for the politicians and companies that abuse them the most.
Microsoft has benefited from piracy ever since Micro-Soft [sic] Basic for the Altair 8800, when hobbyists gave copied paper tapes to one another. This proliferation helped establish Micro-Soft Basic as the standard for microcomputers. It was that market recognition that caused IBM to ask Bill Gates to develop an operating system for their 5150 Personal Computer.
Bill Gates may have b*tched about piracy in a letter he wrote to the Homebrew Computer Club in February 1976, but it has made him an extremely wealthy man.
So maybe what the OSS community needs is a media campaign: Don't steal proprietary software. Use free software instead.
The spaceport is located in Florida at least partially for two reasons: (1) the extreme easterly location means that launches in the direction of Earth's rotation are over water, reducing hazards for persons and property on the ground. (2) it's closer than most states on America's mainland to the equator, which makes for more efficient launches (more payload can be lifted into a given orbit).
SRV records only affect protocols that are defined to use SRV records. most protocols are not defined to use them, and most application codes therefore don't do SRV queries.
even if an application did an SRV query, though, a nonexistent domain wouldn't list any SRV records, and Earthlink's server would return "no such domain" in response to a SRV query. then the application would presumably fall back to querying for A records, and Earthlink's server would return the bogus A records.
(I checked just now, and Earthlink's servers don't appear to return bogus answers in response to queries for _http._tcp.xxx.yyy - they respond with NXDOMAIN even if they give answers for xxx.yyy)
Another thing occurs to me: Even if the client is a web browser, the result of Earthlink's faking the DNS response can be to worsen the user's experience, since the user's web browser might well provide a better handling of nonexistent domains than Earthlink's HTTP server. For instance, it might return quicker results, better matches, or results without ads.
The biggest problem with this is not the ads (though they are annoying). This DNS hack doesn't just affect HTTP, it affects every application that does DNS queries. The claim that the system is configured to only handle NXDOMAIN HTTP traffic is a bald lie. There is no way for the DNS server to determine whether a query is being done for HTTP or for some other protocol.
When an application queries DNS for A records (IPv4 addresses) for a particular domain, one of three things should happen: 1. if there are A records for that domain, they should be returned 2. if there are no A records for that domain but there are other records, "no information" should be returned 3. if there are no records of any type for that domain, "no such domain" (NXDOMAIN) should be returned
What Earthlink's servers appear to be doing is the following:
1. if there are real A records for that domain, they are returned 2. if there are no A records for that domain, return A records for several hosts that don't belong to that domain.
if the application tries to talk HTTP to port 80 on any of those hosts and supplies the Host: query request
(standard in HTTP 1.1) the HTTP server will do a search for the domain that appears in the Host: request
and return HTML that suggests other domains that appear to be similar to the one given in the Host: request.
however if the application tries to talk to other ports on that machine it will get "connection refused" or
it will time out.
(the behavior is actually a bit more complicated than that. the behavior seems to be dependent on the IP address from which the queries were made - so if you make the query to their servers from a host that isn't on Earthlink DSL you will apparently get normal results. the behavior also seems to be dependent on the domain being queried.)
There are several things wrong with this behavior:
1. It's not reporting the error correctly. Applications that do DNS queries quite reasonably expect NXDOMAIN
to be returned if the domain does not exist, and "no information" to be returned if there are no records of
the type they're looking for - not a list of apparently valid IP addresses pointing to hosts that have nothing
to do with that domain. Many applications behave differently depending on the error condition. "connection
refused" and "connection timed out" are often treated as temporary errors - the application assumes that the
remote server is rebooting or isn't reachable and tries again later. "no such domain" is more often treated
as a permanent error, or one that requires immediate user attention. So this Earthlink change can cause
applications other than web browsers to behave improperly, or to give misleading error messages.
For example: if an email server is trying to send mail to someone at a particular domain, it will first do
a query for MX records to determine if there are any mail servers assigned to that domain. If the MX query returns
no answers, it may then issue a separate query for A records. If this happens the Earthlink DNS server will return
bogus A records and the email server will try to send the mail to Earthlink's servers rather than bouncing the mail
like it should. When Earthlink's servers refuse the connection, the email server will treat the condition as a
temporary error and retry at intervals for several days. As a result, mail for nonexistent domains (say, bounced
spam) can clog up the email server's queues and slow things down.
2. It is hiding other records associated with that domain. Say an application will
Jan 1, 1983 (date of ARPAnet shutting down NCP traffic) is as good a date as any. It's not the first date that IP packets were exchanged between networks with different prefixes (thus forming an "inter"-network), but it probably does approximate when this began to be done on a routine operational basis rather than an experimental basis. The ARPAnet certainly formed the original core of what became the Internet, and the switch to IP allowed ARPAnet sites to include other computers from their LANs beyond those directly connected to IMPs. So while it actually took several months before most ARPAnet sites had their IP code up and running to provide similar functionality to what they had before, the switch to IP was actually a big jump in capability and flexibility of the network.
So let's see...ICANN is devoting valuable energy to deciding whether it should free up a tiny number of new domains. The domains will inevitably cost a lot of money. The only question is who gets it. If they released the domains under the normal first-come first-first serve policy they would be snapped up in microseconds by speculators and auctioned off, and the speculators would get the money. OTOH if ICANN tries to make the money itself, or split it with registries, then they subject themselves to charges of inappropriately lining their pockets and favoring wealthy commercial interests.
This will not do a thing for the net as a whole and will only make more trouble for ICANN.
All the small users like me who have Netgear or Linksys NAT routers have thereby a very significant measure of security.
Not clear. There are so many ways to compromise a Windows box that NAT is pretty much irrelevant. If you're not running Windows then the potential threats are greatly reduced anyway. And there are ongoing efforts to define ways by which apps can ask the NAT to forward traffic to them without explicit configuration.
Marketers love to promote the delusion that they can sell you a magic box that will provide security without harming your ability to run apps. Whether or not the box implements NAT, it's a delusion just the same.
The notion of a complete transition is fairly meaningless. We're going to be using IPv4 for the web, email, and dedicated appliances like printers that are hard to upgrade, almost indefinitely. However for those applications the limitations of IPv4 addressing aren't such a big deal as there are fairly acceptable workarounds. IPv6 enables many more hosts to participate in peer-to-peer interactions than before, and this opens up potential for many new kinds of protocols and networked applications.
As for deployment - Some large ISPs are already selling IPv6 access to commercial customers. Consumer ISPs will be the last to see IPv6 because consumers will be the last to understand why it is useful. But this isn't such a big problem either, as anyone with a static IPv4 address can use IPv6 right now using 6to4 or an IPv6 tunnel broker. Bottom line - if you want to use IPv6 with an application today, there's a way to do it using existing networks and services. What we're waiting for is new applications that make use of IPv6 to do things that they couldn't do with IPv4 (maybe because they couldn't access enough devices that way). I think we'll see IPv6 used to control traffic lights, monitor security cameras, etc. before we see it widely used to transport web and email.
I use IPv6 every day between home and work. It's what lets me have multiple individually addressible machines at home with a residential DSL connection. My work network now supports IPv6, but my home ISP doesn't. 6to4 solves the problem handily.
So that happens to be my web page, and basically it's just a place for me to vent - especially since I was never able to find a good way of giving feedback to Apple. It's not like I've examined each successive version of MacOS to see whether all of my earlier complaints were addressed. (feel free to inform me if they have, or to explain workarounds)
I still believe MacOS sucks far less than Windows, though I suppose that's damning with faint praise.
I agree with the idea that everyone should be able to use the Internet in his native language. And I have no problem with using IDNs - actually I was involved in the discussions that led to the standardization and tried to minimize the potential for IDNs to break existing applications. But this action by China was taken rather recklessly and apparently without regard for the likely consequences. Having multiple roots with inconsistent sets of TLDs will lead to interoperability problems, as will a reliance on MSIE plugins. And given China's history it's hard to imagine that they'll resist the temptation to try to use their DNS roots to further limit access and/or redirect traffic to sites of their own choosing (similar to what Verisign did with SiteFinder).
This is a dangerous precedent. If the official root servers don't start handling queries for the Chinese TLDs it will create headaches for operators and application writers and might even result in widespread international pressure to have ITU take over domain management (if you thought ICANN was bad, just wait!). If the official root servers do start handling queries for these TLDs it will encourage other countries to set up their own TLDs, with less drastic but still undesirable consequences for DNS performance worldwide.
now the legitimate root servers will be flooded with queries for these illegitimate top-level domains, as the names leak outside China, or people within China who attempt to use those names with software that hasn't been upgraded or configured to use the alternate root servers.
charter an aircraft big enough to put a large water tank inside, and swim in the tank while the aircraft is flying to Iceland and thence to North America.
If you actually check the references what you find is that Telecordia worked with VeriSign to test ENUM. Telecordia and VeriSign didn't develop ENUM - that was done by an IETF working group in which anyone could participate.
I don't personally think that VeriSign has served as a responsible steward of.COM and.NET (or of the root) and I don't think they should get to keep.NET. But I don't see anything wrong with VeriSign helping to test ENUM.
Reading the patent claims this doesn't look so much like IPv6 (and certainly not a fundemental part of IPv6 - it resembles IPv6 stateless address autoconfiguration, but only vaguely).
What it looks like is IPv4 linklocal addressing, which has shipped in both MacOS and Windows for several years, and is a draft that is either just about to be approved or has already been approved as a standard. See
draft-ietf-zeroconf-ipv4-linklocal-17.txt
The really unfortunate thing is that linklocal addresses are quite useful on isolated networks, but are really harmful to applications unless they're turned off when a computer has a "real" address assigned by manual configuration or DHCP. And from a quick reading the patent would appear to apply to any implementation that turns off linklocal addresses under such conditions.
I've generally said I'd consider using DRM when the DRM system worked as hard to ensure that the rights of consumers and the public were maintained (including the various rights associated with fair use, to make backup copies, for a fixed copy of the work to be sold, for libraries to lend the work, and to use the work after the term of the copyright expired) as it did to ensure that the rights of the content creators and owners were maintained. And the DRM system has to accomplish this without an invasion of the users' privacy...for instance, it's absolutely unacceptable to give either the content owner or the government the ability to track who reads a particular ebook.
I've yet to see a DRM system that comes close to meeting those goals.
I also think it's extremely valuable to society that it is possible to get away with small amounts of copyright violation without punishment - think of how things would be if every photocopier would only copy non-copyrighted material or if you had to get permission from the owner of a work before making even a few photocopies. To be reasonable, DRM needs to permit some amount of casual copying without making it traceable, even if it violates current copyright law.
...to spend much time doing things you resent or despise. When you are nearing the end of your life and you look back, do you want to say that you led a financially secure life, or do you want to say that you spent your time on earth productively and enjoyably? Now sometimes you do need to keep working while you look for something new - especially if you have big debts or kids to feed. Whether you quit then look, or look then quit, depends on your situation and the kind of personality you have. But once it's obvious that the job isn't spending your energy in a way that your soul can agree to, start moving away from it and don't look back.
Slashdot Mirror
more to the point, how does building nuke plants translate into less dependence on oil?
it's not that it can't happen, but it will require a lot more than just building lots of nuke plants. e.g. we'll need electric cars that can be recharged, or we'll need to use a lot of that electricity to produce hydrogen for hydrogen cars.
native at home and at work, 6to4 to tunnel between them. it was a great way to get around the exorbitant fees my ISP wanted to charge me to get more than a single static IPv4 address at home.
OSes (windows, mac, linux, *bsd, and most *ixen) have been shipping with IPv6 support for years.
most "real" (not SOHO) routers have IPv6 support, though upgrades may be needed to switch IPv6 in hardware.
apps are less of an issue than it might seem. the point of IPv6 is to enable new apps and new networks - to extend the capability of the net beyond what you can reasonably do with IPv4 and NAT. the well-established apps, and those that can work well with NATs, will be the last to move. so it doesn't make sense to watch web and email (for instance) for signs of early IPv6 adoption.
biggest pacing item these days for IPv6 adoption seems to be things like high-speed firewalls and intrusion detection systems.
Obviously I can't prove it to you. But I do consider being told personally by a person who was part of the decision making process to be reliable evidence.
Yes, willful negligence. I was an active participant in the IETF working group that wrote the MIME standard. Before MIME, Internet mail was only capable of sending plain ASCII text, MIME was adding the ability to send text in other character sets as well as attachments of arbitrary types. I was concerned about the security risks of sending around arbitrary attachments. Other working group participants actually doubted that such risks existed. So I wrote some exploits in three of the formats we thought people would use for attachments - TeX, troff, and PostScript - and sent them to the working group mailing list. The exploits didn't actually compromise the affected systems, but they demonstrated that such compromise was feasible.
As a result of my efforts, we got some rules put into the MIME standard. One was that mail readers should not by default display message contents without a reasonable belief that it was safe. Another was that a mail reader shouldn't let the author of a message specify what program would be used to display a particular attachment. Another was that new content-types had to have documented security considerations. Another was that objects using the generic content-type (application/octet-stream) should not be presented, the mail reader should just offer to save them. And since HTTP ended up using MIME's content-type system, those rules applied to the web also.
For many years, MS mail readers and web browsers violated all of those rules, and they continue to violate some of them today. They didn't bother registering content-types for their proprietary data formats or analyzing them for security risks. They didn't label attachments in outgoing mail with meaningful content-types, instead labeling everything as "application/octet-stream" even for contents clearly expected to be presented "inline" as part of the message - expecting the recipient to make sense of the filename suffix. On receipt, their mail readers would ignore the content-type and look at only the filename suffix, thus giving the author of a message the ability to send attachments to any application on the recipient's machine that had a filename suffix associated with it. Vendors of competing products more-or-less had to follow suit in order to make their products "usable" by those used to the MS behavior.
In 1996 I was having a discussion with the manager for Microsoft's Exchange product about this, and I said "you really need to fix these problems." He replied that these were deliberate design choices that MS made because they felt that such choices would give them a competitive advantage. When I asked him about the harm this would do to their customers' security, he replied that MS had decided it was worth the risk.
So yeah, they're culpable.
bingo. Microsoft's willful negligence in making their email readers and web browsers insecure has cost consumers hundreds of billions of dollars, and they're doing their best to cripple their customers computers in order to extort more money from them. They still manage to effectively impose a significant tax on the vast majority of computers sold, even if the consumer never uses Windows.
There seems to be something in American culture that causes many people here to reserve their greatest admiration for the politicians and companies that abuse them the most.
Microsoft has benefited from piracy ever since Micro-Soft [sic] Basic for the Altair 8800, when hobbyists gave copied paper tapes to one another. This proliferation helped establish Micro-Soft Basic as the standard for microcomputers. It was that market recognition that caused IBM to ask Bill Gates to develop an operating system for their 5150 Personal Computer.
Bill Gates may have b*tched about piracy in a letter he wrote to the Homebrew Computer Club in February 1976, but it has made him an extremely wealthy man.
So maybe what the OSS community needs is a media campaign: Don't steal proprietary software. Use free software instead.
for news about something like the shuttle, where the status changes from day to day,d ex.html
it really pays to check a primary source. like
http://www.nasa.gov/mission_pages/shuttle/main/in
The spaceport is located in Florida at least partially for two reasons: (1) the extreme easterly location means that launches in the direction of Earth's rotation are over water, reducing hazards for persons and property on the ground. (2) it's closer than most states on America's mainland to the equator, which makes for more efficient launches (more payload can be lifted into a given orbit).
for lots of reasons stated in other posts. the ads are the least of the problems with this hack.
SRV records only affect protocols that are defined to use SRV records. most protocols are not defined to use them, and most application codes therefore don't do SRV queries.
even if an application did an SRV query, though, a nonexistent domain wouldn't list any SRV records, and Earthlink's server would return "no such domain" in response to a SRV query. then the application would presumably fall back to querying for A records, and Earthlink's server would return the bogus A records.
(I checked just now, and Earthlink's servers don't appear to return bogus answers in response to queries for _http._tcp.xxx.yyy - they respond with NXDOMAIN even if they give answers for xxx.yyy)
Another thing occurs to me: Even if the client is a web browser, the result of Earthlink's faking the DNS response can be to worsen the user's experience, since the user's web browser might well provide a better handling of nonexistent domains than Earthlink's HTTP server. For instance, it might return quicker results, better matches, or results without ads.
The biggest problem with this is not the ads (though they are annoying). This DNS hack doesn't just affect HTTP, it affects every application that does DNS queries. The claim that the system is configured to only handle NXDOMAIN HTTP traffic is a bald lie. There is no way for the DNS server to determine whether a query is being done for HTTP or for some other protocol.
When an application queries DNS for A records (IPv4 addresses) for a particular domain, one of three things should happen:
1. if there are A records for that domain, they should be returned
2. if there are no A records for that domain but there are other records, "no information" should be returned
3. if there are no records of any type for that domain, "no such domain" (NXDOMAIN) should be returned
What Earthlink's servers appear to be doing is the following:
1. if there are real A records for that domain, they are returned
2. if there are no A records for that domain, return A records for several hosts that don't belong to that domain.
if the application tries to talk HTTP to port 80 on any of those hosts and supplies the Host: query request
(standard in HTTP 1.1) the HTTP server will do a search for the domain that appears in the Host: request
and return HTML that suggests other domains that appear to be similar to the one given in the Host: request.
however if the application tries to talk to other ports on that machine it will get "connection refused" or
it will time out.
(the behavior is actually a bit more complicated than that. the behavior seems to be dependent on the IP address from
which the queries were made - so if you make the query to their servers from a host that isn't on Earthlink DSL
you will apparently get normal results. the behavior also seems to be dependent on the domain being queried.)
There are several things wrong with this behavior:
1. It's not reporting the error correctly. Applications that do DNS queries quite reasonably expect NXDOMAIN
to be returned if the domain does not exist, and "no information" to be returned if there are no records of
the type they're looking for - not a list of apparently valid IP addresses pointing to hosts that have nothing
to do with that domain. Many applications behave differently depending on the error condition. "connection
refused" and "connection timed out" are often treated as temporary errors - the application assumes that the
remote server is rebooting or isn't reachable and tries again later. "no such domain" is more often treated
as a permanent error, or one that requires immediate user attention. So this Earthlink change can cause
applications other than web browsers to behave improperly, or to give misleading error messages.
For example: if an email server is trying to send mail to someone at a particular domain, it will first do
a query for MX records to determine if there are any mail servers assigned to that domain. If the MX query returns
no answers, it may then issue a separate query for A records. If this happens the Earthlink DNS server will return
bogus A records and the email server will try to send the mail to Earthlink's servers rather than bouncing the mail
like it should. When Earthlink's servers refuse the connection, the email server will treat the condition as a
temporary error and retry at intervals for several days. As a result, mail for nonexistent domains (say, bounced
spam) can clog up the email server's queues and slow things down.
2. It is hiding other records associated with that domain. Say an application will
Jan 1, 1983 (date of ARPAnet shutting down NCP traffic) is as good a date as any. It's not the first date that IP packets were exchanged between networks with different prefixes (thus forming an "inter"-network), but it probably does approximate when this began to be done on a routine operational basis rather than an experimental basis. The ARPAnet certainly formed the original core of what became the Internet, and the switch to IP allowed ARPAnet sites to include other computers from their LANs beyond those directly connected to IMPs. So while it actually took several months before most ARPAnet sites had their IP code up and running to provide similar functionality to what they had before, the switch to IP was actually a big jump in capability and flexibility of the network.
So let's see...ICANN is devoting valuable energy to deciding whether it should free up a tiny number of new domains. The domains will inevitably cost a lot of money. The only question is who gets it. If they released the domains under the normal first-come first-first serve policy they would be snapped up in microseconds by speculators and auctioned off, and the speculators would get the money. OTOH if ICANN tries to make the money itself, or split it with registries, then they subject themselves to charges of inappropriately lining their pockets and favoring wealthy commercial interests.
This will not do a thing for the net as a whole and will only make more trouble for ICANN.
All the small users like me who have Netgear or Linksys NAT routers have thereby a very significant measure of security.
Not clear. There are so many ways to compromise a Windows box that NAT is pretty much irrelevant. If you're not running Windows then the potential threats are greatly reduced anyway. And there are ongoing efforts to define ways by which apps can ask the NAT to forward traffic to them without explicit configuration.
Marketers love to promote the delusion that they can sell you a magic box that will provide security without harming your ability to run apps. Whether or not the box implements NAT, it's a delusion just the same.
The notion of a complete transition is fairly meaningless. We're going to be using IPv4 for the web, email, and dedicated appliances like printers that are hard to upgrade, almost indefinitely. However for those applications the limitations of IPv4 addressing aren't such a big deal as there are fairly acceptable workarounds. IPv6 enables many more hosts to participate in peer-to-peer interactions than before, and this opens up potential for many new kinds of protocols and networked applications.
As for deployment - Some large ISPs are already selling IPv6 access to commercial customers. Consumer ISPs will be the last to see IPv6 because consumers will be the last to understand why it is useful. But this isn't such a big problem either, as anyone with a static IPv4 address can use IPv6 right now using 6to4 or an IPv6 tunnel broker. Bottom line - if you want to use IPv6 with an application today, there's a way to do it using existing networks and services. What we're waiting for is new applications that make use of IPv6 to do things that they couldn't do with IPv4 (maybe because they couldn't access enough devices that way). I think we'll see IPv6 used to control traffic lights, monitor security cameras, etc. before we see it widely used to transport web and email.
I use IPv6 every day between home and work. It's what lets me have multiple individually addressible machines at home with a residential DSL connection. My work network now supports IPv6, but my home ISP doesn't. 6to4 solves the problem handily.
So that happens to be my web page, and basically it's just a place for me to vent - especially since I was never able to find a good way of giving feedback to Apple. It's not like I've examined each successive version of MacOS to see whether all of my earlier complaints were addressed. (feel free to inform me if they have, or to explain workarounds)
I still believe MacOS sucks far less than Windows, though I suppose that's damning with faint praise.
I agree with the idea that everyone should be able to use the Internet in his native language. And I have no problem with using IDNs - actually I was involved in the discussions that led to the standardization and tried to minimize the potential for IDNs to break existing applications. But this action by China was taken rather recklessly and apparently without regard for the likely consequences. Having multiple roots with inconsistent sets of TLDs will lead to interoperability problems, as will a reliance on MSIE plugins. And given China's history it's hard to imagine that they'll resist the temptation to try to use their DNS roots to further limit access and/or redirect traffic to sites of their own choosing (similar to what Verisign did with SiteFinder).
This is a dangerous precedent. If the official root servers don't start handling queries for the Chinese TLDs it will create headaches for operators and application writers and might even result in widespread international pressure to have ITU take over domain management (if you thought ICANN was bad, just wait!). If the official root servers do start handling queries for these TLDs it will encourage other countries to set up their own TLDs, with less drastic but still undesirable consequences for DNS performance worldwide.
now the legitimate root servers will be flooded with queries for these illegitimate top-level domains, as the names leak outside China, or people within China who attempt to use those names with software that hasn't been upgraded or configured to use the alternate root servers.
charter an aircraft big enough to put a large water tank inside, and swim in the tank while the aircraft is flying to Iceland and thence to North America.
nice PR stunt!
If you actually check the references what you find is that Telecordia worked with VeriSign to test ENUM. Telecordia and VeriSign didn't develop ENUM - that was done by an IETF working group in which anyone could participate.
.COM and .NET (or of the root) and I don't think they should get to keep .NET. But I don't see anything wrong with VeriSign helping to test ENUM.
I don't personally think that VeriSign has served as a responsible steward of
It took awhile to find it, but this turned up under IETF's IPR disclosures page: http://www.ietf.org/ietf/IPR/MICROSOFT-499.txt
Reading the patent claims this doesn't look so much like IPv6 (and certainly not a fundemental part of IPv6 - it resembles IPv6 stateless address autoconfiguration, but only vaguely). What it looks like is IPv4 linklocal addressing, which has shipped in both MacOS and Windows for several years, and is a draft that is either just about to be approved or has already been approved as a standard. See draft-ietf-zeroconf-ipv4-linklocal-17.txt The really unfortunate thing is that linklocal addresses are quite useful on isolated networks, but are really harmful to applications unless they're turned off when a computer has a "real" address assigned by manual configuration or DHCP. And from a quick reading the patent would appear to apply to any implementation that turns off linklocal addresses under such conditions.
I've generally said I'd consider using DRM when the DRM system worked as hard to ensure that the rights of consumers and the public were maintained (including the various rights associated with fair use, to make backup copies, for a fixed copy of the work to be sold, for libraries to lend the work, and to use the work after the term of the copyright expired) as it did to ensure that the rights of the content creators and owners were maintained. And the DRM system has to accomplish this without an invasion of the users' privacy...for instance, it's absolutely unacceptable to give either the content owner or the government the ability to track who reads a particular ebook.
I've yet to see a DRM system that comes close to meeting those goals.
I also think it's extremely valuable to society that it is possible to get away with small amounts of copyright violation without punishment - think of how things would be if every photocopier would only copy non-copyrighted material or if you had to get permission from the owner of a work before making even a few photocopies. To be reasonable, DRM needs to permit some amount of casual copying without making it traceable, even if it violates current copyright law.
...to spend much time doing things you resent or despise. When you are nearing the end of your life and you look back, do you want to say that you led a financially secure life, or do you want to say that you spent your time on earth productively and enjoyably? Now sometimes you do need to keep working while you look for something new - especially if you have big debts or kids to feed. Whether you quit then look, or look then quit, depends on your situation and the kind of personality you have. But once it's obvious that the job isn't spending your energy in a way that your soul can agree to, start moving away from it and don't look back.