Slashdot Mirror


OpenBSD Packet Filter Ported To NetBSD, FreeBSD

honold writes "just read this on deadly.org (from Pyun YongHyeon): "Hello there. I have ported pf to FreeBSD 5.0 Currently it works well, though many nice features of pf not tested. I have ported to make FreeBSD users know there is an another excellent stateful packet filter with BSD license. URL is the following. ftp://ftp.kr.freebsd.org/pub/FreeBSD-kr/misc/pf_fr eebsd_0.3.tar.bz2 Thanks." netbsd has a port as well Where are you, Linux?"

48 comments

  1. Linux is dead by Anonymous Coward · · Score: -1, Offtopic

    This shows which OS will survive. BSD is like a roach...

  2. Wow. by Anonymous Coward · · Score: -1, Troll

    It's a story so boring that even the trolls won't touch it. LMFAO.

  3. Where are you, Linux? by Rastor · · Score: 1

    "Where are you, Linux?" I'm not sure I understand the question; Linux has had packet filtering for years now...

    1. Re:Where are you, Linux? by Anonymous Coward · · Score: -1, Flamebait

      Linux's packet filter is a joke. It changes API and rule syntax every major release: ipfwadm, ipchains, netfilter. Let's not talk about all the security holes we discovered in ipchains.

      Brett Glass
      Glassware, Inc

    2. Re:Where are you, Linux? by josepha48 · · Score: 4, Interesting
      Then use netfilter.. its pretty nice... I'd agree it does change each release. But you can also use the old way still. 2.4.x has all 3 in it so you can pick which one you want to use. So while yes it has changed, it also has more options now (another point of view).

      Also both FreeBSD and NetBSD have had for a while ipfilter, which is able to 'keep state'. So they already had stateful filtering. At least that's what I thought the 'keep state' keyword in ipf was supposed to do. In FreeBSD 4.? they introduced ipfirewall or ipfw. FreeBSD 5.0 has ipfw2 which does a great job at keeping state. Just use ipfw -d show and you see what is going through your firewall in the state table. Actual ip:port to ip:port listing. I wish it had something like ipfilters ipfstat -t command.

      FreeBSD now has 3 choices as far as stateful packet filtering go, ipfilter, packet filter and ipfirewall. What really needs to be done is metrics on all these to show which is actually better under FreeBSD. Metrics that show performane as well as features. Also ease of understanding.

      --

      Only 'flamers' flame!

    3. Re:Where are you, Linux? by Anonymous Coward · · Score: 0

      Come on, dude, think for like two seconds and you'll figure it out. The article is about pf being ported to FreeBSD and NetBSD. When he asks about Linux, he's obviously talking about a port of pf to Linux.

    4. Re:Where are you, Linux? by Dan+Ost · · Score: 1

      Linux packet filtering is not as elegant as
      what OpenBSD has created.

      Sure it works, but it's much easier with pf.

      --

      *sigh* back to work...
    5. Re:Where are you, Linux? by Bishop · · Score: 1

      Sure it works, but it's much easier with pf.

      Says the person who has not bothered to learn Linux Netfilter. I use both. My config files for both are equally easy to read and use.

    6. Re:Where are you, Linux? by Anonymous Coward · · Score: 0

      This is /. man. Not too many people here with a clue... Most of them use RH and the likes; which explains most of them...

    7. Re:Where are you, Linux? by Anonymous Coward · · Score: 0

      Linux? What is ``Linux''? ;-)
      So now we have one more reason to upgrade to 5. Can't wait for RELENG_5.
      (In fact i like Linux - I just like BSDs more.)

    8. Re:Where are you, Linux? by rabidcow · · Score: 1

      Could you provide an example? Last time I set up a firewall on Linux, I had to use ipchains, which was baffling to no end. I gave up on any manual configuration and went with linuxconf.

      pf is practically configured in english, I actually know where the config file is, and I can easily understand it weeks later without digging through the man page again.

      I've taken a quick look around www.netfilter.org, but the best I've seen is stuff like:
      iptables -t filter -A INPUT -d $PUBLIC -m state --state INVALID -j log
      iptables -t filter -A INPUT -s localhost -d localhost -j ACCEPT
      iptables -t filter -A INPUT -s $PUBLIC -d $PUBLIC -j ACCEPT
      iptables -t filter -A INPUT -d $PUBLIC -m state --state RELATED,ESTABLISHED -j ACCEPT

      which is still fairly opaque compared to:
      pass in quick on $xif inet proto udp from 10.150.88.1 to 255.255.255.255 keep state
      pass in quick on $xif inet proto tcp from any to ($xif) port 22 keep state
      block in log all

    9. Re:Where are you, Linux? by rsax · · Score: 1
      From the IPF Howto:

      We want convenience and security in one. Lots of people do, that's why Ciscos have an "established" clause that lets established tcp sessions go through. Ipfw has established. Ipfwadm has setup/established. They all have this feature, but the name is very misleading. When we first saw it, we thought it meant our packet filter was keeping track of what was going on, that it knew if a connection was really established or not. The fact is, they're all taking the packet's word for it from a part of the packet anybody can lie about. They read the TCP packet's flags section and there's the reason UDP/ICMP don't work with it, they have no such thing. Anybody who can create a packet with bogus flags can get by a firewall with this setup.

      I remember ipfw getting actual state features like IPF has. I'm more accustomed to the BSD operating systems so I'm not sure how Linux accomplishes this, does netfilter maintain a state table as well or does it still act like how the excerpt from the IPF howto describes it?

      Then use netfilter.. its pretty nice...

      In all fairness, IPF and PF seem to have a way better/intuitive syntax compared to iptables. Since we're talking about Linux here, a community which usually considers having more choice when it comes to software a good thing, I think it would be beneficial to have more choice where packet filters are concerned.

    10. Re:Where are you, Linux? by dirkx · · Score: 1
      Are you sure ? (see http://www.benzedrine.cx/pf.html for a nice 'TODO' list for netfilter/ipchains).

      Specific things which are 'killer apps' to me are the ease by which you can configure things like blocks/groups of ports, services, machines - and then re-use those in your cluster config or wider rules.

      This has safed us many hours of debugging downtime; and allows a much wider new range of 'new sysadmins to be' to deal with the simpler requests; such as adding a machine, service or port,

      As it is fairly safe to modify the right table/macros/lists - without having to have a complete understanding of every detail. And yet, when designed by an experienced hand, robust enough not to be bitten by an overly broad side effect.

      Have a look at http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/s rc/etc/pf.conf?rev=1.19&content-type=text/plai n - to see good examples.

      Dw.

    11. Re:Where are you, Linux? by Anonymous Coward · · Score: 0

      Why make the Linux remarks?
      I do find a lot of *BSD people being frustrated with Linux' success, while *BSD seems to be quite obscure...

      Seems to me that if that is neccesary, it must be a less fun community.

    12. Re:Where are you, Linux? by Strog · · Score: 1

      It's out

      5.0 was released 2 months ago. Even the /. editors know

    13. Re:Where are you, Linux? by josepha48 · · Score: 2, Informative
      Hmmmm. ipfw has check-state, setup and established. Yes it does keep track of the state as it does have a state table. To see the state table in ipfw use ipfw -d show. To see the state tables in Linux you can look at the /proc filesystem. Not sure if iptables has an actual option for this. Under one of the /proc directories (can't remember which one) it has the state table of all the connections that the kernel knows about.

      Truth is that if you want a secure system shutdown your unused services. Use keywords like setup (ipfw) or NEW (iptables) to keep track of new connections. Log new connections, user -j LOG in iptables, 'log' in ipf and ipfw. Not sure what the syntax is in pf. Lastly use ssh over telnet and ftp and REQUIRE shared keys. Webservers are hard to secure, because of 'stray' or possible badly coded cgi. DNS servers should only be run when necessary, or on the internal lan. Use things like ipsec w/ racoon to secure systems so that connection traffic can be encrypted.

      --

      Only 'flamers' flame!

    14. Re:Where are you, Linux? by TheLink · · Score: 2, Interesting

      AFAIK ipf keeps track of the tcp sequence and ipfw doesn't (it does track the tcp port numbers). So while ipfw2 does keep state, I'm not sure you could say it does a great job of it.

      With ipfw you have to rely on the O/S getting the tcp sequence right. Which is probably not a problem.

      With ipfw you have a certain degree of control when stateful rules are checked- on first stateful rule or on a check-state ruke. With ipf you don't - stateful rules are checked before all other rules. This means with ipf it is harder to shut down selected stateful connections without affecting other stateful connections.

      Netfilter? Still immature, and resembles ipchains too much for my liking. It looks significantly uglier too compared to either ipf or ipfw.

      The firewalling stuff was one of the major reasons why I picked FreeBSD instead of Linux for my machine (it has to firewall amongst other things).

      --
    15. Re:Where are you, Linux? by Everlone · · Score: 1

      He means the -STABLE branch of the 5.x series, not the tag for 5.0 Release (which would be the RELENG_5_0)

  4. why this is interesting? think high availability by ubiquitin · · Score: 5, Insightful



    I'm going to take up the challenge here of explaining why this is interesting. Since November of 2002, OpenBSD's pf has had support for load balancing. RedHat's $2499 Premium Edition of their Enterprise distro features Piranha load balancing which was derived from the Linux High Availability project.

    So what the OpenBSD pf project is giving you is enterprise-class high availability and load-balance clustering for a tiny fraction of the price. With a handful of cheap dotcom-throw-away x86 servers, a small company or mildly well-capitalized individual can personally build a multi-datacenter-fault-tolerant clustering setup that will rival Fortune 500 uptime ratings.

    In other words, the pf project's list of accomplishments is starting to read like a ToDo list for RedHat's Enterprise Linux development team.

    --
    http://tinyurl.com/4ny52
  5. And the linux guys say "Huh?" by Anonymous Coward · · Score: 0

    Yes, they are behind the stick, again...

    1. Re:And the linux guys say "Huh?" by Anonymous Coward · · Score: 0

      Somehow I sense some envy here...
      Linux has the publicity and the large userbase.
      BSD has got the "we are better" attitude...

      Posts like this make *BSD look like a frustrated bunch.

  6. *sigh* by cperciva · · Score: 3, Interesting

    When porting pf was first proposed on the FreeBSD mailing lists, the general opinion was that it would be a Bad Idea. pf may be great, but having two firewalls built into FreeBSD has caused much confusion in the past.

    Remember, perfection comes not when there is nothing left to add, but when there is nothing left to take away.

    1. Re:*sigh* by smnolde · · Score: 2, Interesting

      I use ipfw's DUMMYNET features for traffic shaping and queuing. I also use ipf and ipnat for the hardcore stateful packet inspection and kernel-level NAT. It works great.

      But when pf is fully ported with AltQ and tables, I'll only need one packet filter, not two.

      I think porting pf to FreeBSD is great. We'll have more options for packet filtering, queuing, bridging interfaces, etc.... besides, there's so much among the BSDs so this benefits everyone.

    2. Re:*sigh* by Anonymous Coward · · Score: 0

      Agreed.

      When I started using Linux, ipfwadm was it. It worked well and I was happy with it. Along came ipchains, and I wasn't happy with the idea of converting. So I decided to wait a while and see if it was going to be around a while. In the mean time I tried out FreeBSD and was quite happy with it and ipfw. Along came iptables. I've seen no reason to switch to it. I'll stick with ipfw. Perhaps I'm lazy for not wanting to learn the reinvented wheel, or perhaps I just don't see the benefits of the new wheel.

    3. Re:*sigh* by Anonymous Coward · · Score: 0
    4. Re:*sigh* by davet · · Score: 2, Interesting
      Remember, perfection comes not when there is nothing left to add, but when there is nothing left to take away.
      But on the other hand:
      If all you have is a hammer, everything starts to look like a nail.

      On my part, I like the idea that there's more than one way to do something.

    5. Re:*sigh* by cperciva · · Score: 1

      If all you have is a hammer, everything starts to look like a nail.

      Similarly, if all you have is *three* hammers, everything still looks like a nail.

    6. Re:*sigh* by Ded+Bob · · Score: 1

      You would not happen to have a simple example of using dummynet along with ipf or know of a good starter doc? I have ipf and ipnat set up the way I like, but I would love to play around with the traffic shaping and queuing.

      That article about giving ARP's higher priority sparked my *need* for it. :)

    7. Re:*sigh* by Anonymous Coward · · Score: -1, Troll
      So why now? Why did *BSD fail? Once you get past the fact that *BSD is fragmented between a myriad of incompatible kernels, there is the historical record of failure and of failed operating systems. *BSD experienced moderate success about 15 years ago in academic circles. Since then it has been in steady decline. We all know *BSD keeps losing market share but why? Is it the problematic personalities of many of the key players? Or is it larger than their troubled personalities?

      The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.

    8. Re:*sigh* by smnolde · · Score: 1

      try this: h tee tee pee //w ww.smnolde.com: 7080/ipfw/ipfw-queue-bw-only (munged to protect my cable connection)

      It's a script (that I wrote to do queuing and traffic shaping with DUMMYNEY. I used IPFW2 in the kernel. If you remove any references to esp, then you've got a good place to start.

      The script will queue tcp and udp, in, out, or in both directions. Give it a whirl.

      - Scott

    9. Re:*sigh* by Ded+Bob · · Score: 1

      Give it a whirl.

      Thank you. I will.

      P.S. You may want to also munge the link just under your name on each post if you want to protect you cable connection.

  7. Woot. by xA40D · · Score: 1

    I've been waiting for this for sooo long.

    Alas, it's lagging behind OpenBSD's PF

    From the TO DO section of the readme:

    merge new features from OpenBSD 3.3 pf
    - traffic shaping using ALTQ
    - load balancing between multiple routes
    - prevention up-link saturation for xDSL users

    --
    Do you mind, your karma has just run over my dogma.
    1. Re:Woot. by Strog · · Score: 1

      to be fair, 3.3 isn't out yet so the new features are still in current. Give it a little time and we will be rocking.

      A new perspective by having it running on other OSes should improve pf and make it better than it already is.

  8. Question by Quill_28 · · Score: 1

    This may be a little offtopic as it applies to firewalls and not BSD, bear with me.

    Why all the different firewalls programs, do they function differently, perform different functions?
    Different target user or target networks?

    They all seem to be trying to do the exact same thing? Why the variety?

    1. Re:Question by overbom · · Score: 3, Informative

      Yes, they differ in implementation and configurability. FreeBSD's default firewall, ipfw, is pretty easy to set up and configure, and it's pretty powerful. Darren Reed's ipfilter is arcane to set up and insanely powerful. From what I've heard of obsd's pf is that it's pretty easy to set up and insanely powerful.

      Most firewalls more or less do the same thing, but the devil is in the details. Some firewalls can do much more than others can, and that's why there are multiple firewalls available. For example, Darren Reed's ipfilter can process packets based on any of the TCP flags in the packet header -- not an option that an entry-level sysadmin wants to have to worry about, although a security expert might be uncomfortable without it.

      Most of the firewalls can be set up to do host-based and network-based packet filtering (that's firewalling).

      Hope this helps.

    2. Re:Question by Quill_28 · · Score: 1

      So for a home network set-up, ipfw should be fine. It is when you want to get down and dirty you might choose ipfilter.

    3. Re:Question by overbom · · Score: 1

      You got it. The thing that is neato-dandy about 'pf' is that it may be suitable for both home networks (ipfw) and down and dirty firewalling (ipfilter/ipf).

    4. Re:Question by dohcvtec · · Score: 1

      ipfilter is arcane to set up
      Whatever gave you that impression? Setting up IPFilter is very straightforward. The rules are modeled after spoken sentences - for example:
      pass out quick on le0 proto tcp/udp from any to any keep state
      What's arcane about that? If you can't figure out what that line is doing, you probably shouldn't be setting up a firewall anyway. pf's rule syntax is based on IPFilter's, and that's a Good Thing. Other than that, pf adds many new and improved features over IPFilter. By the way, FreeBSD's ipfw isn't terribly difficult to set up, but if you're going to call anything arcane, it should be ipfw's syntax, along with Linux's ipchains.

      --
      -- Never hit a man with glasses. Hit him with a baseball bat.
    5. Re:Question by overbom · · Score: 1

      I'm trying to simply address firewall questions to a kid that doesn't know firewalls -- I'm not trying to broadcast my genius here. My impression, having used ipfw on FreeBSD and ipf on Solaris is that ipfw is easier to use for this kid if he's just getting in to firewalls.

      Admit it, if he's not a genius with TCP/IP, seeing all the options for blocking on TCP headers are going to scare the heck out of him.

    6. Re:Question by Quill_28 · · Score: 1

      kid? hmpf!

    7. Re:Question by overbom · · Score: 1

      Heh. Sorry about that. I, uh, umm...

      Quick, look over there! /poof of smoke /runs away

    8. Re:Question by phoenix_rizzen · · Score: 1

      IPF / PF syntax is fairly easy to read, but nowhere near as clear as IPFW. Using your example:

      allow tcp from any to any via le0 keep-state
      allow udp from any to any via le0 keep-state
      (I'm not sure if IPFW supports multiple protocols on a single line.)

      I mean, does it get any closer to English than that??

    9. Re:Question by empath · · Score: 1

      In pf:

      pass in on le0 inet proto { tcp, udp } from any to any keep-state

      --
      "Please don't sigh like that, maam"
  9. Almost, not quite by Anonymous Coward · · Score: 0

    Yes, they are behind the stick, again...

    They are always in front of the "stick," bent over & ready to go.

  10. *BSD is dying by Anonymous Coward · · Score: -1, Troll
    It is official; Netcraft now confirms: *BSD is dying

    One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

    You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

    FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

    Let's keep to the facts and look at the numbers.

    OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

    Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

    All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

    Fact: *BSD is dying

  11. Developer lashes out: What Killed FreeBSD by Anonymous Coward · · Score: -1, Troll
    The End of FreeBSD

    [ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]

    When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.

    Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.

    FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.

    It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.

    So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.

    Discussion

    I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.

    From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.

    There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.

    Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.

    Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?

    Shouts

    To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.

    To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It

  12. DYING! DYING! DYING! by Anonymous Coward · · Score: -1, Troll

    DYING!dYing!DyINg! dying! dYInG! dyinG! DyinG! dYINg! dyING! DYing! DyInG! dYiNg! DYiNG! dYInG! DYing! DyING!dYING! dYInG! DYING! dyING! DYing! DyInG! DYING! dYing! DyINg! dying! dYInG! dYING! dYInG! DYING!dyING! dYing! DyINg! dying! dYInG! DYing! DyInG! dYiNg! DYiNG! dYInG! DYing! DyING! dYING!DYING! dyInG! DyING! DYINg! dYing! DyINg! dying! dYInG! dyinG! DyinG! dYING! dYINg! dyING! DYing! DyInG! dYiNg! DYiNG! DYING! dYinG! dYInG! DYing!DyING! dYING! dYInG! DYING! dyING! DYing! DyInG! DYING! dYing! DyINg! dying! dYInG! dyInG! DYING! dYing! DyINg! dying! dYInG! dyinG! DyinG! dYINg! dyING! DYing! DyInG!dYiNg! DYiNG! dYInG! DYing! DyING! dYING! dYInG! DYING! dyING! DYing!DyInG! DYING! dYing! DyINg! dying! dYInG! dYING! dYInG! DYING! dyING! dYing! DyINg! dying! dYInG! DYing! DyInG! dYiNg! DYiNG! dYInG! DYing! DyING! dYING! DYING! dyInG! DyING! DYINg! dYing! DyINg! dying! dYInG! dyinG! DyinG! dYING! dYINg! dyING! DYing! DyInG!dYiNg! DYiNG! DYING! dYinG! dYInG! DYing! DyING!dYING! dYInG! DYING! dyING! DYing! DyInG! DYING! dYing! DyINg! dying! dYInG! dyInG! DYING! dYing! DyINg! dying! dYInG! dyinG! DyinG! dYINg! dyING! DYing! DyInG! dYiNg! DYiNG! dYInG! DYing! DyING! dYING! dYInG! DYING! dyING! DYing! DyInG! DYING! dYing! DyINg! dying! dYInG! dYING! dYInG! DYING! dyING!dYing! DyINg! dying! dYInG! DYing! DyInG! dYiNg! DYiNG! dYInG! DYing! DyING! dYING! DYING! dyInG! DyING! DYINg! dYing! DyINg! dying! dYInG! dyinG! DyinG! dYING! dYINg! dyING! DYing! DyInG! dYiNg! DYiNG! DYING! dYinG! dYInG! DYing! DyING! dYING! dYInG! DYING! dyING! DYing! DyInG! DYING! dYing! DyINg! dying! dYInG! dyInG! DYING! dYing! DyINg! dying! dYInG! dyinG!DyinG! dYINg! dyING! DYing! DyInG! dYiNg! DYiNG! dYInG! DYing! DyING! dYING! dYInG! DYING! dyING! DYing! DyInG! DYING!dYing! DyINg! dying! dYInG! dYING! dYInG! DYING! dyING! dYing! DyINg! dying! dYInG! DYing!DyInG! dYiNg! DYiNG! dYInG! DYing! DyING! dYING! DYING! dyInG! DyING! DYINg! dYing! DyINg! dying! dYInG! dyinG! DyinG!dYING! dYINg! dyING! DYing! DyInG! dYiNg! DYiNG! DYING! dYinG! dYInG!DYing! DyING! dYING! dYInG! DYING! dyING! DYing! DyInG! DYING! dYing! DyINg! dying! dYInG! dyInG! DYING! dYing! DyINg! dying! dYInG! dyinG! DyinG! dYINg! dyING! DYing! DyInG! dYiNg! DYiNG! dYInG! DYing! DyING!dYING! dYInG! DYING! dyING! DYing! DyInG! dYING! DYING! dyInG! DyING! DYINg! dYing! DyINg! dying! dYInG! dyinG! DyinG! dYING! dYINg! dyING! DYing! DyInG! dYiNg! DYiNG! DYING! dYinG! dYInG! DYing! DyING! dYING! dYInG!DYING! dyING! DYing! DyInG! DYING! dYing! DyINg! dying! dYInG! dyInG! DYING! dYing! DyINg! dying! dYInG! dyinG! DyinG! dYINg! dyING! DYing! DyInG! dYiNg! DYiNG! dYInG! DYing! DyING! dYING! dYInG! DYING! dyING! DYing! DyInG! DYING!dYing! DyINg! dying! dYInG! dYING! dYInG! DYING! dyING! dYing! DyINg! dying! dYInG! DYing! DyInG! dYiNg! DYiNG! dYInG!DYing! DyING! dYING! DYING! dyInG! DyING! DYINg! dYing! DyINg! dying! dYInG! dyinG! DyinG!dYING! dYINg! dyING! DYing! DyInG! dYiNg! DYiNG! DYING! dYinG! dYInG! DYing! DyING! dYING! dYInG! DYING! dyING! DYing! DyInG! DYING! dYing! DyINg! dying! dYInG! dyInG!

    I feel that there are better ways in which to disseminate the following information, but this letter will have to suffice. If you disagree with my claim that Coach Mother Fucker's disciples must be worn out from the acrobatics they have to perform to keep Coach Fucker from turning on them, too, then read no further. He is blinded by greed, but given the way things are these days, we must remember that even when the facts don't fit, he sometimes tries to use them anyway. He still maintains, for instance, that he is the one who will lead us to our great shining future. In order to solve the big problems with him, we must first understand these problems, and to understand them, we must discuss the programmatic foundations of his short-sighted op-ed pieces in detail. With all due respect, Coach Fucker constantly insists that he is a perpetual victim of injustice. But he contradicts himself when he says that his complaints enhance performance standards, productivity, and competitiveness.

    I may not

  13. It's dead Jim by Anonymous Coward · · Score: 0

    Subject says it all.