Whatever server is handling dmoz.org is totally inadequate. I'd like to become an editor, because there's obviously a need for that, but just getting into dmoz.org requires a great deal of patience. For each access to any page in dmoz, there is less than a 1 in 5 chance of getting a "Cannot find server" error. Therefore the odds of getting through an entire multipage procedure, such as becoming an editor, are extremely low, especially if there is a cgi involved. Maybe that's why you have an editor shortage?!
You guys need to hit Google up for a new server
- Thread starter mutatron
- Start date
bobrat
Member
- Joined
- Apr 15, 2003
- Messages
- 11,061
Re: You guys need to hit Google up for a new serve
Google has no ownership in ODP - please read the posts about "Who owns DMOZ"
You could try http://ch.dmoz.org/
Google has no ownership in ODP - please read the posts about "Who owns DMOZ"
You could try http://ch.dmoz.org/
Re: You guys need to hit Google up for a new serve
Why should they? They're not affiliated with AOL/TW, they're getting the data for free as it is. Why should they feel obliged to fork out any money towards the ODP (and why should the ODP even expect...or want...someone else to step in and donate)?
Why should they? They're not affiliated with AOL/TW, they're getting the data for free as it is. Why should they feel obliged to fork out any money towards the ODP (and why should the ODP even expect...or want...someone else to step in and donate)?
Re: You guys need to hit Google up for a new serve
Fortunately (as has been said somewhere, I think) the issue is not number of servers.
The issue is re-engineering a very large and complex centralized database to allow synchronized access from <n> servers, for <n> greater than one.
I've worked on some problems with some similarities to this one; to be able to listen to an overview of the process and suggest feasible improvements is a most unusual skill.
In the absense of knowledge of the algorithm, about all you can _know_ for certain is that choice of algorithms is far more significant than number of servers. In fact, more servers added to the wrong algorithm, or a buggy algorithm, can actually slow down the process!
More generally, you should assume that any kind of synchronization is designed for a particular kind of access patterns; and can degrade painfully in the face of distinctively different access patterns. At this point, some suspect (but we do not know) that this is happening also.
Think of a rush hour commuter traffic jam. The "cars" are "servers" carrying "loads." It would be an act of incredible stupidity to look at the commute time and say, "the problem is, there aren't enough taxis out there to get people to work on time." To say, "it's obvious we need BIGGER servers -- that is, buses" is unfortunately more credible, but no less stupid. The fact is, performance problems are often subtle, and an experienced analyst will expect many of the solutions to be counterintuitive. In fact, depending on the KIND of traffic patterns, buses may well make the traffic run slower, or faster, or have very little effect.
One of the things that is going on right now is, technical staff is experimenting with, um, different sizes of taxis and buses, different shapes and locations of parking lots and bus stops, and various other interrelated parameters.
Fortunately (as has been said somewhere, I think) the issue is not number of servers.
The issue is re-engineering a very large and complex centralized database to allow synchronized access from <n> servers, for <n> greater than one.
I've worked on some problems with some similarities to this one; to be able to listen to an overview of the process and suggest feasible improvements is a most unusual skill.
In the absense of knowledge of the algorithm, about all you can _know_ for certain is that choice of algorithms is far more significant than number of servers. In fact, more servers added to the wrong algorithm, or a buggy algorithm, can actually slow down the process!
More generally, you should assume that any kind of synchronization is designed for a particular kind of access patterns; and can degrade painfully in the face of distinctively different access patterns. At this point, some suspect (but we do not know) that this is happening also.
Think of a rush hour commuter traffic jam. The "cars" are "servers" carrying "loads." It would be an act of incredible stupidity to look at the commute time and say, "the problem is, there aren't enough taxis out there to get people to work on time." To say, "it's obvious we need BIGGER servers -- that is, buses" is unfortunately more credible, but no less stupid. The fact is, performance problems are often subtle, and an experienced analyst will expect many of the solutions to be counterintuitive. In fact, depending on the KIND of traffic patterns, buses may well make the traffic run slower, or faster, or have very little effect.
One of the things that is going on right now is, technical staff is experimenting with, um, different sizes of taxis and buses, different shapes and locations of parking lots and bus stops, and various other interrelated parameters.