Can ext2 kernel run ext3 binaries.

[Database Administrator]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware rm@biteme.org wrote:
> A Gay Called Littledick wrote:
>
> pgp trash troll delete

You still love me. Wonderful. gonna assume the position on your
knees again like last time?

>>
>> signed with pride using tin 1.9.1 release 20060409 ("Benmore")
>
> And how is Benmore? Are you able to use it own your own yet?

Sender:
From: rm@biteme.org
Subject: Re: Can ext2 kernel run ext3 binaries.
User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/2.6.20 (i686))

Upgrade and find out your damned self.

Either way, you must love being called out all the time.

BL.
- --
Brad Littlejohn | Email: tyketto@sbcglobal.net
Unix Systems Administrator, | tyketto@ozemail.com.au
Web + NewsMaster, BOFH.. Smeghead! | http://www.wizard.com/~tyketto
PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGaKluyBkZmuMZ8L8RAgkvAKDB6GNk8wM/LQL8LpT8xTz07Tg4eQCg2RD2
u5azxIpUZvMq5x0eDAmRRwo=
=o/Wq
-----END PGP SIGNATURE-----

[Database Administrator]

Brad Littlejohnson trolled:

pgp trash troll delete

>>> signed with pride using tin 1.9.1 release 20060409 ("Benmore")
>>
>> And how is Benmore? Are you able to use it own your own yet?

> Upgrade and find out your damned self.

You're the one who should be upgrading. 1.92 is the latest unstable
version. 1.83, which we use, is the latest stable. If you need any
help with the installation, then give us a yell.

cordially, as always,

rm

[Database Administrator]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware rm@biteme.org wrote:
> Brad Littlejohnson trolled:
>
> pgp trash troll delete
>
>>>> signed with pride using tin 1.9.1 release 20060409 ("Benmore")
>>>
>>> And how is Benmore? Are you able to use it own your own yet?
>
>> Upgrade and find out your damned self.
>
> You're the one who should be upgrading. 1.92 is the latest unstable
> version. 1.83, which we use, is the latest stable. If you need any
> help with the installation, then give us a yell.
>
> cordially, as always,
>
> rm

And 1.9.1 < 1.8.3? So you aren't just an idiot, you are stupid
as well. Go try 1.9.2. knock yourself out. You'll see why I'm at 1.9.1.

Better yet, go back to cow tipping. It suits you better.

BL.
- --
Brad Littlejohn | Email: tyketto@sbcglobal.net
Unix Systems Administrator, | tyketto@ozemail.com.au
Web + NewsMaster, BOFH.. Smeghead! | http://www.wizard.com/~tyketto
PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGaL6/yBkZmuMZ8L8RAuhHAKDWRgzDUTjITQmXU4sCP3dZEaBP5gCfc/4U
0tf30XA0VX/Hjb40m5jI0TI=
=uXrS
-----END PGP SIGNATURE-----

[Database Administrator]

Sam wrote:
>
>Guy Macon writes:
>
>> Sam wrote:
>>
>>>Stop smoking crack. You've got a bad batch there, and it's
>>>making you see things.
>>>
>>>Here's the direct link to my last message, as archived by
>>>Google. Hey, putz, where do you see a MIME-Version and
>>>Content-Type after the first blank line?
>>>
>>>http://groups.google.com/group/alt.o...9ef7d263578bc?
dmode=source
>>
>> The first blank line is on line 23, right after line 22
>> (X-Postfilter: 1.3.34) and line 24 (This is a MIME...).
>> There is another blank line on line 29. On line 31 there
>> is a Content-Type line with (Content-Type: text/plain;
>> format=flowed; charset="US-ASCII"). 31 is a larger number
>> than 23 or 29, and thus line 31 comes after lines 23 or 29
>> and thus the Content-Type comes after the first blank line.
>
>And if you go and read RFC 2045 through RFC 2049, you'll perhaps learn what
>this means, and why you're wrong. About this, and a great deal of other
>things. Maybe you'll educate yourself a bit, and learn something. A little
>education never hurts.
>
>Denial won't make 2045 through 2049 go away. Sorry.

Evasion noted.

Speaking of denial, do you deny that you claimed that you do
not have a blank line before the Content-Type? Do you deny
that I proved that claim to be false?

[Database Administrator]

Sam wrote:

>Furthermore, the IETF working group is in the process of finalizing an
>updated *Internet* standard for *Netnews* messages, that basically sticks a
>fork in ancient fossils like you, who keep bleating like stuck pigs anytime
>someone posts a message that their ****ty newsreader chokes on, and who are
>still bitching about being have to deal with the realities of living in the
>21st century:

That document clearly states:

"All header fields in a Netnews article are compliant with
[RFC2822]; this specification, however, is less permissive
in what can be generated and accepted by agents. The
syntax allowed for Netnews article headers is a strict
subset of the "Internet Message Format" headers, making
all headers compliant with this specification inherently
compliant with [RFC2822]. Note however that the converse
is not guaranteed to be true in all cases."

You remember RFC 2822, don't you? That's the one that says

"A message that is conformant with this standard is comprised
of characters with values in the range 1 through 127 and
interpreted as US-ASCII characters [ASCII]."

and

"The body is simply a sequence of characters that follows
the header and is separated from the header by an empty
line (i.e., a line with nothing preceding the CRLF)."

Things aren't looking good for your practice of putting the
Content-type in the body (defined as after the first blank
line) instead of in the header.

[Database Administrator]

Guy Macon writes:

> Sam wrote:
>
>>Furthermore, the IETF working group is in the process of finalizing an
>>updated *Internet* standard for *Netnews* messages, that basically sticks a
>>fork in ancient fossils like you, who keep bleating like stuck pigs anytime
>>someone posts a message that their ****ty newsreader chokes on, and who are
>>still bitching about being have to deal with the realities of living in the
>>21st century:
>
> That document clearly states:

You are too stupid to understand what that document states.

> all headers compliant with this specification inherently
> compliant with [RFC2822]. Note however that the converse
> is not guaranteed to be true in all cases."
>
> You remember RFC 2822, don't you? That's the one that says
>
> "A message that is conformant with this standard is comprised
> of characters with values in the range 1 through 127 and
> interpreted as US-ASCII characters [ASCII]."

Einstein: go and find any message that I posted that contains anything else.
Hop to it, I don't have an entire day to wait.

> and
>
> "The body is simply a sequence of characters that follows
> the header and is separated from the header by an empty
> line (i.e., a line with nothing preceding the CRLF)."
>
> Things aren't looking good for your practice of putting the
> Content-type in the body (defined as after the first blank
> line) instead of in the header.

Things are not looking good for your stubborn stupidity of refusing to read
RFC 2045 through RFC 2049, which describe the format of multipart MIME
content, which specifies how the "body", as you stupidly call it, is
formatted in accordance with that specification.

It may come as a shock to you, that yes, accoring to RFC 2045 through RFC
2049, that is perfectly like. And you won't just find Content-Type headers,
my clueless friend, but any other valid header, such as
Content-Transfer-Encoding, Content-ID, but any other header.

But, again, if you prefer to live in the '70s, where things were less
complicated, and there weren't all those funny-talking furriners talking on
Usenet in some strange-sounding language, go find yourself a Tardis, and
have a nice trip.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBGaTlmx9p3GYHlUOIRAo5uAJwLYKlbD/eodPtBBzM+KOw28OrRCACfXHDI
vNAzzCCz/xVvyy78STB6YsA=
=wlwN
-----END PGP SIGNATURE-----

[Database Administrator]

Sam wrote:

>Guy Macon writes:
>
>> Sam wrote:
>>
>>>Furthermore, the IETF working group is in the process of finalizing an
>>>updated *Internet* standard for *Netnews* messages, that basically sticks a
>>>fork in ancient fossils like you, who keep bleating like stuck pigs anytime
>>>someone posts a message that their ****ty newsreader chokes on, and who are
>>>still bitching about being have to deal with the realities of living in the
>>>21st century:
>>
>> That document clearly states:
>>
>> "All header fields in a Netnews article are compliant with
>> [RFC2822]; this specification, however, is less permissive
>> in what can be generated and accepted by agents. The
>> syntax allowed for Netnews article headers is a strict
>> subset of the "Internet Message Format" headers, making
>> all headers compliant with this specification inherently
>> compliant with [RFC2822]. Note however that the converse
>> is not guaranteed to be true in all cases."
>>
>> You remember RFC 2822, don't you? That's the one that says
>>
>> "The body is simply a sequence of characters that follows
>> the header and is separated from the header by an empty
>> line (i.e., a line with nothing preceding the CRLF)."
>>
>> Things aren't looking good for your practice of putting the
>> Content-type in the body (defined as after the first blank
>> line) instead of in the header.
>
>Things are not looking good for your stubborn stupidity of
>refusing to read RFC 2045 through RFC 2049, which describe
>the format of multipart MIME content, which specifies how
>the "body", as you stupidly call it,

That's what the *RFCs* "stupidly" call it.

>is formatted in accordance with that specification.

RFC 2045 clearly states:

"All of the header fields defined in this document are
subject to the general syntactic rules for header fields
specified in RFC 822."

You remember RFC 822, don't you? That's the one that says

"A message consists of header fields and, optionally,
a body. The body is simply a sequence of lines
containing ASCII charac-ters. It is separated from
the headers by a null line (i.e., a line with
nothing preceding the CRLF).

and

"Header fields are NOT required to occur in any
particular order, except that the message body must
occur AFTER the headers."

and

"Headers occur before the message body and are
terminated by a null line (i.e., two contiguous
CRLFs)."

Things continue to look bad for your practice of putting the
Content-type in the body (defined as anything after after
the first null line) instead of in the header.

--
Guy Macon

[Database Administrator]

On Fri, 08 Jun 2007 06:11:34 -0500, Sam wrote:

>> That document clearly states:

> You are too stupid to understand what that document states.

Are you the same "Sam" dip**** who used to follow Alan Connor around and
reply to every single post he made with the "beavis" comments?

Looks like some of that moron rubbed off on you. In fact you're a bigger
ass than he was, which is hard to believe, but true.

Go bother some other newsgroup with your pedantic (and wrong) arguments,
doofus. Or, just **** off and die.


--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".

[Database Administrator]

Sam wrote:

>Yes, Einstein, in accordance with RFC 2045, you'll now find traditional
>mail headers in message bodies. Don't like it? Tough ****. Welcome
>to the 21st century.

What kind of headers was that again? *MAIL* headers???
Looks like you made a freudian slip there.

As has been explained to you several times, Usenet is not Email.
Nobody here is arguing against MIME in email. That's why it is
maned MIME: Multipurpose Internet *Mail* Extensions. Mail. Not
Usenet news. When they release MIUE, we will consider using it
in Usenet articles.

HTML, JPEG and Acrobat also have specifications. Does that mean
that all Usenet newsreaders have to handle them as well? How
about macromedial flash and microsoft powerpoint? If having a
specification that clearly says "email" means that the specification
applies to Usenet, why excluce all those other formats that have
specifications?

--
Guy Macon

[Database Administrator]

In alt.os.linux.slackware Guy Macon wrote:
> Sam wrote:

>>Yes, Einstein, in accordance with RFC 2045, you'll now find
>>traditional mail headers in message bodies. Don't like it? Tough
>>****. Welcome to the 21st century.

> What kind of headers was that again? *MAIL* headers???
> Looks like you made a freudian slip there.

So you are admitting it was a slip?

> As has been explained to you several times, Usenet is not Email.

Oh, so it wasn't a slip. The man is seriously confused? In fact,
that email and usenet are not the same is about the only thing you
are sure of, so naturally you want to misrepresent somebody's
argument so you can take advantage of your indepth knowledge.

> Nobody here is arguing against MIME in email. That's why it is
> maned MIME: Multipurpose Internet *Mail* Extensions. Mail. Not
> Usenet news. When they release MIUE, we will consider using it in
> Usenet articles.

Why would "they" release a MIME work-alike for Usenet when MIME
already works perfectly well for Usenet?

We find it pretty telling for someone who is _not_ an Electrical
Engineer, taking issue with using MIME for usenet because usenet is
not part of its official name.

> HTML, JPEG and Acrobat also have specifications. Does that mean
> that all Usenet newsreaders have to handle them as well? How

The better ones do. And if usenet is to survive, then all
newsreaders will support them.

Which name do you prefer? Phat Phuck, Macon Bacon Boy, or Pork
Store?

cordially, as always,

rm