Slashdot Mirror

To describe something as "middleware" is much the same as describing something as a "vehicle" - you're not telling me whether it's a car, a van, a bus, a lorry, a boat, ship, plane, &c.

To quote from RFC2768:

Application environment users and programmers see everything below the API as middleware. Networking gurus see anything above IP as middleware. Those working on applications, tools, and mechanisms between these two extremes see it as somewhere between TCP and the API, with some even further classifying middleware into application-specific upper middleware, generic middle middleware, and resource-specific lower middleware.

Lots of things (e.g. Domain Name Service, PKI, Tibco/RendezVous, IBM MQSeries) can be described as "middleware", but DNS is nothing like TIB/RV.

So... Why don't you shut the fuck up, take the nearest heavy object (e.g. your computer monitor), and bludgeon yourself to death with it. That way, the world will be better off and, more importantly, I won't have to read your inane crap on Slashdot anymore.

And I'm in a good mood today... :-)

D.

See the /. posting on the CONRO project, a joint USC/ISI project:
http://slashdot.org/articles/00/12/26/0750248.shtm l

Or go directly to the CONRO Website:
http://www.isi.edu/conro/

-Z

This is not the first slash story about a product like this. There are some great video's of this sort of robot in action, running sin wave's for movement. The originial /. story here. And the CONRO original site which has some interesting videos if you have the bandwith to download them here.

This got my attention, so I checked it out. There are some movies on that page ranging from 6 megs up to over 60 megs. Definitely high bandwidth material. Not too much actual information though.

Of course, there are many obvious jokes and speculations you could go with here. For example, the last thing we need is an army of robots that need their medications

I did find some info elsewhere on the site.

Here is the abstract from one of the PDFs you can download on the Project Information page:

Abstract.

Self-reconfigurable, or metamorphic, robots can change their individual and collective shape and size to meet operational demands.

Since these robots are constructed from a set of autonomous and connectable modules (or agents), control of the robots and coordination among the modules are highly complex and challenging tasks.

The difficulties stem from the fact that all locomotion, perception, and decision making must be distributed among a network of modules.

This network has a dynamic topology, and each individual module has only limited resources in terms of computational power and local information about the topology in its neighborhood.

To meet these challenges, this paper presents a distributed control mechanism inspired by the concept of hormones in biological systems.

We view hormones as broadcast messages that trigger different actions in different modules, and exploit such to coordinate motions and perform reconfiguration in the context of limited communications and dynamic network topologies.

The paper develops a primitive theory of hormone-based control, and reports the experimental results of applying such a control mechanism to our CONRO metamorphic robots, along with the results of simulations.

This got my attention, so I checked it out. There are some movies on that page ranging from 6 megs up to over 60 megs. Definitely high bandwidth material. Not too much actual information though.

Of course, there are many obvious jokes and speculations you could go with here. For example, the last thing we need is an army of robots that need their medications

I did find some info elsewhere on the site.

Here is the abstract from one of the PDFs you can download on the Project Information page:

Abstract.

Self-reconfigurable, or metamorphic, robots can change their individual and collective shape and size to meet operational demands.

Since these robots are constructed from a set of autonomous and connectable modules (or agents), control of the robots and coordination among the modules are highly complex and challenging tasks.

The difficulties stem from the fact that all locomotion, perception, and decision making must be distributed among a network of modules.

This network has a dynamic topology, and each individual module has only limited resources in terms of computational power and local information about the topology in its neighborhood.

To meet these challenges, this paper presents a distributed control mechanism inspired by the concept of hormones in biological systems.

We view hormones as broadcast messages that trigger different actions in different modules, and exploit such to coordinate motions and perform reconfiguration in the context of limited communications and dynamic network topologies.

The paper develops a primitive theory of hormone-based control, and reports the experimental results of applying such a control mechanism to our CONRO metamorphic robots, along with the results of simulations.

IPv6 already has a similar scheme to area codes; the address space is divided in a hierarchial fashion and delegated to regional authorities. RFC 1881 has more information on the address space for IPv6.

Would IPv6 also qualify as prior art for the patents they have pending?

From the port list at http://www.isi.edu/in-notes/iana/assignments/port- numbers

• dls 2047/tcp
• dls 2047/udp
• dls-monitor 2048/tcp
• dls-monitor 2048/udp

• A DLS server is a Dynamic Lookup Service server that is used by Netscape Conference to find out who's logged on to to a particular audioconference or videoconference.

  No trojans use those ports as far as I know. Maybe some l33t hax0r has a script that hacks a DLS server for some reason?

People, IME, tend to be good at associating names with things and less good at associating numbers-- which is why we name, rather than number, files... and cities and computers and children. (The only exception is the telephone system, and even there, people advertise using names of the form 1-800-FOOBAR-7.) I think we'd be losing something valuable if we changed names to numbers:

• ever worked at a site which names its machines things like mercury, phoenix, orion, or charon , as opposed to say, mac1 or pc177? and tried to remember which machine was which?
• Remember FidoNet addresses and how much harder they were to remember than DNS names?

And so we rather than try to resolve the dispute, we decide they're not to be trusted with it, and lose all this? Such a move would be restricting easy access to the net to those of us who are trained to find it easy to work with and remember apparently random strings of digits. Yes, your solution works... but it appears to be throwing the baby out with the bathwater.

I agree.

IP v6 gives a whole new meaning to

• RFC 2324 (Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0))
• RFC 2325 (Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2...)

I agree.

IP v6 gives a whole new meaning to

• RFC 2324 (Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0))
• RFC 2325 (Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2...)

Theoretically, if you send all the requests at the beginning of the connection, you can reduce that latency. However you still have a minimum added latency of 2.25 seconds, ...

... and it's questionable whether or not you can do that with current browsers (I personally don't know).

Actually I'm well aware that there will be an optional method, eventually, for masking MAC addresses in IPv6, although last I checked a few months ago it wasn't final yet and no one seemed in a great rush...and no one held up IPv6 to wait for this fix to be part of the rollout.

And I'm also aware that because it will not be the default, very few folk will use it; most folk will therefore have their true MAC address visible. Your comment is therefore not only snide but thoroughly misleading in terms of the practical effect on the privacy of not just average AOL users, but most people. I discuss all this and a great deal more about privacy in a recent article on privacy and the law (Note: article is in .pdf but a crude HTML of an earlier draft is available here)& lt;/P>

This can cause a good amount of confusion, as I'm not even sure if the protocol was named for the level or the level was named for the first wide-spread protocol to operate at that level (which was IPv4, or Internet Protocol Version 4). To add to this confusion, they decided to open up the first protocol at version 4 and leave versions 1-3 unassigned. The list of assigned "Internet Protocol" versions is available from IANA's Protocol/Number Assignments Directory.

NAT was originally coded by Allen Thompson, for Linux.

Hardly. It was written as RFC 1631 in 1994 by some wackos from Cray.

The goatsex technical archive has more information.

What you've really got is a way to display 4 dimensions of data (3D plus color).

Actually, brightness also works ... check outlavaps for a nice example of this.

One of the biggest "additions" to IPv6 that supposedly makes it more secure if IPSec. Everybody touts this as being the big solution. However, if you take a look at IPSec, it doesn't necessarily have anything to do with IPv6. It was designed for, and works with, both IPv4 as well as IPv6. If you're interested, check out the RFC here. In section 2, it supports what I just claimed.

If you are interested in hearing more of my rants on IPv6, check out my article over at Hellyeah.com. Also, while you're there, check out a reply to my article that, in my opinion, does point out some of the good parts of IPv6, but doesn't directly address my points.

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

Freenet is good, it came up with some pretty neat ideas, but it would be better if it had been developped and thought out in advance in the context of an IETF working group, if the specifications had been released as a Request For Comments, and, in other words, if it had paid a little more attention to existing Internet standards instead of being Yet Another anti-censorship system.

For example, why did Freenet have to come up with their own key scheme instead of using the official standard of Uniform Resource Names (URNs) defined by RFC2141 (the previous link was an example of a URN)?

I have this dream of a true world-wide distributed database founded on recognized Internet standards. It would use URNs as keys. (In particular, it would allow arbitrary Unicode character data.) It would use the ubiquitous RDF format as "semantic sugar" (pardon the expression) of its communications. It would borrow ideas from HTTP (the best Internet communications protocol we have so far) for the protocol, and Usenet and Freenet for the distribution mechanisms, as well as the public key distribution system and trust web, and the everything system. It would use public-key cryptography as the basis for its trust graph, so as to make data authentification possible and tampering impossible. Certificates and signatures would be distributed along the network itself. It would employ secret sharing mechanisms to split the risks of carrying certain data. It would be impossible to tamper with, impossible to censor, and extremely difficult to break. It would replace the lousy and obsolete DNS system (and also alleviate somewhat the power of "root registrars" in the DNS), and possibly The Web itself. And, to make my dream even more of a dream, it would be simple to implement.

Hmmm.... Nice project, for the year 2100 or so. Anyone care to start an IETF working group?

you should probably refer to rfc1918 instead. It obsoletes 1597.

The "Internet" didn't exist in 1980.

Try again. Have a look at RFC675. Read the title carefully. Notice the date? December 1974. AFAIK that's the first known occurrence of the word "Internet".

In September 1981, RFCs 791, 792 and 793 appeared, defining IP, ICMP and TCP (note the "I" in "IP") in the final version which is still theirs today (minor options and exceptions nonwithstanding).

There is nothing wrong with having been using the Internet for nearly ten years in 1990.

In fact, even though the word hadn't appeared yet, the "official birthday" of the Internet is generally taken to be April 7, 1969, the day of publication of the very first RFC by Steve Crocker. See "Thirty years of RFCs" for more historical considerations, and also the the Internet timeline.

The "Internet" didn't exist in 1980.

Try again. Have a look at RFC675. Read the title carefully. Notice the date? December 1974. AFAIK that's the first known occurrence of the word "Internet".

In September 1981, RFCs 791, 792 and 793 appeared, defining IP, ICMP and TCP (note the "I" in "IP") in the final version which is still theirs today (minor options and exceptions nonwithstanding).

There is nothing wrong with having been using the Internet for nearly ten years in 1990.

In fact, even though the word hadn't appeared yet, the "official birthday" of the Internet is generally taken to be April 7, 1969, the day of publication of the very first RFC by Steve Crocker. See "Thirty years of RFCs" for more historical considerations, and also the the Internet timeline.

The "Internet" didn't exist in 1980.

Try again. Have a look at RFC675. Read the title carefully. Notice the date? December 1974. AFAIK that's the first known occurrence of the word "Internet".

In September 1981, RFCs 791, 792 and 793 appeared, defining IP, ICMP and TCP (note the "I" in "IP") in the final version which is still theirs today (minor options and exceptions nonwithstanding).

There is nothing wrong with having been using the Internet for nearly ten years in 1990.

In fact, even though the word hadn't appeared yet, the "official birthday" of the Internet is generally taken to be April 7, 1969, the day of publication of the very first RFC by Steve Crocker. See "Thirty years of RFCs" for more historical considerations, and also the the Internet timeline.

The "Internet" didn't exist in 1980.

Try again. Have a look at RFC675. Read the title carefully. Notice the date? December 1974. AFAIK that's the first known occurrence of the word "Internet".

In September 1981, RFCs 791, 792 and 793 appeared, defining IP, ICMP and TCP (note the "I" in "IP") in the final version which is still theirs today (minor options and exceptions nonwithstanding).

There is nothing wrong with having been using the Internet for nearly ten years in 1990.

In fact, even though the word hadn't appeared yet, the "official birthday" of the Internet is generally taken to be April 7, 1969, the day of publication of the very first RFC by Steve Crocker. See "Thirty years of RFCs" for more historical considerations, and also the the Internet timeline.

The "Internet" didn't exist in 1980.

Try again. Have a look at RFC675. Read the title carefully. Notice the date? December 1974. AFAIK that's the first known occurrence of the word "Internet".

In September 1981, RFCs 791, 792 and 793 appeared, defining IP, ICMP and TCP (note the "I" in "IP") in the final version which is still theirs today (minor options and exceptions nonwithstanding).

There is nothing wrong with having been using the Internet for nearly ten years in 1990.

In fact, even though the word hadn't appeared yet, the "official birthday" of the Internet is generally taken to be April 7, 1969, the day of publication of the very first RFC by Steve Crocker. See "Thirty years of RFCs" for more historical considerations, and also the the Internet timeline.

The "Internet" didn't exist in 1980.

Try again. Have a look at RFC675. Read the title carefully. Notice the date? December 1974. AFAIK that's the first known occurrence of the word "Internet".

In September 1981, RFCs 791, 792 and 793 appeared, defining IP, ICMP and TCP (note the "I" in "IP") in the final version which is still theirs today (minor options and exceptions nonwithstanding).

There is nothing wrong with having been using the Internet for nearly ten years in 1990.

In fact, even though the word hadn't appeared yet, the "official birthday" of the Internet is generally taken to be April 7, 1969, the day of publication of the very first RFC by Steve Crocker. See "Thirty years of RFCs" for more historical considerations, and also the the Internet timeline.

The "Internet" didn't exist in 1980.

Try again. Have a look at RFC675. Read the title carefully. Notice the date? December 1974. AFAIK that's the first known occurrence of the word "Internet".

In September 1981, RFCs 791, 792 and 793 appeared, defining IP, ICMP and TCP (note the "I" in "IP") in the final version which is still theirs today (minor options and exceptions nonwithstanding).

There is nothing wrong with having been using the Internet for nearly ten years in 1990.

In fact, even though the word hadn't appeared yet, the "official birthday" of the Internet is generally taken to be April 7, 1969, the day of publication of the very first RFC by Steve Crocker. See "Thirty years of RFCs" for more historical considerations, and also the the Internet timeline.

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible.

(my emphasis). If MS had set things up so that the URLs were like http://www.ms.com/redir?news_service_1 , and were switching between providers, then yes I would agree with you that this was a valid argument, but thats not what they're at.

As long as they dont mess with *my* bookmarks I don't mind, I've never yet felt the need to use the ones supplied by the browser vendors.

Other interesting concepts in IP transport can be found in RFC's 1216, 1217, 1926, and others.

Unfortunately, this seems like (almost) as bad of an idea - and it seems like this might just be for real.

Other interesting concepts in IP transport can be found in RFC's 1216, 1217, 1926, and others.

Unfortunately, this seems like (almost) as bad of an idea - and it seems like this might just be for real.

Other interesting concepts in IP transport can be found in RFC's 1216, 1217, 1926, and others.

Unfortunately, this seems like (almost) as bad of an idea - and it seems like this might just be for real.

Other interesting concepts in IP transport can be found in RFC's 1216, 1217, 1926, and others.

Unfortunately, this seems like (almost) as bad of an idea - and it seems like this might just be for real.

Other interesting concepts in IP transport can be found in RFC's 1216, 1217, 1926, and others.

Unfortunately, this seems like (almost) as bad of an idea - and it seems like this might just be for real.

You may have missed the Pigeon Tunnel as shown in RFC 2549.

Link Here.

Recently I posted this comment mentioning the fact that there's really no reason why a domain such as www..com (you should see two Chinese ideograms meaning "China" between the "www." and the ".com" parts; further, if you click on this link, your browser should open a window telling you that the domain "www..com" does not exist, with the same two Chinese ideograms) doesn't exist.

Let us recall: first, as specified by the HTML specification, every HTML document, no matter what character set it is "encoded" as, is written in the all-englobing Unicode character set. So when you write something like "中国" in HTML, it refers to the Unicode characters (decimal) 20013 and 22269, no matter what the current character encoding and font are. So that's how you write the link text. Second, as for the URL itself, well, although it is not (as far as I know) formally recommended by an Internet standard, it is widely recognized that URLs are written in the UTF-8 encoding format (which is afterward %-encoded into ASCII).

The whole process is described in this Internet Draft ("Internationalized Uniform Resource Identifiers"; WORK IN PROGRESS!) by Larry Masinter and Martin Duerst where the relationship between URIs and IURIs (Internationalized URIs) is discussed in detail.

The DNS is the toughest part of all. The DNS specification (RFC1034) states (section 3.1) that DNS data is to be taken as binary for possible upward compatibility (this was wonderful foresight on Mockapetris' part!). Consequently, there is nothing as per standards wrong with using (UTF-8 encoded Unicode) 8-bit data in DNS labels. Except, of course, that many "buggy" implementations will have to be corrected for broken assumptions, *sigh*. The IDNS working group suggests using a UTF-5 encoding to avoid going beyond the current domain name limits: I think this is not a good thing and we should stick to UTF-8 and repair broken software.

Oh, and incidentally, see this page too know how broken your browser's Unicode support is.

Recently I posted this comment mentioning the fact that there's really no reason why a domain such as www..com (you should see two Chinese ideograms meaning "China" between the "www." and the ".com" parts; further, if you click on this link, your browser should open a window telling you that the domain "www..com" does not exist, with the same two Chinese ideograms) doesn't exist.

Let us recall: first, as specified by the HTML specification, every HTML document, no matter what character set it is "encoded" as, is written in the all-englobing Unicode character set. So when you write something like "中国" in HTML, it refers to the Unicode characters (decimal) 20013 and 22269, no matter what the current character encoding and font are. So that's how you write the link text. Second, as for the URL itself, well, although it is not (as far as I know) formally recommended by an Internet standard, it is widely recognized that URLs are written in the UTF-8 encoding format (which is afterward %-encoded into ASCII).

The whole process is described in this Internet Draft ("Internationalized Uniform Resource Identifiers"; WORK IN PROGRESS!) by Larry Masinter and Martin Duerst where the relationship between URIs and IURIs (Internationalized URIs) is discussed in detail.

The DNS is the toughest part of all. The DNS specification (RFC1034) states (section 3.1) that DNS data is to be taken as binary for possible upward compatibility (this was wonderful foresight on Mockapetris' part!). Consequently, there is nothing as per standards wrong with using (UTF-8 encoded Unicode) 8-bit data in DNS labels. Except, of course, that many "buggy" implementations will have to be corrected for broken assumptions, *sigh*. The IDNS working group suggests using a UTF-5 encoding to avoid going beyond the current domain name limits: I think this is not a good thing and we should stick to UTF-8 and repair broken software.

Oh, and incidentally, see this page too know how broken your browser's Unicode support is.

Recently I posted this comment mentioning the fact that there's really no reason why a domain such as www..com (you should see two Chinese ideograms meaning "China" between the "www." and the ".com" parts; further, if you click on this link, your browser should open a window telling you that the domain "www..com" does not exist, with the same two Chinese ideograms) doesn't exist.

Let us recall: first, as specified by the HTML specification, every HTML document, no matter what character set it is "encoded" as, is written in the all-englobing Unicode character set. So when you write something like "中国" in HTML, it refers to the Unicode characters (decimal) 20013 and 22269, no matter what the current character encoding and font are. So that's how you write the link text. Second, as for the URL itself, well, although it is not (as far as I know) formally recommended by an Internet standard, it is widely recognized that URLs are written in the UTF-8 encoding format (which is afterward %-encoded into ASCII).

The whole process is described in this Internet Draft ("Internationalized Uniform Resource Identifiers"; WORK IN PROGRESS!) by Larry Masinter and Martin Duerst where the relationship between URIs and IURIs (Internationalized URIs) is discussed in detail.

The DNS is the toughest part of all. The DNS specification (RFC1034) states (section 3.1) that DNS data is to be taken as binary for possible upward compatibility (this was wonderful foresight on Mockapetris' part!). Consequently, there is nothing as per standards wrong with using (UTF-8 encoded Unicode) 8-bit data in DNS labels. Except, of course, that many "buggy" implementations will have to be corrected for broken assumptions, *sigh*. The IDNS working group suggests using a UTF-5 encoding to avoid going beyond the current domain name limits: I think this is not a good thing and we should stick to UTF-8 and repair broken software.

Oh, and incidentally, see this page too know how broken your browser's Unicode support is.

It shouldn't, at all.

GPG is based on the OpenPGP standard ( RFC 2440 ) which doesn't, AFAIK, include "Key Escrow" or "ADK". PGP seemes to have "added" this feature, perhaps this is what the mean by "multiple recipents" in the E-business product.

Of course I could be wrong, but that's the way it looks to me :)

Can a flock of birds take down a network by flying through the lasers?

Maybe they could adapt RFC 1149 - A Standard for the Transmission of IP Datagrams on Avian Carriers and, instead of seeing the birds as a potential problem, use them as carriers. Sure, a device would have to print the scrolls of paper, and attach it to the birds. It would probably decrease bandwidth, as the mentioned RFC mentions: "Avian carriers can provide high delay, low throughput, and low altitude service.". It's worth a good read.

To deal with this, they could also use RFC 2549 - IP over Avian Carriers with Quality of Service .

Can a flock of birds take down a network by flying through the lasers?

Maybe they could adapt RFC 1149 - A Standard for the Transmission of IP Datagrams on Avian Carriers and, instead of seeing the birds as a potential problem, use them as carriers. Sure, a device would have to print the scrolls of paper, and attach it to the birds. It would probably decrease bandwidth, as the mentioned RFC mentions: "Avian carriers can provide high delay, low throughput, and low altitude service.". It's worth a good read.

To deal with this, they could also use RFC 2549 - IP over Avian Carriers with Quality of Service .

For more ports go to: http://www.isi.edu/in-not es/iana/assignments/port-numbers

Can't you tunnel your VPN traffic over ssh or something? Tell ssh to forward port 50 on the local machine to port 50 on some remote machine, and the remote machine then continues the VPNing.

Can't you tunnel your VPN traffic over ssh or something? Tell ssh to forward port 50 on the local machine to port 50 on some remote machine, and the remote machine then continues the VPNing.

This is all dealt with in RFC 2267: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing

See RFC2827 , which describes the Best Current Practice for doing Ingress Filtering. Just the thing needed to block most of the DDoS attacks.

What if just starts resizing images that are part of attachments? It could even be a part of some fun policy. [authoritative voice] Due to network bandwidth concerns, we sometimes strip image attachments, shrink them, and then reattach them for you to help the internet work better[/authoritative voice]. I realize that you can use steganography on any kind of binary file, just pointing out that they could still do something about it.

And as for China controlling all data in and out of the country, implement A Standard for the Transmission of IP Datagrams on Avian Carriers. So the government would have to add guards along all the borders to shoot down any bird with something on its leg. It would be slow, and the ACK times (horrible pun intended) would probably be a little long, but it could work.

See RFC 1876: "A Means for Expressing Location Information in the Domain Name System." Using geographic information to establish a domain, as opposed to vice-versa, seems unnecessary. (At least, *I* can't think of any applications.)

Your comment is completely false. The Internet is transparent upon the networking medium

Just to reinforce this statement, I'd like to remember there's RFC 1149 regarding Transmission of IP Datagrams on Avian Carriers, i.e. pigeons. It's worth reading :) Of course it was posted on April 1st, but it's technically correct.

There's also an amendment, RFC 2549 that adds QOS to Avian Carriers.

Your comment is completely false. The Internet is transparent upon the networking medium

Just to reinforce this statement, I'd like to remember there's RFC 1149 regarding Transmission of IP Datagrams on Avian Carriers, i.e. pigeons. It's worth reading :) Of course it was posted on April 1st, but it's technically correct.

There's also an amendment, RFC 2549 that adds QOS to Avian Carriers.

Your comment is completely false. The Internet is transparent upon the networking medium. Take a look at RFC1011 "Official Internet Protocols". Basically, IP is used to handle getting a packet somewhere (routing et cetra), and transmission protocols like TCP/UDP are used to handle transfering of data via packets.

TCP/IP does not define any standard protocols in the OSI "Physical" layer. This is the job of the physical network medium itself. In fact, IP has a Maximum Transmission Unit field to specify the maximum transmission or receive unit of the underlying medium -- in other words, how much the given medium can send at a time. Ethernet, being the most common on the Internet, has a MTU of 1500 but this is no means the only possible networking media.

The Internet can and will adapt to any media, even something as unreliable as two cans and a tight string. TCP provides reliability services, allowing the Internet to run on anything -- even a noisy phone line.

Every major web browsers support Gopher, there's no reason not to use it. Gopher pages tend to be more content-rich than web pages -- Gopher simply does not allow Zero-Content sludge.

I see useless web sites all the time. Some newbie puts together a page with links to a few well-known web sites and publishes the trash on the World Wide Web, usually using a free web hosting service. Apatheticy to follow the HTML standards, unreadable fonts, annoying security JavaScript/VBScript/ActiveX/Java security holes, and eye burning colors are what make most of the web so ugly.

Admittedly, the World Wide Web is much more flexible and powerful than Gopher. Gopher is inferior to WWW. However, with power comes resposibility. ~99% of all web publishers are not resposible enough to follow the standards and make operable pages. Too many web pages suck.

Gopher does not give the publisher power to publish pages that suck. Gopher's directory listing makes this simply not possible. Of course, someone could host a Gopher site listing nothing, but what would be the point of that? I have never connected to a horrible Gopher site, and I have connected to thousands of horrible WWW sites.

Gopher serves what matters -- pure information. The original version of Gopher, now sometimes known as Gopher0, supports only a few data types, the most frequently used being text. (Gopher+ uses MIME content types, however). What other content types do you need than text? On the other hand, the World Wide Web is able to represent tables, frames, links, and many other useless features. Gopher is so simple and unbloated unlike HTML and the WWW.

The WWW sucks, because it can. Gopher will never suck.

The question is, will Gopher take off? Not a chance. Gopher will remain used by a select few, unlike the WWW. It will never have the trillions of zero content "homepages" and commericialization the WWW has. And frankly, I like it that way. Ever seen an advertisement on a Gopher server?