Re:GTK+ C++ wrappers, more experiences
on
GTK-- vs. QT
·
· Score: 1
've been working on a Voice-over-IP research prototype during almost the whole last year. I had been using Qt up to then and decided to switch to GTK-- mainly because it doesn't need a meta compiler as Qt does.
What's wrong with their meta compiler? qmake is great, as it handles everything for you. moc is very fast, an order of magnitude or two faster than g++. It's g++ that really slows down compilation, not moc.
Just remember that you only need to give your source to any entity you give the binary to. Being GPL/LGPL doesn't mean you can't use it for business use; the license is entirely transparent for apps which will only be used internally.
Actually, you cannot use the non commercial version of Qt for non free internal applications:
"A non-commercial setting means that you must not use the package in the course of your employment or whilst engaged in activities that will be compensated. A non-commercial application is an application that cannot be sold, leased, rented or otherwise distributed for recompense."
However, their prices are quite reasonable, when you consider what you get. Qt is an excellent toolkit, and in my opinion, better than anything else available. Native support for all three major platforms with only a recompile is great. The price for one enterprise license is probably less than a developer's salary for two weeks. How long would it take you to port your application from X11 to Windows or MacOS?
It doesn't happen in NT because there is not a fixed size resource area for storing GDI information. This is why you can have 256+ megs of ram on Windows 98, only have open a few small but resource intensive programs (like C++Builder), and still run out of "system resources".
directNIC.com is $15 and has nice features like free hosting, paid DNS and paid POP3 email accounts. They also have the best interface I've ever seen for a registrar. They make it really easy to mange lots of domains (even hundreds), which is really nice if you have more than a couple domains. Transfering your domain to them or another registrar is a painless process that doesn't involve the original registrar.
By default, tinydns does not hand out referrals to questions it is asked about zones it does not control. I believe that this violates the spirt of the RFCs, if not the letter.
Right, there's another tool for that, dnscache. It isn't monolithic like BIND, in the spirit of unix.
By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt of the RFCs, as well as the letter (if a DNS query via UDP results in truncation, you're supposed to re-do the query using TCP instead).
Indeed, if you want to support TCP under tinydns, you have to configure an optional program called "axfrdns", which was intended to handle zone transfers, but also happens to share the same database as tinydns, and can handle generic TCP queries.
What's your proof of this? DNS is designed to use UDP. No data should be longer than what fits in a normal UDP response.
The suggested method for copying contents of DNS zones is rsync, scp, or other remote copy tools. The DNS standard method of zone transfers (query type "axfr") is only supported as an additional, disrecommended method.
The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed. Contrariwise, if you use the standard zone transfer mechanism, then the zone transfer should fail if the master is munged, and the slaves should keep a good working copy for a while and give you time to notice that the master is munged and needs to be fixed.
If you read his comments on this, then it makes perfect sense. There are already existing, secure tools that do the job better. No need to invent another bloated and potentially buggy and insecure protocol. How often do you corrupt the database, or mess up an rsync or rcp? In any case, when do you not have a backup of your zone files?
Without a patch from a third party, tinydns does not support the standard "NOTIFY" protocol of informing secondary nameservers that the zone has been updated, and that they need to check the SOA serial number and download a new copy (if they don't already have it).
If you use the (better) transfer method that he recommends, this isn't a problem.
Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.
While this is not the recommended mode of configuration, some sites don't have the luxury of having separate authoritative-only and caching/recursive-only server(s), and need to mix them both on one machine (or set of machines). With the BIND 9 "view" mechanism, this is relatively easy to do. With djbdns, this is impossible.
So run put two IP addresses on the machine, and run them on different IP's.
There aren't even any patches that can get djbdns to implement TSIG, Dynamic DNS, or DNSSEC, nor are they ever likely to be created (my understanding is that the author is strongly opposed to them).
Unfortunately, as time goes on and more and more people are doing things like IPv6, VPNs based on IPSec, or people just care about being able to cryptographically prove that their servers are handing out the only correct information and that the clients are able to cryptographically verify this fact (think: electronic banking), these kinds of features are going to become ever more commonplace.
Note that, with the advent of BIND 9, you can create a caching-only server that will validate cryptographically signed records, and all clients can benefit even if they do not themselves implement any of the new DNSSEC features.
If you read his page about DNS forgery, then you'd see why he is against it.
There are a number of things that djbdns does which I believe to be outright bugs. However, the author of this package simply refuses to accept that his code could be anything less than 100% perfect, and while he claims to have a "bounty" that he will pay for any bug that is found, in reality he is the one that gets to define what he accepts as a "bug", and has repeatedly demonstrated a tendancy to openly refuse to accept some purported bug, but then to quietly fix the code with future releases.
What code doesn't have bugs? Is he supposed to test it indefinitely, and never release for fear of there being some obscure bug that didn't affect him when testing? There is a difference between bugs and security holes. As far as I know, none of his code has ever had security holes. He clearly seems to know what he is doing, and has right to gripe about programs like BIND and Sendmail being buggy. His guarantee is for security holes. I don't see other software making any sort of guarantee. If Microsoft offered $500 for every security hole, would they still be in business? If you check securityfocus.com, the only problem ever reported is a DoS attack against qmail on something that the OS should provide (resource limits).
One argument frequently used to support the use of djbdns over BIND is performance.
So there aren't any real published benchmarks? We don't have nearly that kind of traffic, so I can't say anything about it personally. Also, tinydns is not a cache, so it should not be used for heavily loaded servers. That is what dnscache is for. If you read the blurbs, you'll see someone who found that dnscache outperforms BIND 9. If you use his tools the way they are designed to be used, you'll find they work quite well.
Unfortunately, a lot of the reasons the author gives for running djbdns instead of BIND are related to problems in older versions of BIND which have been fixed or are largely non-issues in later releases of BIND 9.
BIND 9 was not out when djbdns was written, so it makes sense that he would address issues that existed when it was written. Perhaps they actually addressed some of these in BIND 9 due to djbdns? It is very likely that BIND 9 will have the same types of bugs that all the other versions do. Read his papaper for more details. BIND is huge, and takes up a lot of resources. We have servers running BIND that take minutes to load, and use 40-80 megs of ram.
We use MySQL in conjunction with djbdns. We just have a simple daemon that runs and every so often checks the database to see if anything has changed. If it has, it writes out new files, runs the program to convert it to djbdns format, and off it goes. Very quick, very easy, very effective. And it doesn't suck up 80 megs of ram like BIND does when you have lots of zones.
As was pointed out above, apt-get is not the package manager. apt-get is the front end to Debian's package manager, dpkg.
Re:PayPal. Nice idea, but it has it's problems.
on
The PayPal Phenomenon
·
· Score: 1
Or maybe, just maybe, the cost to rectify the situation through legal channels just isn't worth it. By costs, I mean time invested (several hours at a minimum), financial costs and the frustration of dealing with the system. Couple that with the fact that you don't know if you're actually going to get your money back, let alone any compensation for having to fight the system and all the heart-ache, its little wonder that most people don't resort to doing the right thing. Just because you're morally right, doesn't mean the system is going to back you up.
So you should not do anything, and let them get away with screwing over yourself and others? That's the purpose of small claim's court. It costs a small fee to file a claim, but in most cases it's worthwhile. If the business is not located in the same area where you live, then they must pay the expense to send someone to represent them, in addition to paying that person. For a small amount like $60, that cost alone will be higher than the amount you are suing over. I would imagine in most cases, they would pay you rather than going through the unnecessary expense.
That's completely false. How many programs do you have that you wish were faster? If you can notice how long it takes for a program to do something, then it's not fast enough. Wouldn't you like your Perl or PHP scripts to run faster? Should you have to rewrite them in assembly? Isn't it better to recompile the interpreter with a better compiler than write it or the scripts in assembly?
Before I waste 20 minutes looking for a mirror, can anybody tell me if they've included any new maps? That one they have really sucks after like the 10th time you play it so I haven't touched the game since the week it came out.
Really needs more maps.
It's an engine test, not a demo. They will more than likely release a demo shortly before the final version is released, just like with Quake III. The test isn't supposed to reflect final gameplay. It's purpose is to test compatibility and networking code.
Okay, I'm kind of a newbie to Linux. I've been using Linux a little over a month, and I just finished compiling the latest stable 2.4 kernel. Now, tell me again why I'd want to take a step backwards? 2.4 is greater than 2.2.20 according to my math, which means it's better and more recent. So why are they still releasing 2.2? Is there some infighting in the Linux development world or something? Is this type of confusion (releasing 2.2.20 when 2.4 is already out) just one of the costs of the Open Source development methodology? I mean, you never hear about Microsoft releasing Windows 3.12 after Windows 95 is out.
Knowing Slashdot moderators, your comment will probably get modded as troll, but I'll answer anyway. Regarding your Windows example, you are incorrect. This is like Microsoft releasing SP6 for NT 4 after Windows 2000 is released. I'm fairly sure SP6 was released afterwards, but if not, they have still released updates to NT 4 after the release of Windows 2000. Just because a product isn't the latest code base doesn't mean it isn't still being used. Many people are still running NT 4, and need updates, like security fixes. There will still be updates to Windows 2000, even though Windows XP is out.
Even though 2.4 is "stable", it isn't "super stable" yet, and might not be for some time. I would guess that most people running Linux on non SMP production servers are using a 2.2 kernel, simply because it has been tested longer, and known to be stable. Then again, that's why many of us use FreeBSD on our production servers:) At this point, I would use a 2.2 kernel on any product boxes that were going to be running Linux. I've personally had problems with 2.4 on the boxes I use as workstations. For example, 2.4.7 would swap for hours when it ran out of memory. While you'd hope that never happens on a production server, many people can't afford to take that risk.
The current even numbered kernel, in this case 2.4, is the "stable" kernel, and the one behind it, in this case 2.2, is the "super stable" kernel.
Re:Debian vs Slack for the 'unix-like' crown?
on
Is Slackware Fading Away?
·
· Score: 2, Informative
How can any distro that dosn't even include pico be considered 'unix-like' ???
If you want pico, you might try nano. It's a GNU clone of pico. Debian doesn't include pine because it's license violates the Debian Free Software Guidelines (DFSG).
True, but these days, if you say you're running Debian, it's implied that you're running Debian unstable. Damn few people run Debian stable, because it's so out of date.
People who use Debian for servers usually run stable. For a server, it's usually more important to have a rock solid setup than to be running the latest and greatest. That's one of the nice things about Debian. It gives you a super stable platform to use for a server, and the latest and greatest for a desktop.
You can write bad code in any language. Assuming you fixed the fprintf() error, then you would get the numbers 0-15 printed in random order, usually different each time the program is run, depending on how the forks are processed.
There is not a single major software market category where open source software has achieved the levels of user adoption currently enjoyed by closed source software. Predicting the death of an opponent that you have barely begun to even scratch suggests some kind of religious zealotry or Messiah complex. It is delusional.
If you believe the Netcraft reports, then Apache would be one such example of an open source product beating closed source products. Apache has over fifty percent market share. It is also an interesting example. Apache could be compared with Windows in many ways. It's design is poor, compared to Zeus, which is in every way a better web server. The decision to continue with multi process/threaded web server is flawed, in my opinion. While the arguments on the mailing lists might have some valid points, they don't hold any water in light of the fact that there is already a web server that does everything that is "too hard" for Apache to do. Many people use Apache, just like many people use Windows, but that doesn't make it the best at what it does.
Some states like New Mexico help you out in figuring exactly when to go and when to stop. I grew up in the Kansas City area, and for streets with multiple lanes, there would dotted lines between the straight lanes leading up to the light, and solid lines between a straight lane and a turning lane. In New Mexico, there are solid lines between all lanes a certain distance from the light. This marks the "point of no return". If you have entered the solid lines when the light turns yellow, then you keep going, otherwise you stop. These are theoretically marked properly for the speed limit, the length of the intersection and the length of the light. If you aren't used to it, then it seems odd at first, but it is actually very helpful.
Getting people to write clean code is a management issue. You can write clean code in any language, and you can write bad code. Perl has a reputation for encouraging obfuscated code, but if you look at the entries for IOCCC, you might think the same thing about C. The company I work for uses PHP for large ecommerce projects, and I can assure you that PHP doesn't force people to write clean code. If people are going to write bad code, I'd rather it be in a safe language like Perl or PHP, rather than C or C++. Of course, I'd rather not work with people at all that don't have the discipline to write good code:)
Why exactly would you want XML for everything? XML is just a buzzword for apple to capitalize on, imho. XML isn't the fastest thing to parse either. Kconfig's key=value is much faster.
The difference in parsing speed isn't that big, and the time it takes to parse a configuration file is usually negligable compared to everything else. You can still do INI style blocks inside XML, even if it's not "proper" XML. Borland C++Builder 5 uses XML for it's project files, but there are still large blocks inside that look like INI files. The advantage of XML is that it's a tree style data structure, where INI is an array. Hence you can do INI in XML, but not vice versa. Plus XML support different encodings as part of the format, which is a big advantage to internationalized apps.
How would that be regulated? Anyone can register a.com,.net. or.org domain now. If you want 10 domains, you'd need to have 10 different companies (say LLC's). But most many companies do this anyway. Domain registrars are in business to make money. They want to sell as many domains as possible. It is not in their interest to make it prohibitive for people to purchase (register) domains.
How often I have searched for something I wanted to buy, by poring through page after page of Altavista or Google, while having to see an endless list of stupid, blinking, obtrusive ads
Google doesn't have blinking, obtrusive ads, and to my knowledge, it never has had them. All of Google's ads are placed neatly on the page, and are easily distinguishable from the regular search results. That's just one of the many reasons why Google rocks.
Slashdot Mirror
've been working on a Voice-over-IP research prototype during almost the whole last year. I had been using Qt up to then and decided to switch to GTK-- mainly because it doesn't need a meta compiler as Qt does.
What's wrong with their meta compiler? qmake is great, as it handles everything for you. moc is very fast, an order of magnitude or two faster than g++. It's g++ that really slows down compilation, not moc.
Just remember that you only need to give your source to any entity you give the binary to. Being GPL/LGPL doesn't mean you can't use it for business use; the license is entirely transparent for apps which will only be used internally.
Actually, you cannot use the non commercial version of Qt for non free internal applications:
"A non-commercial setting means that you must not use the package in the course of your employment or whilst engaged in activities that will be compensated. A non-commercial application is an application that cannot be sold, leased, rented or otherwise distributed for recompense."
See their page for more details: http://www.trolltech.com/developer/download/qt-win -noncomm.html
However, their prices are quite reasonable, when you consider what you get. Qt is an excellent toolkit, and in my opinion, better than anything else available. Native support for all three major platforms with only a recompile is great. The price for one enterprise license is probably less than a developer's salary for two weeks. How long would it take you to port your application from X11 to Windows or MacOS?
Please give examples of software in use today that have been proven 100% correct. I'd be curious to know how many actually exist.
qmail. djbdns.
It doesn't happen in NT because there is not a fixed size resource area for storing GDI information. This is why you can have 256+ megs of ram on Windows 98, only have open a few small but resource intensive programs (like C++Builder), and still run out of "system resources".
directNIC.com is $15 and has nice features like free hosting, paid DNS and paid POP3 email accounts. They also have the best interface I've ever seen for a registrar. They make it really easy to mange lots of domains (even hundreds), which is really nice if you have more than a couple domains. Transfering your domain to them or another registrar is a painless process that doesn't involve the original registrar.
That's only for trademarks, not patents.
By default, tinydns does not hand out referrals to questions it is asked about zones it does not control. I believe that this violates the spirt of the RFCs, if not the letter.
Right, there's another tool for that, dnscache. It isn't monolithic like BIND, in the spirit of unix.
By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt of the RFCs, as well as the letter (if a DNS query via UDP results in truncation, you're supposed to re-do the query using TCP instead). Indeed, if you want to support TCP under tinydns, you have to configure an optional program called "axfrdns", which was intended to handle zone transfers, but also happens to share the same database as tinydns, and can handle generic TCP queries.
What's your proof of this? DNS is designed to use UDP. No data should be longer than what fits in a normal UDP response.
The suggested method for copying contents of DNS zones is rsync, scp, or other remote copy tools. The DNS standard method of zone transfers (query type "axfr") is only supported as an additional, disrecommended method. The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed. Contrariwise, if you use the standard zone transfer mechanism, then the zone transfer should fail if the master is munged, and the slaves should keep a good working copy for a while and give you time to notice that the master is munged and needs to be fixed.
If you read his comments on this, then it makes perfect sense. There are already existing, secure tools that do the job better. No need to invent another bloated and potentially buggy and insecure protocol. How often do you corrupt the database, or mess up an rsync or rcp? In any case, when do you not have a backup of your zone files?
Without a patch from a third party, tinydns does not support the standard "NOTIFY" protocol of informing secondary nameservers that the zone has been updated, and that they need to check the SOA serial number and download a new copy (if they don't already have it).
If you use the (better) transfer method that he recommends, this isn't a problem.
Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server. While this is not the recommended mode of configuration, some sites don't have the luxury of having separate authoritative-only and caching/recursive-only server(s), and need to mix them both on one machine (or set of machines). With the BIND 9 "view" mechanism, this is relatively easy to do. With djbdns, this is impossible.
So run put two IP addresses on the machine, and run them on different IP's.
There aren't even any patches that can get djbdns to implement TSIG, Dynamic DNS, or DNSSEC, nor are they ever likely to be created (my understanding is that the author is strongly opposed to them). Unfortunately, as time goes on and more and more people are doing things like IPv6, VPNs based on IPSec, or people just care about being able to cryptographically prove that their servers are handing out the only correct information and that the clients are able to cryptographically verify this fact (think: electronic banking), these kinds of features are going to become ever more commonplace. Note that, with the advent of BIND 9, you can create a caching-only server that will validate cryptographically signed records, and all clients can benefit even if they do not themselves implement any of the new DNSSEC features.
If you read his page about DNS forgery, then you'd see why he is against it.
There are a number of things that djbdns does which I believe to be outright bugs. However, the author of this package simply refuses to accept that his code could be anything less than 100% perfect, and while he claims to have a "bounty" that he will pay for any bug that is found, in reality he is the one that gets to define what he accepts as a "bug", and has repeatedly demonstrated a tendancy to openly refuse to accept some purported bug, but then to quietly fix the code with future releases.
What code doesn't have bugs? Is he supposed to test it indefinitely, and never release for fear of there being some obscure bug that didn't affect him when testing? There is a difference between bugs and security holes. As far as I know, none of his code has ever had security holes. He clearly seems to know what he is doing, and has right to gripe about programs like BIND and Sendmail being buggy. His guarantee is for security holes. I don't see other software making any sort of guarantee. If Microsoft offered $500 for every security hole, would they still be in business? If you check securityfocus.com, the only problem ever reported is a DoS attack against qmail on something that the OS should provide (resource limits).
One argument frequently used to support the use of djbdns over BIND is performance.
So there aren't any real published benchmarks? We don't have nearly that kind of traffic, so I can't say anything about it personally. Also, tinydns is not a cache, so it should not be used for heavily loaded servers. That is what dnscache is for. If you read the blurbs, you'll see someone who found that dnscache outperforms BIND 9. If you use his tools the way they are designed to be used, you'll find they work quite well.
Unfortunately, a lot of the reasons the author gives for running djbdns instead of BIND are related to problems in older versions of BIND which have been fixed or are largely non-issues in later releases of BIND 9.
BIND 9 was not out when djbdns was written, so it makes sense that he would address issues that existed when it was written. Perhaps they actually addressed some of these in BIND 9 due to djbdns? It is very likely that BIND 9 will have the same types of bugs that all the other versions do. Read his papaper for more details. BIND is huge, and takes up a lot of resources. We have servers running BIND that take minutes to load, and use 40-80 megs of ram.
We use MySQL in conjunction with djbdns. We just have a simple daemon that runs and every so often checks the database to see if anything has changed. If it has, it writes out new files, runs the program to convert it to djbdns format, and off it goes. Very quick, very easy, very effective. And it doesn't suck up 80 megs of ram like BIND does when you have lots of zones.
As was pointed out above, apt-get is not the package manager. apt-get is the front end to Debian's package manager, dpkg.
Or maybe, just maybe, the cost to rectify the situation through legal channels just isn't worth it. By costs, I mean time invested (several hours at a minimum), financial costs and the frustration of dealing with the system. Couple that with the fact that you don't know if you're actually going to get your money back, let alone any compensation for having to fight the system and all the heart-ache, its little wonder that most people don't resort to doing the right thing. Just because you're morally right, doesn't mean the system is going to back you up.
So you should not do anything, and let them get away with screwing over yourself and others? That's the purpose of small claim's court. It costs a small fee to file a claim, but in most cases it's worthwhile. If the business is not located in the same area where you live, then they must pay the expense to send someone to represent them, in addition to paying that person. For a small amount like $60, that cost alone will be higher than the amount you are suing over. I would imagine in most cases, they would pay you rather than going through the unnecessary expense.That's completely false. How many programs do you have that you wish were faster? If you can notice how long it takes for a program to do something, then it's not fast enough. Wouldn't you like your Perl or PHP scripts to run faster? Should you have to rewrite them in assembly? Isn't it better to recompile the interpreter with a better compiler than write it or the scripts in assembly?
Or it could be short for Christopher...
Before I waste 20 minutes looking for a mirror, can anybody tell me if they've included any new maps? That one they have really sucks after like the 10th time you play it so I haven't touched the game since the week it came out.
Really needs more maps.
It's an engine test, not a demo. They will more than likely release a demo shortly before the final version is released, just like with Quake III. The test isn't supposed to reflect final gameplay. It's purpose is to test compatibility and networking code.
"super stable"?
Get Real!
As opposed to just "stable". I'm not the one who came up with the term...Okay, I'm kind of a newbie to Linux. I've been using Linux a little over a month, and I just finished compiling the latest stable 2.4 kernel. Now, tell me again why I'd want to take a step backwards? 2.4 is greater than 2.2.20 according to my math, which means it's better and more recent. So why are they still releasing 2.2? Is there some infighting in the Linux development world or something? Is this type of confusion (releasing 2.2.20 when 2.4 is already out) just one of the costs of the Open Source development methodology? I mean, you never hear about Microsoft releasing Windows 3.12 after Windows 95 is out.
Knowing Slashdot moderators, your comment will probably get modded as troll, but I'll answer anyway. Regarding your Windows example, you are incorrect. This is like Microsoft releasing SP6 for NT 4 after Windows 2000 is released. I'm fairly sure SP6 was released afterwards, but if not, they have still released updates to NT 4 after the release of Windows 2000. Just because a product isn't the latest code base doesn't mean it isn't still being used. Many people are still running NT 4, and need updates, like security fixes. There will still be updates to Windows 2000, even though Windows XP is out.
Even though 2.4 is "stable", it isn't "super stable" yet, and might not be for some time. I would guess that most people running Linux on non SMP production servers are using a 2.2 kernel, simply because it has been tested longer, and known to be stable. Then again, that's why many of us use FreeBSD on our production servers :) At this point, I would use a 2.2 kernel on any product boxes that were going to be running Linux. I've personally had problems with 2.4 on the boxes I use as workstations. For example, 2.4.7 would swap for hours when it ran out of memory. While you'd hope that never happens on a production server, many people can't afford to take that risk.
The current even numbered kernel, in this case 2.4, is the "stable" kernel, and the one behind it, in this case 2.2, is the "super stable" kernel.
How can any distro that dosn't even include pico be considered 'unix-like' ???
If you want pico, you might try nano. It's a GNU clone of pico. Debian doesn't include pine because it's license violates the Debian Free Software Guidelines (DFSG).
True, but these days, if you say you're running Debian, it's implied that you're running Debian unstable. Damn few people run Debian stable, because it's so out of date.
People who use Debian for servers usually run stable. For a server, it's usually more important to have a rock solid setup than to be running the latest and greatest. That's one of the nice things about Debian. It gives you a super stable platform to use for a server, and the latest and greatest for a desktop.
You can write bad code in any language. Assuming you fixed the fprintf() error, then you would get the numbers 0-15 printed in random order, usually different each time the program is run, depending on how the forks are processed.
There is not a single major software market category where open source software has achieved the levels of user adoption currently enjoyed by closed source software. Predicting the death of an opponent that you have barely begun to even scratch suggests some kind of religious zealotry or Messiah complex. It is delusional.
If you believe the Netcraft reports, then Apache would be one such example of an open source product beating closed source products. Apache has over fifty percent market share. It is also an interesting example. Apache could be compared with Windows in many ways. It's design is poor, compared to Zeus, which is in every way a better web server. The decision to continue with multi process/threaded web server is flawed, in my opinion. While the arguments on the mailing lists might have some valid points, they don't hold any water in light of the fact that there is already a web server that does everything that is "too hard" for Apache to do. Many people use Apache, just like many people use Windows, but that doesn't make it the best at what it does.
Would that be TFSnet in the Kansas City area? They had the exact same setup.
Some states like New Mexico help you out in figuring exactly when to go and when to stop. I grew up in the Kansas City area, and for streets with multiple lanes, there would dotted lines between the straight lanes leading up to the light, and solid lines between a straight lane and a turning lane. In New Mexico, there are solid lines between all lanes a certain distance from the light. This marks the "point of no return". If you have entered the solid lines when the light turns yellow, then you keep going, otherwise you stop. These are theoretically marked properly for the speed limit, the length of the intersection and the length of the light. If you aren't used to it, then it seems odd at first, but it is actually very helpful.
Getting people to write clean code is a management issue. You can write clean code in any language, and you can write bad code. Perl has a reputation for encouraging obfuscated code, but if you look at the entries for IOCCC, you might think the same thing about C. The company I work for uses PHP for large ecommerce projects, and I can assure you that PHP doesn't force people to write clean code. If people are going to write bad code, I'd rather it be in a safe language like Perl or PHP, rather than C or C++. Of course, I'd rather not work with people at all that don't have the discipline to write good code :)
The difference in parsing speed isn't that big, and the time it takes to parse a configuration file is usually negligable compared to everything else. You can still do INI style blocks inside XML, even if it's not "proper" XML. Borland C++Builder 5 uses XML for it's project files, but there are still large blocks inside that look like INI files. The advantage of XML is that it's a tree style data structure, where INI is an array. Hence you can do INI in XML, but not vice versa. Plus XML support different encodings as part of the format, which is a big advantage to internationalized apps.
How would that be regulated? Anyone can register a .com, .net. or .org domain now. If you want 10 domains, you'd need to have 10 different companies (say LLC's). But most many companies do this anyway. Domain registrars are in business to make money. They want to sell as many domains as possible. It is not in their interest to make it prohibitive for people to purchase (register) domains.
Google doesn't have blinking, obtrusive ads, and to my knowledge, it never has had them. All of Google's ads are placed neatly on the page, and are easily distinguishable from the regular search results. That's just one of the many reasons why Google rocks.