Slashdot Mirror

A bit surprised to hear that 'Hierarchical databases were blown away by relational versions' - since I'm pretty sure they've been paying my pay check for the last three years... :-)

There are a large number of heirarchical databases out there. The big fellas are the X500 directories (X509 certs came out of this work). More common are X500's demented kid sisters, the LDAP directories ( rfc2251). The DNS system also fits the description 'heirarchical database'.

As far as XML goes, there are people storing XML in directories - although they're still fussing about exactly how to do it. There are a bunch of people trying to come up with standards - check the directory services markup language people www.dsml.org.

There are people trying to sell XML enable directories - Novell sells an XML directory, but most directories can be used to store XML (including our 'eTrust Directory').

As a final quicky - when do you use a directory over an RDBMS? Directories are good for naturally heirarchical data with few cross connections. They are usually optimised for slow writes/fast reads. They are *very* good for distributed data (e.g. DNS, international organisations etc.). The X500 spec defines a very fine grained security model, which can also be useful. However, if your data is closely cross-linked with lots of relationships... well, use an RDBMS!

<RANT>

Why the hell don't people use progressive mode for their JPEGs? Just look at this list of browsers that support progressive JPEG. Just look at it! Do you know anyone who is still using a pre-Netscape 2.0 browser?! Me neither. Must we stay in the stone age forever? Sheesh. People who insist on non-progressive JPEGs are almost as bad as those people who go into conniptions when you send them non-ASCII e-mail.

</RANT>

Just reading some RFCs and FAQs at my favourite site for this and I see that they've lost funding and are asking for donations.

It would be a pity if this site died, as it's a genuinely useful nerd reference info site - if you've ever used it I'd ask you to consider dropping a couple of bucks their way...

Here's the early history of the HP3000.

According to the FAQ, it rather ran iX, you're right, I may have been confused between my HP3000 and the HP9000 that came soon after.

BTW, HP-UX appeared in 1986

• 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.
• 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.
• 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.
• Without a patch from a third party, tinydns does not listen to more than one IP address. If you have a multi-homed server, you have to apply a patch from someone other than they author, before you can get it to listen on more than one address/interface.
• 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).
• Without a third party patch, tinydns does not support standard SRV records (which are intended to ultimately replace MX records, as well as perform similar functions for services other than mail).
• Like tinydns, dnscache will not bind to more than one IP address without a third party patch.
• 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.
• 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.
• 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.
  So, let's look at some of these bugs:
  • When an IQUERY is sent to a djbdns server, it will respond with opcode set to QUERY. (it should simply copy the opcode, not make something up).
  • DNSCACHE (the caching server) does not respond to queries with the RD bit clear in the query. (Instead of simply answering from cache without recursing the dns-tree).
• One argument frequently used to support the use of djbdns over BIND is performance. Upon further investigation, this claim simply does not hold water.
  Benchmarks published by Rick Jones have clearly shown that BIND can scale up to at least 12,000 DNS queries per second, and there is every indication that BIND 9.2 will be able to go considerably higher. The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second, but that is the highest number reported. Other people on the bind-users mailing list have indicated that they have performed their own (as yet unpublished) benchmarks of tinydns, and that it had notable performance problems that BIND did not suffer.
  The best published benchmarks from the author for dnscache report a query handling rate of less than one million records over a 4.5 hour period of time, which works out to an average of less than sixty-two queries per second. Even if you look at numbers of queries per CPU second, the best numbers they can provide are 13.7 million queries over a four week period of time with 128 minutes of CPU time used (an average of slightly less than 1784 queries per CPU second).
  Compare this with the requirement from RFC 2010 "Operational Criteriafor Root Name Servers" (since obsoleted by RFC 2870 "Root Name Server Operational Requirements") is that the machine and software in question be able to handle at least 2000 queries per second, and be scalable to levels higher than that. Indeed, recent reports have indicated that a.root-servers.net (considered by many to be the "primary" root nameserver) is currently handling around 12,000 DNS queries per second at peak.
  Preliminary benchmarks published on the bind-users mailing list have indicated that, on the same hardware, there is little or no performance benefit to using dnscache as opposed to BIND 9.1.2, and when these tests are re-run with BIND 9.2, I'm sure that it will come out even faster.
• 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.
  For example, he makes a big point of tinydns being better than BIND, because while the process is starting up, it still answers queries. While previous versions of BIND would not answer queries during startup, this is no longer a problem with BIND 9.
  Dan also makes a great deal of the fact that the djbdns tools run as a user other than root, and in chroot() environments. While the "monolithic setuid root" situation was an issue with older versions of BIND, even more recent releases of BIND 8 could be easily run as a non-priviledged user in a chroot() environment, and this is the preferred method of running BIND 9.
  Contrariwise, one of the legitimate big complaints about older versions of BIND is that they implemented zone transfers in a separate program. If the database was large, then the fork()/exec() overhead was large, and the system could seriously thrash itself to death as it copied all those pages (for systems without copy-on-write), only to immediately throw them away again when it fired up the named-xfer program. With BIND 9, this problem is solved by having a separate thread inside the server handling zone transfers, and no fork()/exec() is done. However, tinydns/axfrdns goes back to the fork()/exec() model that was so greatly despised.

Suffice it to say that there is absolutely nothing that djbdns does that I believe can't be done at least as well (or considerably better) with BIND, and there are no security benefits it provides that cannot be provided at least as well (or much better) by a proper installation of a modern version of BIND.

I believe in the "security through diversity" scheme as much as anyone, but I'd take root nameservers running a program written in Bourne shell over djbdns. Hell, I'd rather fall back to using HOSTS.TXT than use djbdns.

Unfortunately, the other alternative of DENTS is also unsuitable for use as a production nameserver.

Show me something that is sufficiently better than BIND (and open source), and I'm sure that everyone will quickly gravitate towards it. Until then, BIND is the best we've got.

• 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.
• 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.
• 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.
• Without a patch from a third party, tinydns does not listen to more than one IP address. If you have a multi-homed server, you have to apply a patch from someone other than they author, before you can get it to listen on more than one address/interface.
• 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).
• Without a third party patch, tinydns does not support standard SRV records (which are intended to ultimately replace MX records, as well as perform similar functions for services other than mail).
• Like tinydns, dnscache will not bind to more than one IP address without a third party patch.
• 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.
• 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.
• 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.
  So, let's look at some of these bugs:
  • When an IQUERY is sent to a djbdns server, it will respond with opcode set to QUERY. (it should simply copy the opcode, not make something up).
  • DNSCACHE (the caching server) does not respond to queries with the RD bit clear in the query. (Instead of simply answering from cache without recursing the dns-tree).
• One argument frequently used to support the use of djbdns over BIND is performance. Upon further investigation, this claim simply does not hold water.
  Benchmarks published by Rick Jones have clearly shown that BIND can scale up to at least 12,000 DNS queries per second, and there is every indication that BIND 9.2 will be able to go considerably higher. The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second, but that is the highest number reported. Other people on the bind-users mailing list have indicated that they have performed their own (as yet unpublished) benchmarks of tinydns, and that it had notable performance problems that BIND did not suffer.
  The best published benchmarks from the author for dnscache report a query handling rate of less than one million records over a 4.5 hour period of time, which works out to an average of less than sixty-two queries per second. Even if you look at numbers of queries per CPU second, the best numbers they can provide are 13.7 million queries over a four week period of time with 128 minutes of CPU time used (an average of slightly less than 1784 queries per CPU second).
  Compare this with the requirement from RFC 2010 "Operational Criteriafor Root Name Servers" (since obsoleted by RFC 2870 "Root Name Server Operational Requirements") is that the machine and software in question be able to handle at least 2000 queries per second, and be scalable to levels higher than that. Indeed, recent reports have indicated that a.root-servers.net (considered by many to be the "primary" root nameserver) is currently handling around 12,000 DNS queries per second at peak.
  Preliminary benchmarks published on the bind-users mailing list have indicated that, on the same hardware, there is little or no performance benefit to using dnscache as opposed to BIND 9.1.2, and when these tests are re-run with BIND 9.2, I'm sure that it will come out even faster.
• 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.
  For example, he makes a big point of tinydns being better than BIND, because while the process is starting up, it still answers queries. While previous versions of BIND would not answer queries during startup, this is no longer a problem with BIND 9.
  Dan also makes a great deal of the fact that the djbdns tools run as a user other than root, and in chroot() environments. While the "monolithic setuid root" situation was an issue with older versions of BIND, even more recent releases of BIND 8 could be easily run as a non-priviledged user in a chroot() environment, and this is the preferred method of running BIND 9.
  Contrariwise, one of the legitimate big complaints about older versions of BIND is that they implemented zone transfers in a separate program. If the database was large, then the fork()/exec() overhead was large, and the system could seriously thrash itself to death as it copied all those pages (for systems without copy-on-write), only to immediately throw them away again when it fired up the named-xfer program. With BIND 9, this problem is solved by having a separate thread inside the server handling zone transfers, and no fork()/exec() is done. However, tinydns/axfrdns goes back to the fork()/exec() model that was so greatly despised.

Suffice it to say that there is absolutely nothing that djbdns does that I believe can't be done at least as well (or considerably better) with BIND, and there are no security benefits it provides that cannot be provided at least as well (or much better) by a proper installation of a modern version of BIND.

I believe in the "security through diversity" scheme as much as anyone, but I'd take root nameservers running a program written in Bourne shell over djbdns. Hell, I'd rather fall back to using HOSTS.TXT than use djbdns.

Unfortunately, the other alternative of DENTS is also unsuitable for use as a production nameserver.

Show me something that is sufficiently better than BIND (and open source), and I'm sure that everyone will quickly gravitate towards it. Until then, BIND is the best we've got.

You should check out the newsgroup alt.sysadmin.recovery. They have a FAQ

It doesn't cost $400m to launch a shuttle. The incremental per-launch cost is $150 million US. Other numbers that attempt to amortize the total cost of the program and non-shuttle-specific support facilities come up with higher numbers but they are suspect. Another false estimate comes from taking the total shuttle budget for a given fiscal year and dividing it by the number of launches. Of course NASA is a political agency so depending on what their policy goal is you'll hear different numbers from, but in this article there is no source stated for the cost figure.
See SPACE SHUTTLE MISSION COSTS in the sci.space FAQ controversy section.

• Another possible solution to this problem is the transformation of what is effectively a public good into a private one. This can be accomplished by setting up a market based architecture that allows peers to buy and sell computer processing resources, very much in the spirit in which Spawn was created

Actually, if you run into the "tragedy of the commons" problem, it's usually because the protocol mishandles scaling. See my ancient RFC 970, where I pointed this out back in 1985. Gnutilla is generally acknowledged to have scaling problems.

As for the economic analysis, market enthusiasts tend to ignore that markets both increase transaction costs and consume attention. Some goods are too cheap to charge for, because the costs of pricing, charging, billing, accounting, advertising, and marketing exceed the cost of the goods themselves. This is why the Internet beat out the pay-per-bit services.

Worse, there's the problem of limited attention. If something is charged for, the buyer has to pay attention to its cost and how much they're using. That attention is a limited resource, and people hate wasting it on little stuff. This is why consumer Internet services moved from per-hour to flat rate.

No. Lossless JPEGs typically reduce a file size by about a factor of two. Given that the "SHQ" pics are much more compressed than that, one can assume that they are not lossless JPEGs--though it's evident enough by simply comparing pictures side-by-side that the so-called super high quality setting produces pictures of lower quality than TIFFs.

Also don't confuse "lossless JPEG" with simply setting the compression slider in Photoshop or whatever to the highest-quality/least compression setting. They are two quite different things.

Lastly, from the JPEG FAQ:

Lossless JPEG has never been popular --- in fact, no common applications support it --- and it is now largely obsolete. (For example, the new PNG standard outcompresses lossless JPEG on most images.) Recognizing this, the ISO JPEG committee recently finished an all-new lossless compression standard called JPEG-LS (you may have also heard of it under the name LOCO). JPEG-LS gives better compression than original lossless JPEG, but still nowhere near what you can get with a lossy method. It's anybody's guess whether this new standard will achieve any popularity.

And you'd be surprised: some photographers are nearly as bright as you. :)

Remember FSP, the "File Server Protocol". It was introduced about 10 years ago and was supposed to be the FTP-killer. Technically it probably was superior, but good ol' FTP was available everywhere and was good enough. Today you'd be hard-pressed to find any FSP sites at all. The last published version of the FSP FAQ appears to be dated 1996-08-19. It seems there's really no demand for a better FTP.

This is called IFF format. It was invented by Electronic Arts in 1985 and used by Amiga OS for audio files (AIFF). It was the first portable interchange format, predating XML by over a decade.

I've personally used IFF in years past to great advantage where XML was bulky or wasteful or didn't exist yet. That's one of the reasons I haven't gotten a stiffy over XML, because the problem was largely addressed prior, only it was missing standardized attributes retrieval and arbitrary length tag names. As a format for speedy reading, it's almost unbeatable (with a couple of logical conventions for data formats).

What are you talking about? Please locate any occurence of "Microsoft" in Section 5 of the below document:
RFC1541

Problem is that apparently SPA in Outlook is an MS specific thing. Well, what do you want them to do. The only way for outlook to support not sending the login in cleartext is to use SPA.

What about RFC 1734 and 2095?

Basically all that needs to be done is for other mail clients to support MS SPA

This is where the problem is. There are existing protocols to deal with secure POP/IMAP authenticaion, but MS goes ahead and writes their own, and then people say "why doesn't everyone just support the Microsoft format" -- it is this line of reasoning that has led to nearly every proprietary closed format/protocol.

If MS doesn't want to pass passwords in cleartext, they should be using one of the existing and open methods of encryption, not forcing other people to use their software.

Problem is that apparently SPA in Outlook is an MS specific thing. Well, what do you want them to do. The only way for outlook to support not sending the login in cleartext is to use SPA.

What about RFC 1734 and 2095?

Basically all that needs to be done is for other mail clients to support MS SPA

This is where the problem is. There are existing protocols to deal with secure POP/IMAP authenticaion, but MS goes ahead and writes their own, and then people say "why doesn't everyone just support the Microsoft format" -- it is this line of reasoning that has led to nearly every proprietary closed format/protocol.

If MS doesn't want to pass passwords in cleartext, they should be using one of the existing and open methods of encryption, not forcing other people to use their software.

From the Social Security Number FAQ:

"It's not a good idea to carry your SSN card with you (or other documents
that contain your SSN). If you should lose your wallet or purse, your SSN
would make it easier for a thief to apply for credit in your name or
otherwise fraudulently use your number."

Now imagine if said card also contained or linked to a database containing your fingerprints, facial scans, and DNA sequencing. Better hope you don't ever drop your wallet, or get it stolen.

You're going on the assumption that it's a good thing that they can laways track you. Some people would prefer not to have the government living with them 24 hours a day.

The question is, what benefit does this new card give us? We already have "voluntary" (bleh) id cards of several sorts. What does having this gigantic database accomplish that the current system doesn't? How would this have changed the events of September 11th, and even if it did alter them, was it worth the guy at the airport being able to print out a nice copy of my fingerprint for home use?

-Puk

You meant SPA (Secure Password Authentication), right?

Why SPA, when there is SMTP AUTH [RFC 2554]?

There is no need to create a new propietary protocol . There is a standard way to validate a user using POP3 whitout sending the password in clear text. See RFC 1939 - APOP command

Normally, each POP3 session starts with a USER/PASS exchange. This results in a server/user-id specific password being sent in the clear on the network. For intermittent use of POP3, this may not introduce a sizable risk. However, many POP3 client implementations connect to the POP3 server on a regular basis -- to check for new mail. Further the interval of session initiation may be on the order of five minutes. Hence, the risk of password capture is greatly enhanced.

An alternate method of authentication is required which provides for both origin authentication and replay protection, but which does not involve sending a password in the clear over the network. The APOP command provides this functionality.

And
here's a FAQ explaining why Northern hemisphere monitors don't work so well in the South ....

"it ain't easy bein' green."

And yes, I ment the frog. Not the file transfer protocol.

Ribbit

Kind of like RFC 2549, IP over Avian. Might requrie messing with packet size to work smoothly.

I just learned today that FAQS.org is in financial trouble, too! More here...

I just learned today that FAQS.org is in financial trouble, too! More here...

What's the problem? If you use the UTF-8 encoding
for Unicode, all your data will be ASCII compatible.

ASCII is 7 bit while UTF-8 is 8 bit. You would want UTF-7 to remain ASCII-"compatible" (UTF-7 is defined in RFC 2152).

RFC 432 contains one of the oldest maps of the internet, with only a couple of hosts.

rfc432 in pdf format

First: being released under the GPL is very different from being released in the public domain. I direct you to the Copyright FAQ.

Watcom and gcc will never be a single compiler. Watcom's primary goal is to generate optimum code for the i386/DOS. gcc's goal is to be free and as portable as possible. Many of Watcom's optimisations will most likely find their way into gcc (and DJGPP), but they will remain two distinct projects.

http://groups.google.com/groups?hl=en&as_drrb=b&as _mind=29&as_minm=3&as_miny=1995&as_maxd=10&as_maxm =9&as_maxy=2001&frame=right&th=54ab4d241c34e0cc&se ekm=3b8fd177%40monitor.lanset.com#link1

http://www.247news.net/2001/20010911-towers.shtml

http://www.faqs.org/faqs/nostradamus/part6/ --My friend says that is fake

The AI Mind at http://sourceforge.net/projects/mind/ is a vastly more sophisticated neuronal-mind-workalike than the admittedly most impressive Alicebot, and the SourceForge "Mind" performs many of its quasi-neuronal functions very well, e.g.: storage of input in quasi-auditory memory; re-entry of the output of the Mind back into the Mind; associative cross-tagging of concepts, lexicon and auditory engrams; simple Tutorial; troubleshooting with print-out option; etc.

What the AI Mind at SourceForge does not yet do well is keep track of its concepts, because for two years now (since mid-1999) there has been an algorithmic deficiency in the SPREADACT module for the implementation of the theoretically very important process of spreading activation . That problem or final obstacle to True GOFAI is now being cleared up as we switch from harvesting all active concepts simultaneously in sentence-generation, to an interactive generation by syntax interacting word-by-word between the English lexicon and the underlying Psi concepts at the core of the Mind.

Anyone intensely curious about the very latest Mentifex work may visit http://www.scn.org/~mentifex/mindwork.html to see the AI Mind work-in-progress that has not yet been released because it is not yet stable or otherwise ready. (I hate to do potentially important work and not make it somehow available in the event of, say, my getting run over by a truck.)

Both Alicebot (congratulations!) and the Mentifex AI Mind may claim some recognition for being included in the 5 September 2001 release of the official Artificial Intelligence FAQ at http://www.faqs.org/faqs/ai-faq/general/part6/sect ion-5.html under the "Chatbots" heading. I wish the Alicebot team all the success in the world, because we are working towards the same goal. -- Arthur T. Murray.

As O'Reilly states, WinSock is more a specification, a set of APIs. Anyone could write an implementation. Several did. It just so happens that Peter Tattam wrote the best for Windows 3.1. Also he wrote a scriptable dialer which back in those days was what a lot of people needed to negotiate the hodgepodge of dial-in methods required by the much less consolidated ISP industry. And Tattam gave his package away as shareware so it could spread very fast.

It gets better though from the perspective of an argument against bundling. There were quite frequent warnings as you can see in the alt.winsock FAQ about having the "right" WINSOCK.DLL installed with all others removed. And with the change to Windows 95, I can remember the huge amount of hype over whether one should go "32-bit". Here's a sample from back then which includes advice to simply remove Trumpet Winsock under certain circumstances.

Unfortunately for the opponents of bundling, the problem with this otherwise perfect example is that it is inconceivable that a modern consumer OS would lack either a TCP/IP stack or a dialer. Trumpet Software had the clear market leader. Microsoft in Windows 95 bundled both its own TCP/IP stack and a dialer DUN. This bundling introduced potential incompatibilities that even led for some to advise uninstalling Trumpet's product. So should the government have had the right to force Microsoft to stop invading this software niche? Should it have mattered that Tattam wasn't the head of a much larger company such as Netscape? Should it have mattered that Tattam wasn't American?

By the way, Trumpet Software is currently developing a new 32 bit OS PETROS.

Couldn't be the "fractal" compression creeps again could it? I saw a lecture about the math of it some time ago. The compression seemed quasi-believable, but the de-compression was shrouded in secrecy...

have a look at

this faq

A lot of admins seem to block ICMP at the firewall when they actually shouldn't.

Not that it matters, anyway...

Additionally, the Free Software Foundation is providing GNU-based delivery for full-sized CD sets. Gnus travel more slowly than carrier pigeons, but have the advantage of being able to carry a complete set, reducing the need for retransmissions, and they support for multicasting and parallel processing if you need to ship a whole HURD of the things at once.

There's an interesting bit in the Cray FAQ (which is interesting in its own right) about the display panel on the T3d being a Powerbook.

10. WHAT IS THE SIGNIFICANCE OF THE CHESS GAME?

The chess game between Tyrell and Sebastian uses the conclusion of a game played between Anderssen and Kieseritzky, in London in 1851. It is considered one of the most brilliant games ever played, and is universally known as "The Immortal Game".

The Immortal Game, in algebraic notation, was as follows:

Anderssen - Kieseritzky (London 1851):

1 e4 e5 2 f4 exf4 3 Bc4 Qh4+ 4 Kf1 b5 5 Bxb5 Nf6 6 Nf3 Qh6 7 d3 Nh5 8 Nh4 Qg5 9 Nf5 c6 10 Rg1 cxb5 11 g4 Nf6 12 h4 Qg6 13 h5 Qg5 14 Qf3 Ng8 15 Bxf4 Qf6 16 Nc3 Bc5 17 Nd5 Qxb2 18 Bd6 Qxa1+ 19 Ke2 Bxg1 20 e5 Na6 21 Nxg7+ Kd8 22 Qf6+ Nxf6 23 Be7 Checkmate.

More people need to know this:

The jury has the right to judge the law.

Quoted from here.

Fully Informed Jury Association's 'Jury Power Page'.
Also, Whitten's _Citizen Rule Book_ has good info on your rights and responsibilites as a juror.

When you sit on a Jury, you have more power than as almost under any other capacity as a citizen, 1000 times more power than when you vote. You have more power than the judge, than the legislators, than the police. You have a right and a duty to judge the facts according to the law, AND TO JUDGE THE LAW ITSELF!

Jury Nullification is when a jury nullifies bad law. A jury can say "not guilty" for ANY reason, especially if the jury thinks the person violated a law, but finds that the law was a bad one.

Research what happened to Edward Bushnell, who sat on the jury of William Penn, accused of practicing an illegal religion.

Also research how Jury Nullification helped eliminate prohibition. (Well, of course I mean *alcohol prohibition*. we still have prohibition today, just a different kind!)
-end quote.

Image what a fully informed jury could do for cases like Pavlovish's, Dmitry's, 2600's, etc, etc.

The real reason that PPPoE is used is so you can chose your ISP while maintianing the same DSL, just change your PPPoE settings to point to a different ISP. Personally, I'd sacrifice choice for the use of standard protocols.

:P

There used to be an undocumented CONFIG.SYS setting called SWITCHAR which would change this behaviour. Unfortunately, a lot of programs and dos commands had \ hardcoded in them, so setting SWITCHAR could lead to unpredictable results. For more info see the msdos programmer faq at http://www.faqs.org/faqs/msdos-programmer-faq/part 4/section-19.html

e is Euler's Number. e^(i*pi) is Eulers Formula.

The hardware is not the limitation, so much as our ability to design the software with the complex adaptive ability of the human brain.

It may well be that we'll never be able to design such software.

However, we could evolve it. Using genetic algoriothms and other "evolutionary" programming approaches seems to me the most promising approach.

Tom Swiss | the infamous tms | http://www.infamous.net/

Try FAQs.org. Looks like they have everything HTMLized, much better than the plain text docs.


Enigma

Haven't you ever heard of HTCPCP?

So the real question is, will this make an RFC 3091 protocol happen more rapidly?

Sig: Tell all your friends NOT to download the Advanced Ebook Processor:

So the real question is, will this make an RFC 3091 protocol happen more rapidly?

Sig: Tell all your friends NOT to download the Advanced Ebook Processor:

It eliminates a whole class of headaches caused by using the same port (25) for both outgoing mail from one's own subscribers and for incoming mail from the rest of the world.

There is prior art up and down the Yin Yang on this. this document places the innovation of Kermit in 1981, while RFC 765, describing the FTP protocol, dates back to June 1980.

You also mentioned Unix to Unix Copy Protocol. According to this history of the internet, AT&T labs developed the UUCP suite in 1976.

Or then, the higher court may just be smoking something...

Sometimes, I think the only reason that drugs are illegal is to prevent us from understanding the system. :)

--

RFC959 was issued in 1985 but refers to older documents such as Telnet (RFC854)...
Note this extract from the latter:
"It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation)."
Not quite sure lawyers would be happy with this point, though.
--

Readers of a UK bent might be interested in the latest upgrade to JANET, the Joint Academics Network. This is the primary backbone supplier to (all?) Universities and (some) Further Education Colleges in the UK.

SuperJANET4 currently has a 2.5Gbps SDH optical backbone, rising to 20Gbps in 2002 using DWDM. At various points across the contry are JANET Connection Points (JCPs) to which Metroplitan Area Networks (MANs) are connected: these MANs then supply the universities with bandwidth. These MANs are being upgraded in concert with JANET - the London MAN, as an example, is moving to a 2.5Gbps backbone, with 100Mbps feeds to individual universities.

QoS was a key factor in designing the network and thus the routers chosen (Cisco 12016s and 12008s) support Multiprotocol Label Switching (MPLS) (see RFC 2702 for why this is good for QoS) amongst other QoS features.

JANET's link to the rest of the internet is being upgraded too, with 2.5Gbps of external bandwidth and 622Mbps transatlantic bandwidth - to Internet2.

In the past, the UK academic community has been on the ball with internetworking - from the invention of packet-switched data networks (1967) and the first ARPAnet node outside the US at University College London (1974) to one of the earliest and largest (and still very large) deployments of web caching with Squid (the JANET webcache). Not to mention that the web was invented by a British academic... (although he was working in Switzerland at the time... does that count? :p )

If only our commercial managers were as bright... then we wouldn't have The Great British Broadband Farce.
Hmmm, now can I steal 802.11 wireless from my local university? I'm sure they'd never notice now :)

In order to register as a ".org", an organization must meet certain criteria.

Is that still true? I know that such restrictions on TLDs have eroded over time as they proved unenforcable.

AFAIK there has never been such restriction. See RFC 1591:

"ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non-government organizations may fit here."

In other words, "the TLD for the rest of us".

I don't think .org websites should ever be for-profit businesses as that is not how that domain was intended to be used.

That's a very popular misconception. The .org domain is intended to be a catch-all for domains that don't qualify for any other TLD.

You're wrong, and I agree with you!