Raising the price for tld would actually be a good thing, as it would make "domain investing" (domain hoarding) unprofitable.
Let's say a .com costs $1,000 per year. For a legitimate business / organization, that is a trivial cost. For a domain hoarder, that makes keeping domains by and large unprofitable.
Except that a .com won't cost $1,000/year because the number of domains registered in it is so large (more than 130 million) that the uproar would be deafening and the registry has no incentive to slice off its nose just to go after squatters.
The .org domain is a tenth the size (about 14 million domains) so it's possible that a massive price hike could go through with no one able to stop it--as we're discussing here--but in doing so, you've thrown the baby out with the bath water and made a whole lot of historical domains with no commercial purpose (remember that .org has usually been where "non-business" groups and individuals register) prohibitively expensive in order to tackle a speculative problem.
Wow. That's around 1% of some of my clients take home simply to have a web site for their small business. This drives everybody to "Facebook pages" instead of their own website hosted on Wix, Wordpress or Squarespace.
I know you meant this as an example, but $1000 is a lot of money for many students, hobbyists, bloggers and startups.
For that matter, even $100 will put many at a huge disadvantage in low income countries. I'd rather have squatting than make domains unaffordable for the developing world.
Personal anecdote: If the e-mails I get every few months are to be believed, yes. I was lucky enough to be around on the Internet when domains were free so I have two .org domains (because to have a .com back then was a sign that you were one of those "dirty businesses" who wanted to "sully the InterNet"[0]) that are old enough to buy their own drinks in the States. Both have been used for e-mail and internal naming schemes for as long as I've had them; only one has a web site.
Every few months, I get e-mails asking if I'll sell one or the other for a small sum or donate the domain to the group that's asking. I used to reply and politely decline but the vitriol about my "pointlessly" keeping a domain that I'm "obviously not using" that inevitably comes back now has me shift-Delete e-mails like that. The times, they have changed.
0 - And getting a .net meant showing you were an actual Network Operator. Anybody else remember FTPing the template down from internic.net and sending it to hostmaster and waiting two months for the zone delegation?
The average price a domain investor sells a domain for is around $2,000. That's a one time charge, and then after that they pay just about $10 a year to renew.
And people register alternative domains rather than one an investor owns because they don't want to pay that amount.
So I don't agree with your thinking.
And in some countries $1,000 is a lifetime's earnings.
I would have to seriously reconsider my domain if it cost a lot of money.
Perhaps domain registrars could do a lot to stop a lot of hoarding if they charged progressively by the number of domains with the same payment details?
Of course, perhaps registrars don’t want to stop hoarding?
That's complete nonsense. Many many people hold TLDs for their private websites. That's a thousand dollars for each one of your websites. That's ridiculous, not everyone can afford that. This would be the death of small independent websites. Though I wouldn't be surprised if that's what's happening.
-- Most merchants want either a declined transaction (possibly with explanation -- possibly), or an accepted one with a guarantee against chargebacks.
Well in fact their is an issue of misaligned incentives here. Your chargeback insurance has a strong incentive not to receive any chargeback (of course), so they will be overly cautious and decline a lot of valid charges. Stripe on the other hand as perfectly aligned incentives with the merchant, as they don't make money on a blocked transaction.
This does not contradict what I said. Declines should be free. Accepts should be guaranteed (but not free). Stripe currently offers free declines, but not guaranteed accepts.
I'm no expert here but current job duration may be counter-intuitive. We usually think that the longer the better but it may also correlate with inability to find another job, so in fact during a recession, these kinds of people may actually be more at risk than people used to job-hop.
It probably needs to be controlled for social class and job type but I think this could explain the phenomenon.
Absolutely. It's crucial for a founder to be able to take a step back and think strategically. Being always under water and completing task after task prevents you from seeing the big picture and taking the big decisions.
It doesn't have to be the case, at least not from my experience managing startup teams. The most usual case I've seen is that you have to let the employee go for performance reasons but you still have a good relationship with him and it's pretty natural to help by a) telling what was wrong and what he could improve in his new job and b) offering help to find a new job/talk to his prospective employers about what he did do right. I would even argue that even the most selfish managers should still proceed that way, since ending a relationship on a (as much as possible) positive note decreases the risk of a lawsuit afterwards.
Very interesting read. What I would add to this framework is the often overlooked "solving one big problem" vs "solving lots of small problems". Most startups try to solve lots of problems, which can be seen by the number of features being developped. This is understandable: in the early days, you keep thinking that "if we had feature X, we would close customer A" and keep on adding more and more features.
In general this doesn't work, because small problems are something we can live with. It's way better to solve one big problem, the one the customer is losing sleep over.
At Local Motion, we noticed that the big customers we closed fast were always companies with one very big problem we could solve (e.g. "my cars are getting stolen") vs lots of small problems (e.g. "software tool for maintenance" + "data reports" + "graphs" + xxx)
That's one of the reasons I like the Node ecosytem: the culture is really about finding the right library and designing clean interfaces so that you can switch when you need to. Having worked with Grails in the past was such a pain in comparison ...
I agree with you and have the skill and facilities to run a VM with node as most of the HN audience does, but this doesnt represent the majority of little nobody sites that litter the web.
If a dev really writes code that blocks the event loop, is not tested and not reviewed, I'm not sure he should work on professional projects ...
Anyway with one nodejs process it's not possible, but you can detect a stuck node and use some load balancing with a cluster of node processes (2 is usually enough), and simply reload a process if it gets stuck (while sending an email to ops of course). You need to use such an architecture to get zero-downtime deployments in any case .
a low priority admin page renders a 3000 row, 30 col table on the server using react. The query and resulting page size are pretty small < 2MB but this takes 5s for react to render.
I didn't expect it to be this slow and can't use client side rendering.
Those type of frameworks are great, but they all have performance limitations. The typical solutions are either find a faster framework or write it by hand. If the issue is that it is blocking the event loop rather than the literal performance, then you could spawn a process to do the React work.
You could break it up so that it processes the 3000 rows in chunks of say.. 500, and use process.nextTick() between each chunk to ensure node is handling other events too.
That would block a server for 500ms six times which is still unacceptable let alone being a hack that would mean rewriting the react page to support partial evaluation.
Your suggestion is basically to write your own event loop and write any cpu bound task to manually yield to the single-threaded node event loop. Crazy given we have been using multithreaded servers for decades that would do this automatically and generalise for any cpu-bound task.
The last point about small libraries versus monolithic framworks really resonnates with me. I always have a hard time understanding why my team should commit to one specific way of doing almost everything, instead of picking the best tool for every job. In my experience, framework code is of a very varying quality, some is good, some is not, some doesn't suit what I want to do.
Let's say a .com costs $1,000 per year. For a legitimate business / organization, that is a trivial cost. For a domain hoarder, that makes keeping domains by and large unprofitable.
Killing this parasitic activity is a good thing.