CouchDB, which has been generating somehype lately (especially among Rails fans), is by Damien Katz, who did work on LotusNotes and Domino, and claims CouchDB is inspired by that.
According to him, Lotus got a lot of things wrong, but it got the database right.
I don't know if there would be anything to gain from the original (even just to read through it), or if we should all be focused on CouchDB now, but it would be interesting to find out.
It seems to me that when you're spending 90% of your time doing nothing other than driving around town, or a daily commute, it makes a lot more sense to rent or borrow something for the other 10%, assuming, in fact, you actually run into that other 10%.
perceived sturdiness
Not entirely perceived -- after all, sheer size counts for a lot in a crash. Of course, the net result has been that the roads are less safe for everyone, and there are still better options if you want a big car.
their status.
This, I just never understood, and it makes even less sense now that the wealthiest people seem to be buying Priuses.
First of all, the automobile represents freedom. Freedom to go where you want, when you want. You are not tied to mass transit schedules and routes.
I live in a small town, and I find the most freedom when on foot. It takes more time to get places, sure, but if it's a car, if I start walking somewhere else, I'll have to walk back to the car at some point. If I ride a bike, there's that plus the fact that if someone offers a ride, I either have to leave the bike and get it later, or find a way to fit it (possibly with jumper cables) into their car.
I imagine the same would be true in a city, and that's what I've found, most of the time. No need to deal with finding parking (or paying for it), filling the tank (and maintaining the car) -- instead, I can just walk up to a bus stop or a train station, wait at most some 20 minutes, then go wherever I want. What's more, my hands are free during the whole process, which means a laptop, an iphone, whatever I want to do while I wait -- if I'm driving, I'm limited to audio, and even that is distracting and potentially dangerous.
The only thing that's really more free about a car is if I suddenly want to go a few cities or states away, I can, much cheaper and with much less planning (just check Google Maps) than with a plane. Unfortunately, for most people (who have jobs), that's not possible.
A family of five wants a car that can comfortably haul the family plus a couple of friends plus their stuff.
As another poster said, minivans accomplish this far better than SUVs, and with better mileage.
Fox would then scramble to make a deal with WB so that they could actually make money on it somehow.
And hopefully before the movie inevitably gets leaked. It would kind of suck for both parties if the movie was available only via BitTorrent for several months, while legal issues got sorted out.
Pop it in a computer, use something like vlc, and you can skip anything you want. And unlike VHS, you don't have to sit there for 2-5 minutes watching that 10 minutes go by -- you just click "next" a few times, and you're done.
And this is, indeed, one of the effects of DRM and patents -- no one's going to sell a player without all the licensing in place, which means that the DRM gatekeepers could always decide that no players can be made which allow skipping. It's also the reason they try crap like region-coding.
Fortunately, DVD was cracked years ago, so you have VLC.
So, Passenger won't be needed as soon as Merb completes its own, similar project. It is already able to fork, which is especially useful in development mode, and there has been talk of having it fork on demand, to dynamically scale your cluster up and down.
That's good, because Passenger is a little too tied to Apache for my tastes. I much prefer a pure-Ruby solution which I can throw behind any old load-balancer.
The amount of ugly, spaghetti-like "meta-programming" needed to make Rails code look as simple and pretty as it does makes me want to scream sometimes.
That's not metaprogramming, that's Rails, or at least, Rails 2. Check out Merb for a counterexample.
Better yet, learn how it works, and then see if you can do better. I remember digging into ActionMailer, and being frustrated at the sheer bloat, but when I wrote something similar (wrote to the database, rather than to SMTP), it was much smaller.
The spaghetti part is that the integer class handles date/time functions as well. That's inherently messy and conceptually ugly.
If you say so -- keep in mind that not much has to be done within the integer class, other than creating and referring to objects of more appropriate classes. I am not sure if this is actually what Rails does, but it would make sense.
And in that sense, I don't see 5.seconds as being uglier than seconds(5) -- after all, it is unlikely that anyone would create a "seconds" method on integers except for that purpose. Beyond that, I'm sure you will agree, methods like 'ago' or 'from_now' make sense.
There are Time, Date, and DateTime classes in Ruby, and they work more or less the way you expect. Time is available out of the box, and Date/DateTime is available in the standard library. This is just a convenient interface for dealing with them -- 5.seconds.ago will, in fact, return a Time object.
And if you really don't like it, just don't use Rails. Ruby itself has nothing related to dates in its Integer class. Rails (specifically, ActiveSupport) adds them.
In Python for example, if I want date/time manipulation, I import the requisite module.
And that is still true -- here, if you want to manipulate dates and times in this way, you require activesupport, which requires date and a few other things. The good news about Merb is, it's likely that you won't need all of activesupport to make that happen.
In Ruby, it seems as though I get date/time manipulation just by virtue of having integers (which I presume I always have), which makes me wonder what else is being brought in whether I know about it or not.
This is not the case -- you're confusing Ruby and Rails. If you have an environment set up, you can easily compare by running a simple irb, which will give you a bare Ruby, versus opening a Rails project and running script/console, or requiring activesupport in another irb.
More importantly, why would it bother you? What possible disadvantage could there be to having methods like seconds, minutes, and hours on integers, other than seeming conceptually odd?
not knowing what's going on under the hood is part and parcel if you're using a giant framework like Rails.
Perhaps. I found Rails code needlessly long and complex, but it was readable, and open source. So it's not actually that difficult to figure out what's going on, especially if you know Ruby well.
And we haven't really touched on symbols. One trick adopted by Rails, which is actually built into Ruby 1.9, is Symbol#to_proc. I don't have an example offhand, but I'll try to explain what it does:
Symbols are, effectively, frozen strings which are faster to compare. That's oversimplifying, but it's enough to give you an idea.
Procs are chunks of executable code, much like an anonymous function. Ruby methods often take procs as arguments. Contrived example:
ducks = [Duck.new, Duck.new, Duckling.new] ducks.each do |duck|
duck.quack! end
That each method, on that array, is taking the do..end block as proc argument, and calling it once for each duck in the array. Rails changes the Symbol class like this:
class Symbol
def to_proc
Proc.new do |object|
object.send self
end
end end
send, in this case, means "send this message to this object" -- effectively, "foo.send:bar" is equivalent to "foo.bar". So now, I can actually do this hack:
ducks.each(&:quack!)
That ampersand effectively means, turn this into a proc. So, the result of:quack!.to_proc is passed to ducks.each. More compact, more readable once you've seen it used.
making object hierarchies that seem to serve only to replicate the English language in a language not designed to resemble English syntax.
Not at all required, but that's one of the things I love about Ruby -- that you can do that, which makes the code extremely readable. Whether or not you like the fact that these methods exist on integers, it doesn't really hurt, and at a glance, even a non-programmer understands.
It seems to me like it would be more sensible to have, on a datetime object, some simple 'within', 'before', 'after' methods that return true/false (e.g. post.date.within "5 seconds"
So, instead of adding methods to an integer, you'd be parsing strings? I like the Rails way better.
Oh, and it's a bit more flexible than that -- because 5.seconds is actually a value of time, and 5.seconds.ago is actually a datetime.
But then, if you don't like this, you'll hate rspec...
It just comes across like Rails tries to make things convenient that were never really THAT difficult, or which could have been done in a far more sensible way
Perhaps not, but Rails is targeting the first 80% -- and while it takes some time to get used to, it's now at the point where I get quite annoyed when I can't do 5.seconds.ago, and instead have to do something like Time.at(Time.now.to_i - 5) -- and that's not even equivalent (5.seconds.ago handles usecs).
So, while it's not that difficult, it's also damned convenient, and if Rails stopped doing it, I'd find something that did, or write it myself. Hopefully Merb/Rails3 will split it out into some small time-manipulation library, so that a Rails app can be built without it, and a separate app can be built with it but without a huge pile of ActiveSupport.
I just have a hard time taking a language seriously that seems to overload integers to do date/time calculations.
You'll hate the Inflections library, then.
Everything seems mixed together in true spaghetti fashion, and that, more than anything, turns me off the language and framework entirely.
I really don't see the connection to this, though. What's spaghetti about having a convenient way to create and manipulate time durations?
So Install XP Home on VirtualBox and then run the Windows version of Quicken if you must.
I'd use XP Pro, or, more likely, Wine. But whatever...
Mac users are 2nd class citizens to Intuit and that shouldn't be supported.
Erm, WTF?!
Ok, that behavior is basically telling Intuit, "Hey, you don't have to support the Mac after all! Your Mac users are so desperate for your product, they'll do the work for you -- including spending hundreds of dollars on Windows and virtual machine software!"
No, if you actually don't want to support them, don't buy their software. Give that money, instead, to an open source project (like GnuCash, say), or find someone else -- there are a few interesting web-based competitors now.
But this is every bit as stupid as saying "Vista sucks! Vote with your dollars and buy XP instead!"
Yes, the debugging does kind of suck. On the other hand, Rails is pretty easy to test. I do still occasionally break out the debugger -- which does exist, and isn't actually that bad, just isn't good -- but for the most part, unit tests work well enough.
we've gone through four different ways to run RoR apps
And they do seem to be improving... Right now, Rails apps are generally run as a standalone webserver, which can (if needed) be placed behind a load-balancing proxy like nginx, making it easy to scale horizontally.
I don't really see that going away. Everyone seems to be wetting themselves about Passenger, but really, I suspect I'll be running little embedded Ruby webservers for awhile now. Rack makes them pluggable, so if you don't like Mongrel, you can use something else. It also means that they can be put behind any frontend you like, and it means you can run whatever you like on the backend, without having to think too hard.
Rubygems make it easy to maintain multiple versions of Rails -- not that you really have to care. It's not hard to bundle Rails itself with the app -- thus, the system I've described above is really more a Ruby app deployment, not just a Rails app deployment.
Python started in 1991, Ruby in 1995. Are you telling me you're still mad about that?
Or are you talking about something of substance -- like, say, frameworks? Because here, Merb has done some things that make Django developers jealous. (And vice versa, of course.) And Python still hasn't figured out how to write a decent package manager -- "easy-install" is anything but.
And your "performance" comment, as it turns out, really isn't justified. I don't know about Python, but it turns out that Merb is faster than PHP, and absurdly faster than CakePHP.
It's also been lightweight in that Rails has always had everything you need, in some form. All kinds of Rails plugins that won't work with Merb. All kinds of conveniences that you get for free somewhere in ActiveSupport, like being able to type "5.seconds.ago" or, of course, Symbol#to_proc -- some might exist in Merb, some won't.
This move is good for Rails for obvious reasons, like the ones you've outlined -- even just ActiveSupport takes something like a half second to load on my machine. But it's also a good move for Merb -- probably the single biggest problem Merb had, for many people, was "it's not Rails."
So you'll get www.cocacola and www.pepsi (or just pepsi) but never www.apache or www.firefox.
I don't see how that's less fair than the current situation, where merely being a nation gives you a TLD. There is not a www.firefox, but there is a www.tk.
And I would not be incredibly surprised to see at least a few of those -- maybe not apache, but firefox seems to get a fair amount of funding.
I'm saying they're "not a religion" because the people running it went out of their way to make it clear that they weren't...
True, it's difficult to find evidence of Christianity denying being a religion -- though Zen and Buddhism seem to.
I think that's more a technicality than anything, though -- it's not as if other religions weren't abusing the very concept of a religion as a form of protection for... whatever it was they needed.
Given the profits that can be made selling subdomains of the TLD, $100k is a drop in the bucket,
That balances out, I think -- that is, if it's really so cheap, and really so profitable, a large number of corporations which have that $100k will spend it, and before you know it, the domains won't be worth as much. But that'll happen faster than with.com, and you won't exactly have trolls willing to spend $100k just on the offchance of a Google hit.
My assumption would be that the $100k is meant as a deterrent to that flood of TLDs. I'm guessing most organizations would rather pay $10 or $50 for a domain or three.
And, hey, it's like the "I Am Rich" app. If the rich want to waste their money, let them.
The only part that's not fair is the fact that one organization gets to monopolize this, and unilaterally decides how much it should cost, what the procedure is, etc. But that hasn't changed, and I have no idea what a good solution is.
IMHO, we need a California-wide ballot measure to demand citizen oversight committees be in charge of all traffic light management. That's the only way the abuse will stop.
Unfortunately with the state of California being as broke as it is... I doubt anything like this will ever happen
Just dress it up as a green initiative, and point out that it creates jobs.
From TFS, I don't really see what all the fuss is about. Why does anyone care? Pretty much anyone can buy a.com name, for any reason, and then resell subdomains -- this is just the same thing, without the.com, and much more expensive.
Slashdot Mirror
CouchDB, which has been generating some hype lately (especially among Rails fans), is by Damien Katz, who did work on LotusNotes and Domino, and claims CouchDB is inspired by that.
According to him, Lotus got a lot of things wrong, but it got the database right.
I don't know if there would be anything to gain from the original (even just to read through it), or if we should all be focused on CouchDB now, but it would be interesting to find out.
Erm... I still don't get it, and I'm an American.
versatility
It seems to me that when you're spending 90% of your time doing nothing other than driving around town, or a daily commute, it makes a lot more sense to rent or borrow something for the other 10%, assuming, in fact, you actually run into that other 10%.
perceived sturdiness
Not entirely perceived -- after all, sheer size counts for a lot in a crash. Of course, the net result has been that the roads are less safe for everyone, and there are still better options if you want a big car.
their status.
This, I just never understood, and it makes even less sense now that the wealthiest people seem to be buying Priuses.
First of all, the automobile represents freedom. Freedom to go where you want, when you want. You are not tied to mass transit schedules and routes.
I live in a small town, and I find the most freedom when on foot. It takes more time to get places, sure, but if it's a car, if I start walking somewhere else, I'll have to walk back to the car at some point. If I ride a bike, there's that plus the fact that if someone offers a ride, I either have to leave the bike and get it later, or find a way to fit it (possibly with jumper cables) into their car.
I imagine the same would be true in a city, and that's what I've found, most of the time. No need to deal with finding parking (or paying for it), filling the tank (and maintaining the car) -- instead, I can just walk up to a bus stop or a train station, wait at most some 20 minutes, then go wherever I want. What's more, my hands are free during the whole process, which means a laptop, an iphone, whatever I want to do while I wait -- if I'm driving, I'm limited to audio, and even that is distracting and potentially dangerous.
The only thing that's really more free about a car is if I suddenly want to go a few cities or states away, I can, much cheaper and with much less planning (just check Google Maps) than with a plane. Unfortunately, for most people (who have jobs), that's not possible.
A family of five wants a car that can comfortably haul the family plus a couple of friends plus their stuff.
As another poster said, minivans accomplish this far better than SUVs, and with better mileage.
Fox would then scramble to make a deal with WB so that they could actually make money on it somehow.
And hopefully before the movie inevitably gets leaked. It would kind of suck for both parties if the movie was available only via BitTorrent for several months, while legal issues got sorted out.
In fact, I would argue that most Phillip K. Dick books are better as movies, once Hollywood has a chance to make some kind of sense with them.
Pop it in a computer, use something like vlc, and you can skip anything you want. And unlike VHS, you don't have to sit there for 2-5 minutes watching that 10 minutes go by -- you just click "next" a few times, and you're done.
And this is, indeed, one of the effects of DRM and patents -- no one's going to sell a player without all the licensing in place, which means that the DRM gatekeepers could always decide that no players can be made which allow skipping. It's also the reason they try crap like region-coding.
Fortunately, DVD was cracked years ago, so you have VLC.
I see...
So, Passenger won't be needed as soon as Merb completes its own, similar project. It is already able to fork, which is especially useful in development mode, and there has been talk of having it fork on demand, to dynamically scale your cluster up and down.
That's good, because Passenger is a little too tied to Apache for my tastes. I much prefer a pure-Ruby solution which I can throw behind any old load-balancer.
Sorry, I guess I wasn't clear...
Yes, it is meta-programming. However, I don't think it's an inherent property of metaprogramming, that it has to be ugly, spaghetti, or convoluted.
My point was that yes, Rails metaprogramming is ugly. However, that's Rails. Metaprogramming can be done properly.
The amount of ugly, spaghetti-like "meta-programming" needed to make Rails code look as simple and pretty as it does makes me want to scream sometimes.
That's not metaprogramming, that's Rails, or at least, Rails 2. Check out Merb for a counterexample.
Better yet, learn how it works, and then see if you can do better. I remember digging into ActionMailer, and being frustrated at the sheer bloat, but when I wrote something similar (wrote to the database, rather than to SMTP), it was much smaller.
The spaghetti part is that the integer class handles date/time functions as well. That's inherently messy and conceptually ugly.
If you say so -- keep in mind that not much has to be done within the integer class, other than creating and referring to objects of more appropriate classes. I am not sure if this is actually what Rails does, but it would make sense.
And in that sense, I don't see 5.seconds as being uglier than seconds(5) -- after all, it is unlikely that anyone would create a "seconds" method on integers except for that purpose. Beyond that, I'm sure you will agree, methods like 'ago' or 'from_now' make sense.
There are Time, Date, and DateTime classes in Ruby, and they work more or less the way you expect. Time is available out of the box, and Date/DateTime is available in the standard library. This is just a convenient interface for dealing with them -- 5.seconds.ago will, in fact, return a Time object.
And if you really don't like it, just don't use Rails. Ruby itself has nothing related to dates in its Integer class. Rails (specifically, ActiveSupport) adds them.
In Python for example, if I want date/time manipulation, I import the requisite module.
And that is still true -- here, if you want to manipulate dates and times in this way, you require activesupport, which requires date and a few other things. The good news about Merb is, it's likely that you won't need all of activesupport to make that happen.
In Ruby, it seems as though I get date/time manipulation just by virtue of having integers (which I presume I always have), which makes me wonder what else is being brought in whether I know about it or not.
This is not the case -- you're confusing Ruby and Rails. If you have an environment set up, you can easily compare by running a simple irb, which will give you a bare Ruby, versus opening a Rails project and running script/console, or requiring activesupport in another irb.
More importantly, why would it bother you? What possible disadvantage could there be to having methods like seconds, minutes, and hours on integers, other than seeming conceptually odd?
not knowing what's going on under the hood is part and parcel if you're using a giant framework like Rails.
Perhaps. I found Rails code needlessly long and complex, but it was readable, and open source. So it's not actually that difficult to figure out what's going on, especially if you know Ruby well.
And we haven't really touched on symbols. One trick adopted by Rails, which is actually built into Ruby 1.9, is Symbol#to_proc. I don't have an example offhand, but I'll try to explain what it does:
Symbols are, effectively, frozen strings which are faster to compare. That's oversimplifying, but it's enough to give you an idea.
Procs are chunks of executable code, much like an anonymous function. Ruby methods often take procs as arguments. Contrived example:
That each method, on that array, is taking the do..end block as proc argument, and calling it once for each duck in the array. Rails changes the Symbol class like this:
send, in this case, means "send this message to this object" -- effectively, "foo.send :bar" is equivalent to "foo.bar". So now, I can actually do this hack:
That ampersand effectively means, turn this into a proc. So, the result of :quack!.to_proc is passed to ducks.each. More compact, more readable once you've seen it used.
It takes a bit to
making object hierarchies that seem to serve only to replicate the English language in a language not designed to resemble English syntax.
Not at all required, but that's one of the things I love about Ruby -- that you can do that, which makes the code extremely readable. Whether or not you like the fact that these methods exist on integers, it doesn't really hurt, and at a glance, even a non-programmer understands.
It seems to me like it would be more sensible to have, on a datetime object, some simple 'within', 'before', 'after' methods that return true/false (e.g. post.date.within "5 seconds"
So, instead of adding methods to an integer, you'd be parsing strings? I like the Rails way better.
Oh, and it's a bit more flexible than that -- because 5.seconds is actually a value of time, and 5.seconds.ago is actually a datetime.
But then, if you don't like this, you'll hate rspec...
It just comes across like Rails tries to make things convenient that were never really THAT difficult, or which could have been done in a far more sensible way
Perhaps not, but Rails is targeting the first 80% -- and while it takes some time to get used to, it's now at the point where I get quite annoyed when I can't do 5.seconds.ago, and instead have to do something like Time.at(Time.now.to_i - 5) -- and that's not even equivalent (5.seconds.ago handles usecs).
So, while it's not that difficult, it's also damned convenient, and if Rails stopped doing it, I'd find something that did, or write it myself. Hopefully Merb/Rails3 will split it out into some small time-manipulation library, so that a Rails app can be built without it, and a separate app can be built with it but without a huge pile of ActiveSupport.
I just have a hard time taking a language seriously that seems to overload integers to do date/time calculations.
You'll hate the Inflections library, then.
Everything seems mixed together in true spaghetti fashion, and that, more than anything, turns me off the language and framework entirely.
I really don't see the connection to this, though. What's spaghetti about having a convenient way to create and manipulate time durations?
So Install XP Home on VirtualBox and then run the Windows version of Quicken if you must.
I'd use XP Pro, or, more likely, Wine. But whatever...
Mac users are 2nd class citizens to Intuit and that shouldn't be supported.
Erm, WTF?!
Ok, that behavior is basically telling Intuit, "Hey, you don't have to support the Mac after all! Your Mac users are so desperate for your product, they'll do the work for you -- including spending hundreds of dollars on Windows and virtual machine software!"
No, if you actually don't want to support them, don't buy their software. Give that money, instead, to an open source project (like GnuCash, say), or find someone else -- there are a few interesting web-based competitors now.
But this is every bit as stupid as saying "Vista sucks! Vote with your dollars and buy XP instead!"
Does GnuCash actually choke on EV certs, though? That would be surprising.
And, at least in the case of GnuCash, fixable.
It also allows you to use Enterprise Ruby, with it's COW GC.
This is something Merb is likely to support out of the box, soon, if it doesn't already.
There's little to no debugging
Doesn't sound like a sysadmin, but I'll bite.
Yes, the debugging does kind of suck. On the other hand, Rails is pretty easy to test. I do still occasionally break out the debugger -- which does exist, and isn't actually that bad, just isn't good -- but for the most part, unit tests work well enough.
we've gone through four different ways to run RoR apps
And they do seem to be improving... Right now, Rails apps are generally run as a standalone webserver, which can (if needed) be placed behind a load-balancing proxy like nginx, making it easy to scale horizontally.
I don't really see that going away. Everyone seems to be wetting themselves about Passenger, but really, I suspect I'll be running little embedded Ruby webservers for awhile now. Rack makes them pluggable, so if you don't like Mongrel, you can use something else. It also means that they can be put behind any frontend you like, and it means you can run whatever you like on the backend, without having to think too hard.
Rubygems make it easy to maintain multiple versions of Rails -- not that you really have to care. It's not hard to bundle Rails itself with the app -- thus, the system I've described above is really more a Ruby app deployment, not just a Rails app deployment.
You're absolutely right that Ruby is slow, and Ruby 2.0 will make it faster. But relative to what?
It turns out, someone has done benchmarks, and the results may surprise you. It turns out, Ruby really isn't that slow.
As for the ease of deploying, you can do it seamlessly with mod_passenger nowadays
You know, I really don't get this -- how, exactly, is Passenger easier to deploy?
For that matter, how is Rails hard to deploy? I've always found Capistrano to be much easier (and more powerful!) than sending PHP files over FTP.
Python started in 1991, Ruby in 1995. Are you telling me you're still mad about that?
Or are you talking about something of substance -- like, say, frameworks? Because here, Merb has done some things that make Django developers jealous. (And vice versa, of course.) And Python still hasn't figured out how to write a decent package manager -- "easy-install" is anything but.
And your "performance" comment, as it turns out, really isn't justified. I don't know about Python, but it turns out that Merb is faster than PHP, and absurdly faster than CakePHP.
It's also been lightweight in that Rails has always had everything you need, in some form. All kinds of Rails plugins that won't work with Merb. All kinds of conveniences that you get for free somewhere in ActiveSupport, like being able to type "5.seconds.ago" or, of course, Symbol#to_proc -- some might exist in Merb, some won't.
This move is good for Rails for obvious reasons, like the ones you've outlined -- even just ActiveSupport takes something like a half second to load on my machine. But it's also a good move for Merb -- probably the single biggest problem Merb had, for many people, was "it's not Rails."
So you'll get www.cocacola and www.pepsi (or just pepsi) but never www.apache or www.firefox.
I don't see how that's less fair than the current situation, where merely being a nation gives you a TLD. There is not a www.firefox, but there is a www.tk.
And I would not be incredibly surprised to see at least a few of those -- maybe not apache, but firefox seems to get a fair amount of funding.
Allow me to bash them for you, then...
Once a year! How generous!
I'm saying they're "not a religion" because the people running it went out of their way to make it clear that they weren't...
True, it's difficult to find evidence of Christianity denying being a religion -- though Zen and Buddhism seem to.
I think that's more a technicality than anything, though -- it's not as if other religions weren't abusing the very concept of a religion as a form of protection for... whatever it was they needed.
Given the profits that can be made selling subdomains of the TLD, $100k is a drop in the bucket,
That balances out, I think -- that is, if it's really so cheap, and really so profitable, a large number of corporations which have that $100k will spend it, and before you know it, the domains won't be worth as much. But that'll happen faster than with .com, and you won't exactly have trolls willing to spend $100k just on the offchance of a Google hit.
Yes, that 404s on me.
My assumption would be that the $100k is meant as a deterrent to that flood of TLDs. I'm guessing most organizations would rather pay $10 or $50 for a domain or three.
And, hey, it's like the "I Am Rich" app. If the rich want to waste their money, let them.
The only part that's not fair is the fact that one organization gets to monopolize this, and unilaterally decides how much it should cost, what the procedure is, etc. But that hasn't changed, and I have no idea what a good solution is.
IMHO, we need a California-wide ballot measure to demand citizen oversight committees be in charge of all traffic light management. That's the only way the abuse will stop.
Unfortunately with the state of California being as broke as it is... I doubt anything like this will ever happen
Just dress it up as a green initiative, and point out that it creates jobs.
I get a 404 on that PDF. Anyone have a mirror?
From TFS, I don't really see what all the fuss is about. Why does anyone care? Pretty much anyone can buy a .com name, for any reason, and then resell subdomains -- this is just the same thing, without the .com, and much more expensive.