Slashdot Mirror

Basic idea seems the same, right? http://www.faqs.org/rfcs/rfc3514.html

Welcome to Unix. You seem to be confused about a great many things. I'm not more than a novice myself, but I must recommend Eric S. Raymond's The Art of Unix Programming , because for better or worse Unix and F/LOSS count most of your complaints as strengths. Core principles, even.

Your view of the One True Unix implies that there is only one correct way to implement an OS. If there's only one way to implement an OS, doesn't that imply that all computer usage is pretty similar? Perhaps we can optimize for all use-cases at once? Or do you just think that you know better than everyone else how they should spend their coding time?

It's likely that if you've raised this argument here before that people have mentioned the UNIX certification process as well as the Linux Standard Base. In what way do these entities fall short in defining a common standard?

Oh, fuck it. Don't have this argument with me. Don't have it with anyone on slashdot. Go have it out with Theo de Raadt, Linus, Eric Raymond, and RMS. If you want to change the world and change people's minds, start at the top. Alternately, close your mouth, open your mind, and start with the first chapter of that book.

but chris taylors' thesis is something i give to unix neophytes who might be interested in learning more about unix and vi.
it either scares them away, or draws them in, but that's up to them to figure that out, evangelism will eventually just wear you out.
IMHO taylors' writing style is amusing and might keep a reader engaged. even though it is unix agnostic i think the ability to speak to the uninitiated and offer them a quick stepping stone document without being overly cryptic or aloof is more helpful then sudden immersion into uber geekdom.

you want to scare a neophyte away, try encouraging them to read unix koans of master foo

1) Whether it is an IPv6 address or an IPv4address+DNAT port, the exposure is the same, the outside world has a door into a specific system.

Unless you are running the ipv6 privacy extensions :
http://playground.sun.com/ipv6/specs/ipv6-address-privacy.html
http://www.faqs.org/rfc/rfc3041.txt

My thought is that running an open wifi does not provide plausible deniability. It's more likely that someone will do something malicious behind your gateway and you'll take the blame than vice-versa. *Especially* if you seem technically capable, the fact that you explicitly left your wifi open would be taken as a sign you were *trying* for plausible deniability. Face it, for the residential case, *there is no plausible deniability*, at least with respect to traffic that originates from your residence, *unless* you have a trusted proxy shared with others out there that you *know* won't retain enough data to trace your identity. The only way to have plausible deniability is to find an open-wifi somewhere and hope there's no security camera. If it is some poor sap's house, then they will probably get blamed, if a business, that business may be required to discontinue open wifi under legal pressure.

Here I think we will have to agree to disagree. Particularly when you consider some of the advantages to the privacy extensions. My point is that at present, there is no happy medium. You have a choice between a centralised traditional firewall, and a decentralised randomised more privacy friendly solution.

I think we can agree that ipv6 could be far better than it is with what we know today verses when it was designed 15 years ago. I'm just willing to wait a little longer for my feature set than you are for yours.

But why do you care if they're known outside your network? You have a stateful firewall that protects them from the world. Here's my printer's IPv6 address: 2001:453:da65:1:94ab:7c00:8cba:beb5. Go ahead, have fun trying to connect to it.

You have far more confidence in your firewall than I have. One slip in the coding, one unchecked buffer is all that it takes for it to be breached.

Yes, of course. Why wouldn't you?

Privacy.
http://playground.sun.com/ipv6/specs/ipv6-address-privacy.html
http://www.faqs.org/rfc/rfc3041.txt

Perhaps a packet every so often that says "Hi, how much bandwidth may I have please?" which the server or node would reply"You can have X" and then everyone wouldn't be trying to slam and your route would be based on which gives you the largest X.

While we're at it, why not implement the Evil Bit so viruses and spam don't clog the network?

Any congestion sensing algorithm that relies on accurate reporting of congestion by a third party is so utterly stupid an idea that it's not even worth considering.

IPv5 was the experimental ST2 protocol ( http://www.faqs.org/rfcs/rfc1819.html ). It was sort of a connection oriented IP designed for multimedia stuff. Nobody seemed to want that either. RSVP was a protocol designed to reserve bandwidth on the Internet, but ran on good old IPv4. That tanked as well.

The European Telecom research agency, ETSI, is working on yet another attempt to provide resource reservation through the Internet for VOIP. We'll see how that one goes.

That's been known in the TCP community for decades.

I looked at this back in my RFC 896 days, when TCP was in initial development and I was working on congestion. I introduced the "congestion window" concept and put it in a TCP implementation (3COM's UNET, which predated Berkeley BSD). The question was, what should be the initial size of the congestion window? If it's small, you get "slow start"; if it's large, the sender can blast a big chunk of data at the receiver at start, up to the amount of buffering the receiver is advertising.

I decided back then to start with a big congestion window, because starting with a small one would slow down traffic even when bandwidth was available. One of the big performance issues back then was the time required to FTP a directory across a LAN, where TCP connections were being set up and torn down at a high rate. So startup time mattered. The decision to go with a smaller initial congestion window size came years later, from others. This reflected trends in router design. I wanted routers to have "fair queuing", so that sending lots of packets from one source didn't gain the sender any bandwidth over sending few packets. But routers gained speed faster than RAM costs dropped, and so faster routers couldn't have enough RAM for fair queuing. Today, your "last mile" CISCO router might have fair queuing. Some DOCSIS cable modem termination units have it. But many routers are running Random Early Drop, which is a simple but mediocre approach. (The backbone routers barely queue at all; if they can't forward something fast, they drop it. Network design tries to keep the congestion near the edges, where it can be dealt with.)

Remember, every dropped packet has to be retransmitted. (Too much of that leads to congestion collapse, a term I coined in 1984. That's what the "Nagle algorithm" is about.) In a world with packet-dropping routers, "slow start" makes sense. So that was put into TCP in the late 1980s (by which time I was out of networking.)

However, the RFC-documented slow start algorithm is rather conservative. RFC 2001 says to start at one maximum segment size. Microsoft's implementations in Win95 and later start at two maximum segment sizes. In RFC 3390, from 2002, the limit was raised to 3 or 4 maximum segment sizes. (We used to worry about delaying keystroke echo too much because big FTP packets were tying up the 9600 baud lines too long. We're past that.)

But Google is sending at least 8 segments at start, and Microsoft was observed to be sending 43. Sending 43 packets blind is definitely overdoing it.

I wonder whether they're doing this blindly, or if there's more smarts behind the scenes. If their TCP implementation kept a cache of recent final congestion window sizes by IP address, they could legitimately start off the next connection with the value from the last one. So, having discovered a path that's not dropping big bursts of packets, they could legitimately start fast. If they're just doing it the dumb way, starting fast every time, that's going to choke some part of the net under heavy load.

the obfuscation layer, being hidden behind the router?

There is no obfuscation layer behind a router, a router is completely transparent. Are you referring to a NAT gateway? That's available for IPv6 as well, but its use is discouraged. Or are you referring to an application-layer gateway (ALG), such as an HTTP proxy? Of course they work on IPv6 as well. Or maybe you are referring to a state-tracking firewall (on either session or transport layer)? Those devices are also completely transparent, although asymmetric.

If you have a uniquely identifiable address..well..see the problem? Or what am I missing?

You're missing the IPv6 privacy extensions, RFC 3041

"Then the package manager will fail to install the program because the program requires a later version of a given library than is available in the long-term-supported distribution that the end user is running."

No, it won't. Unlike Windows, Linux is perfectly happy having multiple versions of any given library installed and available: Fortunately, on Unix-like systems (including Linux) you can have multiple versions of a library loaded at the same time, so while there is some disk space loss, users can still run ``old'' programs needing old libraries.

Well if it's just plain text they could open the file in an editor, highlight the text, and use copy/paste to drop it in a textarea field in an HTML form.

So let's make the problem harder. How would I have enabled uploading of a binary object in 2001? I'd do the same thing I do today; use "forms-based file uploading."

RFC 1867 defining "forms-based file uploads" appeared in 1995, some months before Berners-Lee and company released RFC 1945 proposing HTTP 1.0. HTML 3.2 (1997) defined the "file" input type that Web applications use for file uploads. That element is usually displayed as a text box into which a file path can be entered, along with a "Browse" button that opens the local file browser.

Of course, there were many other ways to upload a file to a web server by 2001. I wrote a PHP-based application for a legal foundation that enabled subscribed attorneys to share documents in an online archive. Members could register a document online. They'd then receive a mail message to which they would reply after attaching the file. The message included a unique code that so the file could be matched to the registration entry in the database. This worked especially well with people on services like AOL whose interfaces at the time were not friendly to RFC-1867 uploads. (Nowadays I'd probably use either WEBDAV or dspace depending on how much structure I'd need.)

Sometimes I'd use Samba to export directories from a Linux application server to the Windows desktops. Then staff members could simply drop HTML files into pre-determined folders and have them appear within the context of the website. Nowadays, though, I handle pretty much all the content editing on the browser side with forms and TinyMCE. That way I get reasonably clean HTML code as opposed to what you get from someone copying and pasting from Word into a text box.

I wouldn't have thought uploading files was a key obstacle in the way of platform-independent development in 2001. Surely there must have been some bigger roadblocks.

If you're talking about an application that periodically collects files from a Windows workstation, in 2001 I'd have used an automated shell script running smbclient to connect to the workstation using SMB/Netbios and collect the file(s). What happens next depends on the application. I often run PHP scripts from the command line to process text files because I know it well, because of the enormous array of functions it offers, and, frankly, because I've always found Perl's syntax rather intimidating. grep, sed, and awk go a long way, too. Automatically manipulate a graphic image? ImageMagick.

What happened to IPv5?

It was the ST2 protocol: http://www.faqs.org/rfcs/rfc1819.html

Never went anywhere.

... the evil bit! Now, let me just check the RFC to see if that goes at the beginning or the end, then I can start decoding.

They accepted responsibility for a critical piece of internet infrastructure, here is the current list of expectations for said operators http://www.faqs.org/rfcs/bcp/bcp40.html

What is probably annoying / concerning most people is, if you look at almost every major service that provides service to more than say 1 million plus people there is some sort of redundancy so that even if an entire site is taken out of commission no disruption occurs. The fact that DNS is the poster-child of the anycast technique is not helping their cause.

The "shit happens" argument affects everyone equally, so why is no one else site down for such a long run for what appears to be a predictable reason (tropical storm damage to fiber lines). The cynical version of this question is "synchronized backhoes anyone?".

Due to technical limitations within the DNS protocol itself the number of root servers is limited to 13, given that this operator (and supposedly others) seem to not be capable of handling the responsibility of being in the position they are, is it time to give the responsibility to others? From the looks of it, the only reason the research lab is in control of H is that they had facilities during the internet's infancy.

I wouldn't. I, like many others, don't need encryption, so I'd just be paying $7 for a $3 function. If Wal-Mart has taught us anything, it's that a few dollars price difference makes a lot of extra sales.

With the prices you listed, encryption would have to be needed in 8% of network devices to just break even on price alone. They also must need the exact encryption features offered by the $7 chip, or they'd need the extra equipment anyway. Do 8% of devices really need security? Is my dancing robot (I'm the AC above) or HTCPCP server really that important?

Personally, I'll stick with a cheap insecure shield, and just keep my network secure.

RFC 1149 is 20 years old at this point, not just from last year.

There's an RFC for it!

Well, you are of course free to call it whatever you want. The fact remains that Wine doesn't emulate a Windows system in the way that, say, VirtualBox running Windows does.

I believe I've differentiated between the two the entire time. Nor am I the only one that considers what Wine does emulation, even if it is not at the machine level, you do realize that the original acronym for Wine was Windows Emulator right? Read the old FAQ if you don't believe me, the name was changed to help differentiate it from full virtual machines.

http://www.faqs.org/faqs/windows-emulation/wine-faq/

Ancient History? How about this, from Linux.com:

"The acronym "WINE" stands for Wine Is Not an Emulator. But don't let the acronym fool you, WINE does help to "emulate" the Windows environment."

http://www.linux.com/news/software/applications/37986-use-windows-applications-on-linux-using-emulation

and from the previous article..

"Although the acronym WINE stands for "WINE Is Not an Emulator", the theory is the same. What WINE does is serve as a compatibility layer allowing Linux to make use of Windows DLL files. WINE achieves this by implementing the Windows API layer entirely in user-space instead of kernel-space with the help of the wineserver daemon."

This is the seat I endorse.

This is *exactly* what RFC3041 discusses.

Microsoft has already implemented a solution, in Windows 7 at least -- which is to say, Microsoft is actually ahead of the curve in implementing an RFC standard. Good on them. That covers the majority of home and office desktop users. The Linux folks will catch up.

I'd say their own implementation of the player will use LLVM for accelerated execution of JavaScript to get the necessary performance (they've been contributing to the LLVM project for some time now). Why do I say this? They've submitted a recent (and invalid due to prior art) patent for LLVM IR generation from JavaScript. Don't believe me? See:

http://www.faqs.org/patents/app/20100153929

Any JavaScript frontend for generating LLVM IR violates this patent (they even mention LLVM IR explicitly here). Ironically there is so much prior art here its not funny (they've essentially repatented in the old UCSD p-System). This patent would cover the generation of bytecode from JavaScript such as already used by Mozilla in their engines. Smells like a future Mozilla-versus-Apple court case.

So much for Apple being high minded in all this. They are simply attempting to corner another market. Makes Adobe look like the good guy again.

http://code.google.com/p/memcached/wiki/NewConfiguringServer

Networking
By default memcached listens on TCP and UDP ports, both 11211. -l allows you to bind to specific interfaces or IP addresses. Memcached does not spend much, if any, effort in ensuring its defensibility from random internet connections. So you must not expose memcached directly to the internet, or otherwise any untrusted users. Using SASL authentication here helps, but should not be totally trusted.

From their wiki page detailing how to configure a new server. Surely the part they highlight in bold should have raised a flag to even the dumbest administrator.

Here's an idea that won't impact performance: At startup, issue a big multi-line warning if the IP addresses that are getting bound aren't on a Private Internet:

The Internet Assigned Numbers Authority (IANA) has reserved the
      following three blocks of the IP address space for private internets:

          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)

FYI, there are patents on APIs out there already.

Why hand-carry when you can just use the protocols of pigeon-carried-ip?

Good throughput, albeit a bit high in packet-loss and poor latency.

http://www.faqs.org/rfcs/rfc2549.html

RIM were and are jerks, no arguments there. But I think our points of agreement begin and end there. As far as I know, being a jerk is not in itself a tort (although many things jerks do are). No matter how big of jerks they are, they don't deserve to be punished for doing something that's not wrong. So the question of whether the patent is valid is critical, even though there were jerks on both sides of RIM v NTP.

As for your comment that the price to consumers is negligible, I disagree. The damage in rewarding patent trolls is not just in the monetary costs, but in the dangerous precedent it sets. To quote Kipling:

"It is always a temptation to a rich and lazy nation,
To puff and look important and to say:
"Though we know we should defeat you, we have not the time to meet you.
We will therefore pay you cash to go away."

And that is called paying the Dane-geld;
But we've proved it again and again,
That if once you have paid him the Dane-geld
You never get rid of the Dane."

As for the question of whether the patent is valid? It's simple. Email relies on TCP/IP, a protocol that is independent of the means of transmission. Copper, fiber, radio, avian carrier", it doesn't matter. NTP clearly doesn't have a patent on wireless TCP/IP, and once you have wireless TCP/IP, all TCP- or UDP-based protocols come along for free. HTTP, SMTP, NTP (the protocol, not the company), NNTP, SNMP, etc., etc., etc.--none of them depend on or are affected by the physical medium used to transmit TCP/IP packets.

As for why RIM didn't win, I don't know, but as you point out, their courtroom shenanigans surely didn't help, and may have pre-empted any proper re-examination of the patents. But more importantly, that was pre-Bilski, and while the final SCOTUS decision on that may have stopped short of what many of us wanted, it did leave the bar for patents set a whole lot higher than it had been.

I don't know about some of the other players, but with Google at least, the patent almost has to fail the "machine-or-transformation" test. It's not the machine, because I can download the Android SDK to my desktop, and run Android apps there just fine, even though that's a totally different (and totally different type of) machine. And my machine is wired, so I'm not infringing their patent when I run the application under the SDK--so why is it suddenly infringing when I transfer the software unchanged (nothing is "transformed") to my phone? And if it's infringing on my phone for some inconceivable reason, is it infringing on my laptop the moment I remove the cat5 and it (automatically and transparently) switches to WiFi? I'm sorry, but "does not compute" is the only phrase that comes to mind.

No, increase the budget instead: give perks to employees that deny patents like this.

Sorry, but someones already patented that...

Can we patent this type of reply on Slashdot so that we don't get the inevitable trite "that's been patented" responses? I mean heck... at try and be clever and original if you're going to pull out that crusty relic of a response.

But that hasn't been patented though. Rewarding an employee has been patented though for having/learning to do their job properly. Patent application number: 20100023384.

A TANDEM computer with a bullet hole in it is still a computer. Buy better computers.

http://www.faqs.org/rfcs/rfc1.html : 7 July 1969, well over 40 years ago and I did one Google search to find it

http://www.freereg.org.uk/ : Birth (well, baptism) and death records from before your country even existed. Transcribed and made searchable on the web, using digital information.

So long as you conceive of a "30 year old record" as being stored on 30 year old media, you are misunderstanding the whole point of digital information.

The funny thing is, the Marine Corps does understand this stuff. Check the dog tags on the next dead marine you see, that's digital information. The alternative solution would be an embossed photograph of the marine's face or his signature, neither of which would be easy to match or robust against the kind of mistreatment which can happen to a body in war.

Wasn't that part of the new extension to RFC 2549: "IP over Avian Carrier with QoS and Packet Tracking over SMS Carrier"

Would be fun to see all those pigeons texting where they are...

Can I just scan for the evil bit instead?

Looks like RFC1149 is needed after all!

http://www.faqs.org/rfcs/rfc1149.html

This decision by Google is symptomatic of so much that's wrong is software.

I remember when Google first came out, Altavista was the dominant search engine then and it was a mess. A page full of blinking ads, where one had to search for the search input. Google was a refreshing change, with that clean look. Now they are doing their best to throw it away. Pity.

But that's not so different from the software world in general, people seem to find it pretty hard to leave well enough alone, although one *remarkable* exception to this rule seems to be Linus Torvalds, he has definitely rejected an attempt to create Linux version 3.

There are so many examples of people who should have celebrated their success and gone to other projects. KDE and Python are the most relevant examples, IMHO. KDE 3 and Python 2 were superb, outstanding pieces of human creation. KDE 4 and Python 3 suck.

And there are many other examples of software that tried to fix inexistent problems. For example, there was a time when every Linux distro had a utility called Lilo, for "Linux Loader". Lilo was simple, easy to configure, worked perfectly. Then someone thought he could improve Lilo and created an abomination called "Grub". Last time I looked there were 185 files in the Grub configuration directory in my computer. How many files do you need to choose which partition you want to boot? Oh, but wait! Grub lets you configure an image that will be shown as the background when you choose the partition to boot! I guess that makes it worthwhile to have 185 files instead of one file to configure, right?

Another example, Linux used to have something called the open Sound System, or OSS. Then someone tried to improve it and created something called ALSA, for Advanced Linux Sound Architecture. The problem is that OSS followed the Unix philosophy being simple, modular, and following the principle that "everything looks like a file". ALSA does not, doing development in ALSA is a PITA.

Why, oh why, cannot people see the beauty of keeping things simple?

What in the hell were they thinking? EMAIL IS NOT A FILE TRANSFER PROTOCOL, DAMMIT.

This guy disagrees.

Patent application title: COMPOSITION AND METHOD FOR ENABLING PROLIFERATION OF PLURIPOTENT STEM CELLS
Authors: Karl Tryggvason, Anna Domogatskaya, Sergey Rodin, a subset of the authors of the paper referenced at the end of TFA. I don't know enough about stem cells to say that the patent application is identical to TFA, but it's on at least highly similar subject matter. Prof. Tryggvason has over 30 patents as per his bio on the Biolamina corporate website, a company he co-founded. As a scientist currently trying to bring some academic research out of the lab and into deployment, I can tell you that this is just how things are done. It isn't perfect, but without the protection of a patent it's hard to see any company willingly expose itself to the massive risk and cost of developing, producing, testing, and marketing Prof. Tryggvason's work without the profit motive that patents protect.

Arrgh... Blew the link. Let's try that again, shall we?

How to Create a New Usenet Newsgroup

here is a good place to start :)

Funny that they mention such high requirements:

A serious Usenet server system, carrying all of the standard 8 Usenet
| hierarchies, a large hunk of alt.* and various regionals, is typically
| going to need a Sparc 20/HP 9000/7xx series or better, with 64Mb or
| more RAM, and at least 8Gb of disk

I guess nowadays it is possible to have a usenet run as a "virtual machine"

In fact, someone should make a VMWare appliance (or whatever is called for VirtualBox or QEmu with a Linux usenet installed ready to use!

What about the evil bit?

You know the BCC list can still be intercepted at the recipient's server, right?

Not if the sender is well-behaved:

In the first case, when a message containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is removed even though all of the recipients (including those specified in the "Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a separate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.)

Also:

Each recipient address from a TO, CC, or BCC header field SHOULD be copied to a RCPT command (generating multiple message copies if that is required for queuing or delivery). This includes any addresses listed in a RFC 822 "group". Any BCC fields SHOULD then be removed from the headers.

What, no WAIS or TN3270? How do you expect people to get work done?!

Merely mentioning Nazis or the Third Reich doesn't automatically Godwin a thread. One has to make a comparison of a particular post or person to the Nazis as a way of insulting them or an ad hominem.
Here's a reference.

If you'd ever seen old-fashioned farm equipment, you wouldn't find the look of those wheels very unusual.

Actually that "CancerX" drug all the newspapers were talking about appears to be DMAT, which you can buy here. I mean the the guy doesn't seem to have published anything about CancerX besides on his webpage. He filed a patent in 2009 which is about using DMAT or TBB to inhibit the enzyme Casein Kinase 2 (CK2), and had a PhD student do her dissertation work on the same thing which was completed in 2008. Since DMAT was actually first synthesized in 2004 for the very purpose of inhibiting CK2 to decrease cell proliferation, and there have been numerous papers on using DMAT for this purpose (you can see these by searching for DMAT CK2 in pubmed or google) I find it hard to believe that this was a serendipitous discovery. If you do the pubmed/google search and look for the institutes where the DMAT studies have been done you'll notice they are pretty much all based in Europe. So it seems to me that these other groups failed to patent the use of this drug for whatever reason and this guy is taking advantage of that while making up a new name along with some story about accidentally discovering its anti-proliferative properties as a self-marketing ploy. Possibly to encourage funding or somehow support his patent rights.

That said he is a biochemist working on anti-coagulants and DMAT is basically a nucleotide analogue (nucleotides are involved in blood clotting) so its possible he synthesized/designed the drug himself at some point for that purpose. I don't really know anything for sure except that calling it CancerX is shady, and talking to the newspapers before publishing is shady.

at the scary devil monastery.

Bourne is "sh" (In unixes dating from V7 (ie all of them)). bash is the Bourne Again SHell. csh might be installed by default in fbsd, but programming in csh is considered harmful. Use Korn instead.

Don'd feed the extremely inaccurate troll. The probability of complex organic life coming into being is actually much higher than most people realize.

I think the real reason we haven't found anyone out there is probably things like interstellar hydrogen getting in the way of space travel, and causing scattering and absorption of communications signals. Most people agree that the SETI project is fundamentally flawed in that way. Doesn't make it an unworthy cause, however, just an unlikely one.

some 120 million killed outside of war over the course of the 20th century

Does your ass hurt from the constant excretion of "facts"?

Sandinistas were also enslaving the populace, silencing newspapers, kidnapping said children from their families to "educate" them, expanding the secret police, creating neighborhood spy networks, forcibly relocating, torturing and murdering Indians for being Indian

Looks like you're confusing the Sandanistas for the US backed Samoza dictatorship, which we left after we occupied the country from 1912 to 1933. The Sandanistas were no saints, but they were Nicaraguans.

People in El Salvador were fighting against the imposition of an alien political ideology and economic system responsible for the deaths of millions and millions, against the clear will of the vast majority of Salvadorans, by those who were armed, funded by, and in the service of the Soviet Union.

Even if what you're saying was remotely true, you'd still be advocating direct material support for one terrorist organization to combat another terrorist organization. I read the declassified "Growth and Prospects of Leftist Extremists in El Salvador", I believe from 1980, and the USSR is not even mentioned (though it may be in a redacted portion.) Leftist support is mentioned from throughout Central America, but that's to be expected. It did tally the death toll of leftist extremists at 450 from 1978 to 1979. After the US got involved in propping up the government against the largely native movement, the death toll eventually reached 75,000.

Notice how after the USSR fell, these wars in Latin America ended, and democracy was restored. That should tell you who caused these wars, and who was keeping them going.

Actually, the timeline of US withdrawal is the one that matches more completely with moves towards peace. Turns out when you aren't having the CIA train every evil shithead at the School of the Americas, and then arming him to the teeth with drug money and weapons sales to sworn enemies in Iran, peace does have a chance.

Mosaddegh came to power after his predecessor was murdered for opposing Mosaddegh's policies. Once in power, Mosaddegh continued to rule without holding elections, as required by the Iranian constitution at the time.

And now, without further explanation, I will say that any political leader of any democratic and sovereign nation accused of anything can be overthrown by the American government because... well, just because.

At least three of those examples during the Cold War are pure bullshit

Does mike know how to accidentally throw in the towel or what? But you still managed to even fuck that one up in three, two, one...

Chile 1973

http://www.faqs.org/cia/docs/56/0000096947/OVERVIEW-STATEMENTS-ON-CIA-INVOLVEMENT-IN-CHILE-IN-1970.html

Primary CIA activity in Chile was to conduct spoiling operations against the candidacy of Salvador Allende in the 4 September 1970 elections without, however, supporting either of the two non-Marxist presidential candidates. This effort focused on a propaganda program to alert the Chilean people to the dangers of a Marxist regime under Allende. A total of $425,000 was spent in this endeavor which was approved by the 40 Committee and was carried out in close coordination with Ambassador Korry in Chile and State Department officials in Washington.

A second Agency activity was conducted between 15 September 1970, after the popular plurality won by Allende, and before the election of Allende by the Congress on 24 October and his inauguration on 3 November. A total of $153,000 was spent in

http://www.faqs.org/patents/asn/1686
http://www.faqs.org/patents/asn/16553
http://www.faqs.org/patents/asn/1735

Google wants a proprietary system, because THEY have something they can trade with; non-proprietary systems lower the barriers to entry.

http://www.faqs.org/patents/asn/1686
http://www.faqs.org/patents/asn/16553
http://www.faqs.org/patents/asn/1735

Google wants a proprietary system, because THEY have something they can trade with; non-proprietary systems lower the barriers to entry.

http://www.faqs.org/patents/asn/1686
http://www.faqs.org/patents/asn/16553
http://www.faqs.org/patents/asn/1735

Google wants a proprietary system, because THEY have something they can trade with; non-proprietary systems lower the barriers to entry.

have been doing it for alot longer than us. Often around here outside it sounds like a DDoS.

http://www.rfc-editor.org/rfc/rfc1149.txt

http://www.faqs.org/rfcs/rfc2549.html

...but did you know it has actually been implemented?

http://news.bbc.co.uk/2/hi/africa/8248056.stm

Yeah it's stupid to replace to own post, but here is latest list of subsidiaries of Google Inc. Like you can see their jurisdiction is marked for every one of those countries, and they are actually established in them.