Slashdot Mirror

Definitely, it's one of the best computer books I've ever read.
However the title is misleading, most of the concepts found inside could be applicable to Windows/J2EE/Assembly ;) programming environnements. Take it like a case study of successful and elegant programming: UNIX and its tools
Btw: the direct link: ARTU saves you one click.

And I thought firewalls were supposed to stop certain services...isn't "P2P Through Firewalls" defeating the purpose?

Or perhaps the problem is rather with NAT? In that case, I'm still hoping that someday someone will implement something like RFC 1701 or somesuch instead of continuously reinventing the wheel.

The RFC, the server, or the client?

I became aware of it having been recently bitten by a window scaling bug in a router between my PC and where I work. I found the RFC quite interesting.

Do not underestimate the power of the RFC 1149. They need careful fine tuning, but if done right, the results are mind boggling. :-)

http://www.faqs.org/rfcs/rfc1149.html Check out RFC1149 too. It can get a bit messy, but its low maintenance and will work for miles on very little electricity.

"IMAP is much better, in that it only downloads the headers of the messages until you read the body."

From RFC 1939, the POP specification:

TOP msg n
After the initial +OK, the POP3 server sends the headers of the message, the blank line separating the headers from the body, and then the number of lines of the indicated message's body.

My group inherited a bunch of code from another group; almost the worst possible situation (the original product was a prototype that had been shoved into production, the code was meant to be 'portable' but was never actually ported, and hence full of gotchas, etc.).

Ever read 'The Art of Unix Programming'? When he said, "The combination of threads, remote-procedure-call interfaces, and heavyweight object-oriented design is especially dangerous... if you are ever invited onto a project that is supposed to feature all three, fleeing in terror might well be an appropriate reaction.", he wasn't kidding. One of our guys found 1500 lines of code that didn't do anything.

The key thing is to figure out where the joints are. Find the interfaces, the ways different peices talk to each other. Understanding this is usually the key to how the whole code is organized. It tells you how the authors thought about it. And it also tells you what parts can be incrementally replaced without having to throw out the whole shebang.

but in the last year, I have probably had almost a month of total downtime, twice the length of downtime was almost a week. I don't live in the boondocks either, my ISP, a national cable provider here is based in the city I live in.

I don't think that is an inherent limitation of the technology, I think that is a limitation of the people deploying the technology. In my experience, a higher than acceptable number of network engineers don't treat the network as carefully as they should. They take somewhat of a "maverick" approach - their ego regarding their level of skills exceeds their care for continued service availability for their customers.

Cisco abandoned a slogan a while back which I thought was great, and is my philosophy on how a network should be designed and run - "The network works, no excuses." The goal should be that faults in a network should never be attributable to a human, if they are, that indicates a lack of planning and care in managing and operating the network.

Sadly, in reality, humans are the greatest cause of network faults. According to RFC 3439 - Some Internet Architectural Guidelines and Philosophy, "... 80% of unscheduled outages are caused by people or process errors [SCOTT]". The best way to run a network is to only "touch" it when you absolutely have to, and question whether that "touching" is necessary twice - much like the old carpenter's saying, "measure twice, cut once".

I thought that the ISODE Consortium invented LDAP. They're the ones credited on the RFC. One of their partners is Novell but that's a far cry from saying Novell invented Active Directory.

Please read the Godwin's Law FAQ. "Invoking" Godwin's Law is a misuse of the law. Godwin's Law is about probability, not ending discussions and declaring yourself a winner.

As you seem to have missed it, the issue is the behaviour of TCP when it operates over a path involving links which have asymmetric bit per second values.

I suggest reading RFC 3449 - TCP Performance Implications of Network Path Asymmetry for further information.

But perhaps they could account for that and start issuing a set # of desktop licenses (that don't move) and a set # of laptop/mobile licenses that can move off the network.

So how would they know if a desktop license would move from the network? As you said, they can't check IP ranges, because this won't allow you to change ISP without notifying MS. And then MS has to deal with private networking IPs (RFC 1918).

And can't just a pirate use a mobile license key instead?

TCP was designed with the assumption of a symmetric bandwidth path between the involved end points.

To try to put a figure on it, for around 80% to 90% of the Internet's history, the Internet has been run over symmetrical bandwidth links eg. 56Kbps full duplex point to point links, T1/E1s, T3/E3, Frame Relay, ATM, Token ring, the Ethernet variants etc. Asymmetric links such as DSL and cable are the exception.

TCP has performance issues when run over paths which involve asymmetric bandwidth links. They are described in RFC 3449 - TCP Performance Implications of Network Path Asymmetry.

FTP is quite old, and was quite useful even before gopher and later http made zipping files back and forth trivial. The genius of Berners-Lee was rather like the mythical invention of the Recees Peanut Butter Cup. He figured out a way to combine a hypertext markup scheme with internet file transfer. The individual component ideas had been lying around for at least seven years (and possibly since the dawn of ARPANET) when he put them together in a limited whole. Active scripting was a bit more clever an idea, but only marginally.

I will grant that it's a good thing TELNET is dying in favor of SSH-- security (network and computer alike) has made great progress since then. So has bandwidth. So has accessibility to the general public. But it's no more funamentally different in terms of power than modern desktop computers are compared to those of days of yore.

I am personally not much of a fan of TLDs. In my experience, they just lead to confusion. Most domains are registered under .tld, so that's where people will look, even if they should technically be somewhere else. This is also how domains are registered (compare georgewbush.com and georgewbush.org). Outside the US it's even worse - sites often have the country TLD, but sometimes a gTLD. To avoid confusion, some sites are accessible through multiple TLDs.

So, if TLDs are not being respected, why have them at all? Some have tried me that it organizes the namespace hierarchically, thus distributing the load. I don't think it helps a lot, if most people go for the .com anyway. The only people who benefit are those who profit from more domain registrations.

My proposal? Change the system so that top level domains can be directly registered. E.g. Google would get just Google, with no .com or anything. While we're at it, we might as well get rid of the ass-backwards naming, e.g. google/www/search rather than www.google.com/search. Companies that actually use the TLDs to select sites in different countries could still do so; instead of google.de and google.co.uk they would get google/de and google/uk.

And one more pet peeve of mine: we could add support for IP-IP encapsulation. That way, if your server is hosted between a NAT box, you can just instruct clients to route the packet to your internal IP via the NAT box. Of course, the client and the NAT box would have to support it as well...

COM - This domain is intended for commercial entities, that is
companies. This domain has grown very large and there is
concern about the administrative load and system performance if
the current growth pattern is continued. Consideration is
being taken to subdivide the COM domain and only allow future
commercial registrations in the subdomains.

NET - This domain is intended to hold only the computers of network
providers, that is the NIC and NOC computers, the
administrative computers, and the network node computers. The
customers of the network provider would have domain names of
their own (not in the NET TLD).

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

ORG is for "miscellaneous organizations", NOT non-profits. The idea of .org being for non-profits is some sort of wierd meme that everyone believes, for no particular reason.

NET is for "only the computers of network providers, that is the NIC and NOC computers", NOT ISPs.

There's nothing you as an individual company / organization can really do, for all the reasons you've listed.

However, if there was a concerted effort among ISPs to implement proper filtering of packets, then at least DDoS attacks that used spoofed sources would be impacted. This can't solve all types of attacks, and it requires significant cooperation and motivation because currently there is little incentive to do so. Basically you configure your border routers not to pass packets that you know are invalid -- those with RFC1918 addresses, bogon addresses, and addresses outside of your AS. This is all documented in BCP38.

So basically, tell your boss that to prevent attacks like this you can have him mandate that whatever company you decide to buy connectivity from must implement BCP38. If ISPs have an actual incentive to do this, instead of just a bunch of grey-bearded admins saying it would be a good idea, then perhaps it would be implemented more widely. Essentially, tell him to make his purchasing decisions based on "good network stewardship" and not just lowest price. If more companies did this then as a whole the DDoS landscape would clean up just a little bit.

There was recently a long thread on nanog about this. It's good reading as it shows from the operator side of the fence how the situation is known to be improveable but there's no financial (and thus managerial) reason to do it.

Do you resent the IETF defining email?

Email, as defined by RFC, is a plain text medium. Binary attachments are a legitimate extension of that medium. See RFC 2045 and friends. (Ever wonder why MIME is needed? It's because email is plain-text.)

HTML is plain text, but it isn't very human-readable, is it? It, thereby, violates the spirit of the RFC.

Furthermore, when it comes to communication, it takes two to tango. I resent it when people dictate that I must use a mail agent that renders HTML or slog through HTML source.

If you think that HTML should really be allowable in the body of emails, you should get cracking writing RFC 3822.

-Peter

Do you resent the IETF defining email?

Email, as defined by RFC, is a plain text medium. Binary attachments are a legitimate extension of that medium. See RFC 2045 and friends. (Ever wonder why MIME is needed? It's because email is plain-text.)

HTML is plain text, but it isn't very human-readable, is it? It, thereby, violates the spirit of the RFC.

Furthermore, when it comes to communication, it takes two to tango. I resent it when people dictate that I must use a mail agent that renders HTML or slog through HTML source.

If you think that HTML should really be allowable in the body of emails, you should get cracking writing RFC 3822.

-Peter

netblt (RFC) purpose is also to enhance file transfer thruput (bandwith efficiency). An implementation has also been studied.

The law that the previous poster thinks is protecting him is probably the Privacy Act of 1974, which is only binding on government agencies. It's discussed in the FAQ.

There is also a SSN FAQ at cpsr.org, but it formats like crap on Mozilla. You'd think "computer professionals" wouldn't screw up something like this.

Hacker's know Godwin's Law.

There's nothing wrong in rendering a GIF image from inline binary data provided in the SRC attribute of an IMG tag.

Check out RFC 2397 - The 'data' URL scheme

The full story here. I sent Linus a $200 check for beer money about the time of the 386 port(I'm honestly not sure if he ever cashed the check-he didn't remember it when I asked once). I can't swear it was the first money sent-but it was sure sent early on. I was working at Sun at the time and felt that was the best contribution I could make. I was director of tiny non-profit organization which also made a small donation to the Wine Project--which clearly did register.

I don't think even GMing trees will make it more advantageous than industrial hemp -- which does not have enough THC to get one high.

Read here: http://www.faqs.org/faqs/drugs/hemp-marijuana/inde x.html

Fight prejudice and corrupt business practices and advocate industrial hemp!

Honestly...Good catch ... Missed that one completely. It is an interesting thought, if the individual indeed had a valid & working abuse address.
What then? :-)
Should the sandal-wearing, black t-shirt clad, internet propellerheads descend upon this ignoble perpetrator who used the free enterprise system to conduct a faux fraud upon the gullible & witless public. Perish the thought!
;-)

RFC 2557: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)

There's a Mozilla KB entry about MHTML support and open bugs for load and save (IDs 18764 and 40873; bugzilla won't accept links from Slashdot). Plus the maf extension to support MHTML.

Your head must be in the sand too then, as you are using a computer. Not the most eco-friendly device around.

Maybe (s)he's using RFC 1149 - Standard for the transmission of IP datagrams on avian carriers?

(would make for an interesting twist on the slashdot effect :-))

In that case, FairPlay is also open: drms.c and DeDRMS.cs. MD5 and AES.

I knew chimps were smart but not that smart! :)

Hey, it's the water powered computer from the Crunchly saga! The future is finally here!

There are many subsequent panels in this story line, if you follow the links at the bottom of the Jargon entries...

Yeah man, like revive gopher - except put a Google "spin" on it and call it "Goopher". :)

http://www.faqs.org/faqs/

I maintain(ed) a Usenet FAQ for about six years or so for Eudora/Mac

It takes effort. Since the application I was writing for was still being released, information would change with every new version. Of course, you had to keep questions specific to a certain beta version as long as they remained "frequently asked".

It also requires following the newsgroup on a very regular basis, and watching for the trends (and the questions that are getting asked a bit).

For a while I looked at things to turn the flat text file I was posting to the group into a nice HTML version. I ended up doing what I think that 90% of Usenet FAQ-writers did - did most of by hand. I just wrote the FAQ in HTML and then exported to plain-text to post and email.

Some suggestions tp anyone thinking about maintaining a Usenet FAQ:
1) Do not list your email address anywhere in it unless you want people contacting you with every question imaginable.

1a) Refer everyone who emails you to the newsgroup, even if it is an easy question. If you answer the quick question, then they email you back with a more complicated one.

2) Be honest and succinct.

3) Find a program or script to regularly post the FAQ to the newsgroup.

4) Get it set up so that you can post the FAQ to *.answers This will help with propagation and will automatically get several copies up on the web.

5) Realize it is largely a thankless job.

Like you said: "That cycle was discovered a long time ago during the IGY. The "Ozone Hole" over the Antarctic was larger in the mid-50's than it is today."

The earliest year with data is 1956.

1956 321 DU

1957 330 DU

http://www.faqs.org/faqs/ozone-depletion/antarctic /

As was pointed out in the topic, this year is looking rather better than recent history, starting the month at 150 DU:

http://www.antarctica.ac.uk/met/jds/ozone/images/z oz0405.JPG

(Historic data is the average of 1957-72)

"you pick your data carefully and you can justify any theory you want."

Some theories are clearly unjustified when we look at all of the data. Like, for example: "The "Ozone Hole" over the Antarctic was larger in the mid-50's than it is today."

It would be interesting to discuss why October, as then we could discuss the way that CFCs cause the ozone hole. Discussing the centuries before 1956, the first year with ozone data from Halley Bay, Antarctica, without data, is pointless. As for data between 1982 and 2004, feel free to educate yourself and us.

Oh, and one more thing. There are no ice core records of ozone as there are no glaciers in the stratosphere. If that changes, let us know.

http://www.atm.ch.cam.ac.uk/images/easoe/total_ozo ne.gif

"This is a myth, arising from a misinterpretation of an out-of-context quotation from a review article by Dobson."

http://www.faqs.org/faqs/ozone-depletion/antarctic /

A lot has been said about the fears of preventing the inflatable capsules from being punctured, but the article states that they don't even have the solution to sealing them properly yet. The Bigelow team is also developing how to fold and package those soft goods around the module's aluminum core, so once inflated in space, creases and folds and critical seals around windows and hatches do not leak. Plus, and I'm not physicist, but isn't it cold in space? And doesn't gas pressure drop when it gets cold? Are these things to be inflated with liquid nitrogen and oxygen? This site http://www.faqs.org/faqs/astronomy/faq/part4/secti on-14.html leads me to believe that if you were on the sunny side of Earth things would be ok, but go into a shadow and whoops, there goes the inflation.

Well, my argument was specifically related to the "lambda" construct which, I'm sorry, is basically useless in it's current form. See the Python FAQ, sections 6.9 and 6.10. Of course, their argument is that "lambda" is simply syntactic sugar, so who cares? Just define a function. My argument is, why bother with a half-assed "lambda" construct in the first place if it's going to be ridiculously broken.

I think this is covered in the Godwin's Law FAQ.

• It requires a connection back to the originating MTA. Slow.
• The information returned would be useless - my machine would always say "postfix". Unless you're talking about a new identd linked with the mail server. But that's not what RFC1413 says. It says the "owner of that connection" - that's always going to be postfix.
• It includes no provision for telling if the machine shouldn't be sending this message at all.

A good SASL setup, along with SPF, does far, far more for authenticated email. My machine has this: it rejects any inbound email claiming to be from one of my user's domains unless SASL-authenticated as that user. And has SPF records so other servers can reject messages from these domains unless they come from my server. Thus, it's very difficult to forge an email from my users' domains to a server with SPF checking enabled.

I think you are fretting with WiFi and copying things. A bit of a non-story - either use CDA / CD-MP3 (I am sure you can buy MP3 player for car).

For added geek value, have a CD/SD/Memstick/pigeon carrier input to an ogg player. Less fuss more music.

Geek value points: avian carrier IP dataram transmission

OGG audio

Why is it so hard to have one set of private records for the registrar and another set for the public and to do it without charging an extra $10/yr per domain?!

Because running a domain is a responsibility. As RFC 1591 puts it,

Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community.

If you don't want the responsibilities, including making contact information available, don't have your own domain. Or hire someone to perform those responsibilities for you.

Maybe not.

actually, the following are legal email addresses:

root@localhost
Administrator@localhost
webmaster@your-hostname-without-a-TLD

The law is so vague that it didn't specify what a valid e-mail address is. Should have reference something like

RFC 831 - Simple Mail Transport Protocol

or more importantly, what the email syntax SHOULD BE

RFC 822 - Standard for the format of ARPA Internet text messages

This bill will get thrown out of court easily but only AFTER the EFF expends additional money due to our overpaid legislators' technologically-clueless ineptitudes.

Get with the program, EFF lobbyists.

For example, consider the address shown above
1080:0:0:0:8:800:200C:417A

<snip>

Then, when encoded as specified above, this becomes:
4)+k&C#VzJ4br>0wv%Yp

This has to be a joke. Who let the sendmail developers out of their cages?

1. Cisco is only one of a handfull of router manufacturers, and if their gear doesn't keep up with the technology then those 'insane corporate policies' you referenced will be fixed. In the early days of IPv4 Cisco's routers (and everyone else's for that matter) used the cpu to handle routing too, fancy fast path hardware didn't exist at the time. As time changed, and the amount of load on routers increased the industry leaders invented faster and better hardware to keep pace with that load, there is no indication that they won't do the same with IPv6.
2. This same argument has been made for every new addressing scheme... there was no reason to use more than 8 bits of address, because there would never be more than 256 computers in the world. Same arguments were made for phone numbers. Oh, and it's "Network Address Translation" see RFC 1631, any amount of "anonymity" provided by NAT is purely a placebo effect on the less cluefull user. You focus purely on the number of addresses availabel in IPv4, but fail to take into account how many of those are usable, given the amount of reuse hacks already in use throughout the world, I'm sure we're already well over the number of usable, globally routed, IPv4 addresses. Especially with some of the Asian and European Cell carriers using their own NAT'd 10/8 network, as do a number of US cable modem companies, not only in some cases for end users, but also for their internal routers. (The route out from my cable modem travels through two routers in the 10/8 network.)
   
   Oh, and if you actually read said RFC you would learn that it is not a solution, it is a bandaid. Just read the abstract:

   Abstract
   
   The two most compelling problems facing the IP Internet are IP
   address depletion and scaling in routing. Long-term and short-term
   solutions to these problems are being developed. The short-term
   solution is CIDR (Classless InterDomain Routing). The long-term
   solutions consist of various proposals for new internet protocols
   with larger addresses.
   
   It is possible that CIDR will not be adequate to maintain the IP
   Internet until the long-term solutions are in place. This memo
   proposes another short-term solution, address reuse, that complements
   CIDR or even makes it unnecessary. The address reuse solution is to
   place Network Address Translators (NAT) at the borders of stub
   domains. Each NAT box has a table consisting of pairs of local IP
   addresses and globally unique addresses. The IP addresses inside the
   stub domain are not globally unique. They are reused in other
   domains, thus solving the address depletion problem. The globally
   unique IP addresses are assigned according to current CIDR address
   allocation schemes. CIDR solves the scaling problem. The main
   advantage of NAT is that it can be installed without changes to
   routers or hosts. This memo presents a preliminary design for NAT,
   and discusses its pros and cons.

3. What exactly is the difference between 2 and 3? Two seems to be "2^64 is too many hosts", whereas three seems to be "64 is too many bits". Well, duh. The two go hand in hand. All the same issues that apply to 2 apply to 3... but you raised an additional issue, that having 64bit addresses will bloat routing tables absurdly. That's because of the way addresses have been handed out, split, merged, moved, and generally horribly mismanaged. IPv4 routing tables today are absurdly bloated. IPv6 was designed, from the get go, to fix this problem by using aggregated routes. Say you have two networks that are very nearly adjacent in the address spac

That killer app may be VoIP. If everyone wants their own IPv6 phone number.

Sometime in 2045, when IPv6 is deployed...

Hey, here's my new VoIP number! It's de56:234d:13b5:123b:1337:923a:be34:ab21!

Maybe we'd best start using RFC 1924...

Will it use pigeons to display web content?

I'm using something similar right now to get on the Internet, it's not that bad.

The Morris worm was way interesting. It was multi-platform as I recall, targetting Solaris and VMS. It used finger and sendmail exploits. Groundbreaking for its time. Here's an RFC about the worm:
http://www.faqs.org/rfcs/rfc1135.html