I met Jef and Aza in Sweden last year at the EuroPython conference where he was talking about Archy, an editor with a more humane interface that they were working on. It was a pleasure to speak with him about computers, music and other things. My condolences go out to his family.
That's interesting. I studied Music Composition and received a degree in it and yet I am a professional programmer with a family and I am very happy. I work on open source software on a regular basis but I also am employed full-time as a software developer.
What's the point of all of this? I don't know. I do know that you should enjoy your life and do what you love and you will be happy.
In that case, why not just use Python? The point is that each language is designed to be used for certain tasks, and although you can use most of these languages to accomplish the same set of tasks some languages are better than others when it comes to certain tasks.
One other thing: this environment is not really a new scripting language, rather it exposes native components to the JavaScript language. The JavaScript language has been around for some time now and is used in more than just browsers (think server-side JavaScript).
The term is "settle on audit" and the acronym, obviously, SOA
Or, "Screwed on Arrival".
Thanks for the insight. As someone who once dealt with record companies as an artist (on a small level at least) I have always known that they are slimy.
Its too bad that things like CARP will destroy the possibility of using the web for alternative distribution channels of "indie" music. I feel like our rights are under attack from so many different angles nowadays that I don't even know how to respond.. * sigh *
Obviously you would only charge the winner of the lottery in my example;.biz was charging everybody just for a chance in the lottery.
True.
The separation of NSI the Registry from NSI the Registrar occurred in December of 1999, so it has actually been over two years now. I am not sure of the exact date when Verisign aquired NSI but it doesn't matter since the people and policies at the Registry have not changed since the beginning.
Whether or not Verisign GRS and Verisign the Registry are isolated from each other is hard to tell. Unfortunately the only ones who really know that are some of the employees at Verisign. It would be interesting to see the results of an audit by either ICANN or even better the Department of Commerce, but I don't think that will happen any time soon.
You don't have to believe it even if it is the truth. If Verisign the Registry were to continue trying to throw money at the problem to resolve it in a technical fashion without increasing the wholesale registration price then they probably would go the way of Enron. However I highly doubt that is going to happen - the domain name system will remain prevalent for at least a few more years and Verisign the Registry already has a good track record for handling domain registrations from over 100 registrars as well as maintaining the master DNS records.
I can't stress this enough that I am talking about Verisign the Registry and not the Registrar. Two entirely different beasts.
I will agree that waiting a year or two before releasing names to the public is a problem - but it is Verisign the Registrar's problem, not the Registry.
The load is coming from the registrars querying the database and as you stated this is the most important issue. Your mailing list suggestion would probably not go over well because of latency for email delivery. The "ticker app" concept might work - each registrar could attach themselves to a server which broadcasts drops as they occur. This would have to be used in conjunction with some sort of policy for limiting traffic for all registrars so that registrars wouldn't be able to just ignore the broadcast and continue hitting the registry nonstop.
As for the concert ticket idea - well I don't think that would fly especially after the dot biz fiasco.
While the actual drop time of a particular domain name is not known, the general drop time is known. Are are suggesting that the exact drop time of a particular name should be published? This is rather difficult because the deletion of a name from the registry is dependant on each registrar. Thus the registrar would have to delete a name and then the registry would have to hold that name while they determine an exact drop time, publish that drop time and then finally drop the name. I believe that there are others who have suggested this as well to Verisign GRS but I don't think it would alleviate the problem - registrars would still whack the registry in that second because the even milliseconds make a difference between getting a dropped name and failing.
If Verisign GRS can't handle the load given the current delete process (where the deletion time is a well known value) then how do you think they would be able to handle random drops 24/7? They can't IP ban anyone because their agreement with the ICANN forbids them from selectively denying access to a registrar. It helps to understand the number of requests as well - it is very easy for a registrar to generate thousands of checks per second! The registrars would not agree to a system which limits to a few checks per minute.
As for notification of renewals as well as actual deletion of domain names, it is up to each registrar to handle that. Thus if you choose a subpar registrar which doesn't notify you or doesn't protect your intellectual property (your domain names) then you are to blame. Consumer beware.
This whole discussion should make one thing clear: choose a registrar you can trust and if they ever break that trust then transfer your name BEFORE it expires.
I do not have exact amounts but I can tell you that they were dedicating multiple machines just for the deletion process. While I cannot be sure, I believe that they took machines away from the normal registration system (which operates at a fairly stable transaction rate) to support the deletion process.
They have also limited both number of allowed connections per registrar as well as allowed bandwidth when accessing these machines. These actions helped for a while but utilization is now back up to near 100% on a regular basis and they have had to put new limits in. In order to keep the system running they cannot continue like this indefinately...unless you would like them to raise normal registration fees to support it.
No, it just means that you need to register through a Registrar which can be trusted to not delete your name without getting explicit permission. The burden will always be upon your (the registrant's) shoulders but a good registrar will offer facilities to make protecting your name easier.
Actually this is how the current system works, if you can even say it works. The problem is that this system is proving to be too expensive on the Registry side of things - they cannot handle the load (which is similar to a denial of service attack) and cannot afford to augment their systems merely to handle domain deletions.
Verisign the Registry has tried to cope with this situation. They have been working for the past 6 months to try to find a reasonable solution which provides equal access to all registrars. Unfortunately they have not been able to do that using purely technical means.
The agreement with the Department of Commerce states "NSI shall take all reasonable steps to ensure the continued operation, functionality, and accessibility of the Shared Registration System." Appearently this is the next reasonable step.
As I stated in my previous post there proposal may not be the best solution. However I think it is unfair to compare what they are doing with what occurred at that other registry.
I would like to offer a bit of perspective on why Verisign is doing this. First it is important to note that it is Verisign GRS (the registry) which is considering this and not Network Solutions (the Verisign Registrar). Currently when a name expires it is up to each registrar to determine what happens to that name. When a domain expires it is actually automatically renewed by the registry. It is then up to the registrar to decide if the name should be deleted permanently. The registrar has up to 45 days to make that decision before the 1 year renewal fee is permanent.
Now, Verisign the Registrar releases a lot of domains to the public right now after a certain period of time. At this time the names are released and numerous registrars attempt to snag those names when they are dropped. This practice has caused headaches to no end at Verisign the Registry. It essentially acts as a denial of service attack as all the different registrars pound the registry trying to snatch those dropped names. Were talking hundreds of thousands of queries every minute.
This new propsed system is a response to this situation. It is designed to end the constant pounding of the registry. Granted it may not be the best solution but it is only the first draft and it must be okayed by ICANN first, thus there is a strong possibility that it will not be implemented. However something is needed in order to make the domain deletion process less system intensive as the registry cannot continue to support the amount of traffic caused by these domains dropping.
If I could mod your comment as a Troll I would. You state "Face the truth, java is a cripled language for lots of reasons" without giving any details to back that statement up.
Why is Java crippled? Because it has a feature-rich cross-platform standard API? Because it has built in multi-threading? Because it makes writing network code a snap? Because Sun actively supports it and listens to developer requests through the Java Community Process? Because it has modern JIT compilers and HotSpot which makes its runtime speed more then acceptable? Because it has a large number of useful APIs provided by open source developers such as myself?
I probably should qualify my original statement by saying that no "new" 2 letter second level domains will be allowed. Of course that is just a guess based on previous TLDs.
You like reading Slashdot, right? Slashdot could be written in Java using JSP for page generation. This is the type of dynamic content that the author is referring to.
I REALLY wish people would stop immediately associating Java with eye-candy applets. This is, IMHO, the weakest use for Java.
As a server side language Java is extremely powerful, primarily due to the huge number of APIs available but also due to the basic design of the language and the core API. Java also promotes code reuse better than any mainstream language out there (once again this is my opinion).
If you don't like Java as a server side language then don't use it. But please, stop saying Java == applets or JavaScript and using that as a reason to trash the Java platform.
You should definately transfer before the current registration expires. If you transfer you will not lose the time between now and the expiration date as domain years are now added on from the expiration date, not the date of renewal.
To answer number (3): There are individuals out there who are less than honest. They will sell a domain to someone, then go back to the registrar and say that the name was stolen. What is the registrar supposed to do at this point? Without any record the registrar must make an uninformed decision which usually favors the original owner and then the supposed new owner loses their money or must open a lawsuit which, given the cross-border issues, is surely not an easy task.
The whole concept of domain ownership is still murky, especially since different registrars have different policies about who the owner is (i.e. Register.com believes it is the administrative contact!)
If the author is only worried about database access time, then he was not clear enough in his original post. Regardless, most large sites like Amazon ARE replicating their databases (even to the point of placing DB servers at different geographical locations, along with server farms.) While this is expensive, it is necessary for any high, high volume site.
One of the most common ways to scale your site is to add hardware load balancing and multiple cheap servers running exact copies of your web site. This is how I have built my company's site.
We use a Cisco Local Director to load balance as many Linux servers as we like. It is very easy to insert and remove servers in a configuration like ours. Most large company's (such as Amazon or Yahoo!) will use multiple systems like this.
As for adding on new features, I would say that an iterative process is best. Once again, most large sites will have hundreds of developers working on different features which they will roll out one by one.
Slashdot Mirror
I met Jef and Aza in Sweden last year at the EuroPython conference where he was talking about Archy, an editor with a more humane interface that they were working on. It was a pleasure to speak with him about computers, music and other things. My condolences go out to his family.
He said "the big knob" not "a big knob". Don't get your hopes up. ;-)
That's interesting. I studied Music Composition and received a degree in it and yet I am a professional programmer with a family and I am very happy. I work on open source software on a regular basis but I also am employed full-time as a software developer.
What's the point of all of this? I don't know. I do know that you should enjoy your life and do what you love and you will be happy.
Repeat after me: JavaScript is not Java.
I curse the day that Netscape coined the term JavaScript.
In that case, why not just use Python? The point is that each language is designed to be used for certain tasks, and although you can use most of these languages to accomplish the same set of tasks some languages are better than others when it comes to certain tasks.
One other thing: this environment is not really a new scripting language, rather it exposes native components to the JavaScript language. The JavaScript language has been around for some time now and is used in more than just browsers (think server-side JavaScript).
Or, "Screwed on Arrival".
Thanks for the insight. As someone who once dealt with record companies as an artist (on a small level at least) I have always known that they are slimy.
Its too bad that things like CARP will destroy the possibility of using the web for alternative distribution channels of "indie" music. I feel like our rights are under attack from so many different angles nowadays that I don't even know how to respond.. * sigh *
True.
The separation of NSI the Registry from NSI the Registrar occurred in December of 1999, so it has actually been over two years now. I am not sure of the exact date when Verisign aquired NSI but it doesn't matter since the people and policies at the Registry have not changed since the beginning.
Whether or not Verisign GRS and Verisign the Registry are isolated from each other is hard to tell. Unfortunately the only ones who really know that are some of the employees at Verisign. It would be interesting to see the results of an audit by either ICANN or even better the Department of Commerce, but I don't think that will happen any time soon.
You don't have to believe it even if it is the truth. If Verisign the Registry were to continue trying to throw money at the problem to resolve it in a technical fashion without increasing the wholesale registration price then they probably would go the way of Enron. However I highly doubt that is going to happen - the domain name system will remain prevalent for at least a few more years and Verisign the Registry already has a good track record for handling domain registrations from over 100 registrars as well as maintaining the master DNS records.
I can't stress this enough that I am talking about Verisign the Registry and not the Registrar. Two entirely different beasts.
I will agree that waiting a year or two before releasing names to the public is a problem - but it is Verisign the Registrar's problem, not the Registry.
The load is coming from the registrars querying the database and as you stated this is the most important issue. Your mailing list suggestion would probably not go over well because of latency for email delivery. The "ticker app" concept might work - each registrar could attach themselves to a server which broadcasts drops as they occur. This would have to be used in conjunction with some sort of policy for limiting traffic for all registrars so that registrars wouldn't be able to just ignore the broadcast and continue hitting the registry nonstop.
As for the concert ticket idea - well I don't think that would fly especially after the dot biz fiasco.
While the actual drop time of a particular domain name is not known, the general drop time is known. Are are suggesting that the exact drop time of a particular name should be published? This is rather difficult because the deletion of a name from the registry is dependant on each registrar. Thus the registrar would have to delete a name and then the registry would have to hold that name while they determine an exact drop time, publish that drop time and then finally drop the name. I believe that there are others who have suggested this as well to Verisign GRS but I don't think it would alleviate the problem - registrars would still whack the registry in that second because the even milliseconds make a difference between getting a dropped name and failing.
If Verisign GRS can't handle the load given the current delete process (where the deletion time is a well known value) then how do you think they would be able to handle random drops 24/7? They can't IP ban anyone because their agreement with the ICANN forbids them from selectively denying access to a registrar. It helps to understand the number of requests as well - it is very easy for a registrar to generate thousands of checks per second! The registrars would not agree to a system which limits to a few checks per minute.
As for notification of renewals as well as actual deletion of domain names, it is up to each registrar to handle that. Thus if you choose a subpar registrar which doesn't notify you or doesn't protect your intellectual property (your domain names) then you are to blame. Consumer beware.
This whole discussion should make one thing clear: choose a registrar you can trust and if they ever break that trust then transfer your name BEFORE it expires.
I do not have exact amounts but I can tell you that they were dedicating multiple machines just for the deletion process. While I cannot be sure, I believe that they took machines away from the normal registration system (which operates at a fairly stable transaction rate) to support the deletion process.
They have also limited both number of allowed connections per registrar as well as allowed bandwidth when accessing these machines. These actions helped for a while but utilization is now back up to near 100% on a regular basis and they have had to put new limits in. In order to keep the system running they cannot continue like this indefinately...unless you would like them to raise normal registration fees to support it.
No, it just means that you need to register through a Registrar which can be trusted to not delete your name without getting explicit permission. The burden will always be upon your (the registrant's) shoulders but a good registrar will offer facilities to make protecting your name easier.
Actually this is how the current system works, if you can even say it works. The problem is that this system is proving to be too expensive on the Registry side of things - they cannot handle the load (which is similar to a denial of service attack) and cannot afford to augment their systems merely to handle domain deletions.
Verisign the Registry has tried to cope with this situation. They have been working for the past 6 months to try to find a reasonable solution which provides equal access to all registrars. Unfortunately they have not been able to do that using purely technical means.
The agreement with the Department of Commerce states "NSI shall take all reasonable steps to ensure the continued operation, functionality, and accessibility of the Shared Registration System." Appearently this is the next reasonable step.
As I stated in my previous post there proposal may not be the best solution. However I think it is unfair to compare what they are doing with what occurred at that other registry.
I would like to offer a bit of perspective on why Verisign is doing this. First it is important to note that it is Verisign GRS (the registry) which is considering this and not Network Solutions (the Verisign Registrar). Currently when a name expires it is up to each registrar to determine what happens to that name. When a domain expires it is actually automatically renewed by the registry. It is then up to the registrar to decide if the name should be deleted permanently. The registrar has up to 45 days to make that decision before the 1 year renewal fee is permanent.
Now, Verisign the Registrar releases a lot of domains to the public right now after a certain period of time. At this time the names are released and numerous registrars attempt to snag those names when they are dropped. This practice has caused headaches to no end at Verisign the Registry. It essentially acts as a denial of service attack as all the different registrars pound the registry trying to snatch those dropped names. Were talking hundreds of thousands of queries every minute.
This new propsed system is a response to this situation. It is designed to end the constant pounding of the registry. Granted it may not be the best solution but it is only the first draft and it must be okayed by ICANN first, thus there is a strong possibility that it will not be implemented. However something is needed in order to make the domain deletion process less system intensive as the registry cannot continue to support the amount of traffic caused by these domains dropping.
If I could mod your comment as a Troll I would. You state "Face the truth, java is a cripled language for lots of reasons" without giving any details to back that statement up.
Why is Java crippled? Because it has a feature-rich cross-platform standard API? Because it has built in multi-threading? Because it makes writing network code a snap? Because Sun actively supports it and listens to developer requests through the Java Community Process? Because it has modern JIT compilers and HotSpot which makes its runtime speed more then acceptable? Because it has a large number of useful APIs provided by open source developers such as myself?
Please, don't spread the FUD.
I probably should qualify my original statement by saying that no "new" 2 letter second level domains will be allowed. Of course that is just a guess based on previous TLDs.
I can almost guarantee that one letter and two letter second level domains will be forbidden, as described in the Proposed Unsponsored TLD Agreement: Appendix K.
Microsoft would NEVER be able to post ads on SlashDot with this system.
You like reading Slashdot, right? Slashdot could be written in Java using JSP for page generation. This is the type of dynamic content that the author is referring to.
I REALLY wish people would stop immediately associating Java with eye-candy applets. This is, IMHO, the weakest use for Java.
As a server side language Java is extremely powerful, primarily due to the huge number of APIs available but also due to the basic design of the language and the core API. Java also promotes code reuse better than any mainstream language out there (once again this is my opinion).
If you don't like Java as a server side language then don't use it. But please, stop saying Java == applets or JavaScript and using that as a reason to trash the Java platform.
You should definately transfer before the current registration expires. If you transfer you will not lose the time between now and the expiration date as domain years are now added on from the expiration date, not the date of renewal.
The whole concept of domain ownership is still murky, especially since different registrars have different policies about who the owner is (i.e. Register.com believes it is the administrative contact!)
If the author is only worried about database access time, then he was not clear enough in his original post. Regardless, most large sites like Amazon ARE replicating their databases (even to the point of placing DB servers at different geographical locations, along with server farms.) While this is expensive, it is necessary for any high, high volume site.
One of the most common ways to scale your site is to add hardware load balancing and multiple cheap servers running exact copies of your web site. This is how I have built my company's site.
We use a Cisco Local Director to load balance as many Linux servers as we like. It is very easy to insert and remove servers in a configuration like ours. Most large company's (such as Amazon or Yahoo!) will use multiple systems like this.
As for adding on new features, I would say that an iterative process is best. Once again, most large sites will have hundreds of developers working on different features which they will roll out one by one.