The domain is for
plaintext email only

  DE-OBFUSCATOR ping ping ping ...
Other LARTs include Stilson, crowbar, tyre leaver, lead pipe, gympie hammer, sledge hammer and the ever popular half a house brick.


!   .   !   .   !   .   !   .   !   .   !   .   !   .   !   .   !   .   !   .  v

!   .   !   .   !   .   !   .   !   .   !   .   !   .   !   .   !   .   !   .  v

History of Plaintext

The precedents for plaintext with the CRLF sequence for a new line go back to Donald Murray´s code used by Creed machines of the 1920s. The Baudot based codes were later replaced with US-ASCII based codes such as DEC-MCS, ISO-8859-1 (Latin-1), ISO-8859-15 (Latin-9) and UTF-8.

The precedents for the 80 column text limit also go back to Herman Hollerith´s BCD cards of around 1900 which originally had just 24 to 45 columns. These cards where later extended to 72, 80 and rarely 96 columns and Western EBCDIC-1047 (Latin-1).

The reason that 80 columns was chosen for cards and teleprinters is that longer columns are hard to read. This why the www (WCAG 2.0 1.4.8 2) requires that the "width is no more than 80 characters or glyphs (40 if CJK)". Note that for small screens on PDAs and phones it can be less, but never more than 80 characters. Terminals are also 80 columns for the same reason.

Plaintext is Required for Email

Email must consist of lines no longer than 80 characters with exactly one blank line as a paragraph break. Attempting to conceal obfuscated email with quoted-printable or base64 encoding will be reported to your ISP.

Microsoft text places a paragraph on one line often violating the 998 octet rule and certainly violating the 78 character rule. It also does not insert a blank line between paragraphs. It also uses non-ASCII or other non standard encoding such as Windows-1252, byte swapped UTF-16 or UTF-8 and uses alternate codes for common ASCII glyphs which may not display.

Though modern MUAs and browsers can scroll sideways email obfuscated in this way will not be read and will result in a network abuse complaint.

RFC 5322 Internet Message Format

2.1.  General Description

   At the most basic level, a message is a series of characters.  A
   message that is conformant with this specification is composed of
   characters with values in the range of 1 through 127 and interpreted
   as US-ASCII [ANSI.X3-4.1986] characters.  For brevity, this document
   sometimes refers to this range of characters as simply "US-ASCII

      Note: This document specifies that messages are made up of
      characters in the US-ASCII range of 1 through 127.  There are
      other documents, specifically the MIME document series ([RFC2045],
      [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that
      extend this specification to allow for values outside of that
      range.  Discussion of those mechanisms is not within the scope of
      this specification.

   Messages are divided into lines of characters.  A line is a series of
   characters that is delimited with the two characters carriage-return
   and line-feed; that is, the carriage return (CR) character (ASCII
   value 13) followed immediately by the line feed (LF) character (ASCII
   value 10).  (The carriage return/line feed pair is usually written in
   this document as "CRLF".)


2.1.1.  Line Length Limits

   There are two limits that this specification places on the number of
   characters in a line.  Each line of characters MUST be no more than
   998 characters, and SHOULD be no more than 78 characters, excluding
   the CRLF.

   The 998 character limit is due to limitations in many implementations
   that send, receive, or store IMF messages which simply cannot handle
   more than 998 characters on a line.  Receiving implementations would
   do well to handle an arbitrarily large number of characters in a line
   for robustness sake.  However, there are so many implementations that
   (in compliance with the transport requirements of [RFC5321]) do not
   accept messages containing more than 1000 characters including the CR
   and LF per line, it is important for implementations not to create
   such messages.

   The more conservative 78 character recommendation is to accommodate
   the many implementations of user interfaces that display these
   messages which may truncate, or disastrously wrap, the display of
   more than 78 characters per line, in spite of the fact that such
   implementations are non-conformant to the intent of this
   specification (and that of [RFC5321] if they actually cause
   information to be lost).  Again, even though this limitation is put
   on messages, it is incumbent upon implementations that display
   messages to handle an arbitrarily large number of characters in a
   line (certainly at least up to the 998 character limit) for the sake
   of robustness.

US-ASCII Plaintext Definition

ABNF for well formed plaintext <pre> human readable text </pre>:-

        SP = %x20
        CR = %x0D
        LF = %x0A
        VCHAR = %x21-7E
        CRLF =  CR LF
        line = 1*VCHAR *(SP 1*VCHAR) CRLF
        line = 1*80(SP / VCHAR) CRLF
        paragraph = 1*line CRLF
        plaintext = *paragraph 1*line

A SP / VCHAR is one of (%x20-7E):-

C0: ^@ ... ^_
          v> 0123456789ABCDEF
        %x00 ␀␁␂␃␄␅␆␇␈␉␊␋␌␍␎␏ + US-ASCII
        %x10 ␐␑␒␓␔␕␖␗␘␙␚␛␜␝␞␟ + Control0 (%x00-1F)

US-ASCII: ␠, ! ... ~, ^? (␡)
        %x20 ␠!"#$%&´()*+,-./ +
        %x30 0123456789:;<=>? |
        %x40 @ABCDEFGHIJKLMNO | US-ASCII (%x20-7F)
        %x50 PQRSTUVWXYZ[\]^_ |
        %x60 `abcdefghijklmno |
        %x70 pqrstuvwxyz{|}~␡ +

C1: M-^@ ... M-^_ or ^[+@ ... ^[+_
        %x80 @ABCD␤FGHIJKLMNO + ECMA-48  (vt220-8)
        %x90 PQRSTUVWXYZ[\]^_ + Control1 (%x80-9F)

Microsoft Windows only
        %x80 Windows-1252 has + Proprietary(Windows)
        %x90 Latin-9 and junk + Microsoft(%x80-9F)

ISO-8859 western variants: M-␠ ... M-?
        %xA0  ¡¢£¤¥|§"©ª«¬-®¯ + ISO-8859-1  (USA)
        %xB0 °±²³´µ¶·,¹º»¼½¾¿ + Latin-1  (%xA0-BF)

        %xA0  ¡¢£€¥Š§š©ª«¬-®¯ + ISO-8859-15 (Euro)
        %xB0 °±²³Žµ¶·ž¹º»ŒœŸ¿ + Latin-9  (%xA0-BF)

Western: M-@ ... M-~, M-^? (M-␡)
        %xD0 ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß | Western  (%xC0-FF)
        %xE0 àáâãäåæçèéêëìíîï | encoding
        %xF0 ðñòóôõö÷øùúûüýþÿ +

UTF-8 (KT´s encoding of Unicode) covers US-ASCII, ISO-8859-1 and others

 ASCII  0b0???????                                   U+0x0000..U+0x007F
 Latin  0b110????? 0b10??????                        U+0x0080..U+0x07FF
        0xc?..0xd? 0x8?..0xb? (ch&0xc0==0x80)
 16 bit 0b1110???? 0b10?????? 0b10??????             U+0x0800..U+0xFFFF
        0xe?       0x8?..0xb? (ch&0xc0==0x80)
 21 bit 0b11110??? 0b10?????? 0b10?????? 0b10?????? U+0x10000..
        0xf?       0x8?..0xb? (ch&0xc0==0x80)

UTF-8 is 100% compatible with US-ASCII.

ABNF for loose text <listing> source code or program output </listing>:-

        SP = %x20
        CR = %x0D
        LF = %x0A
        HTAB = %x09
        VCHAR = %x21-7E
        WSP = SP / HTAB
        CRLF =  CR LF
        looseline = 1*132(WSP / VCHAR) CRLF
        looseparagraph = 1*looseline CRLF
        loosetext = *looseparagraph 1*looseline

In the loose text the HTAB advances to the next multiple of 8 characters. It is important that a line not advance beyond 132 columns so the line may need to be less than 132 characters where HTAB is used.


HTML (2, forms, tables, 3.2, 4, 5), CSS (1, 2, MathML) and XHTML (1, 1.1, Basic).

Do you have Adobe Flash for Linux enabled?

[You do not have flash plugin enabled.]


Copy about:plugins to the address bar.

The Lightspark Flash Player may be downloaded from

Use the package manager in your distro for ready made players.

Cert: New one that I will get signed some day.

!   .   !   .   !   .   !   .   !   .   !   .   !   .   !   .   !   .   !   .  v
Written in VI.
Traditional (termcap) VI, Bill Joy
New Berkeley (curses) VI, Keith Bostic
an open operating system has not only advantages
for security, efficiency and power management it
can also be adaptable, versatile and effective.
New cool and efficient.
i386, AMD64, AMD32, ARM, MIPS, POWER, 680X0, System z, SPARC, ...
Girl with pet GNU she got when she asked Satan for a puppy.
Fire Fox has encountered a problem with Windows.

Win XP: C:\$MFT\foo Win 9X: C:\con\con

There once was a system called VMS
Of cycles by no means abstemious.
  It's chock-full of hacks
  And runs on a VAX
And makes my poor stomach all squeamious.

-- The Great Quux (Guy Steele)

Windows NT crashed.
I am the Blue Screen of Death.
No one hears your screams.

-- Peter Rothman

:( Designed for Microsoft Windows -->

Yesterday it worked.
Today it is not working.
Windows is like that.

-- Margaret Segall
Upgrade from Windows

VMS, the demise of DEC and Compaq and WNT bought to you by Dave "Get a job, get a job, get a job job job with Microsoft" Cutler.

The demise of HP-UX, HP/PA, and SGI Irix and MIPS bought to you by Rick Belluzzo. SGI XFS from Irix has survived and I run it on GNU/Linux.

Both went to Microsoft as a reward for their utter destruction.

Only the bullshit blue pill is available.
The bulshit blue pills only.
Wana Decrypt0r 2.0
Wana Decrypt0r screen shot
Run in snap shot with network disabled
and discard snap shot to restore files.
Junk "science" or Bullshit Hard science
Statistics which can not separate
cause from effect.
A testable hypothesis which demands:-
unequivocal qualitative results; or
quantitative results within experimental error.
literature review of work not testing
the same hypothesis; epidemiology; or
lies damn lies and statistics.
Real science.
The FDA and TGA only rely on junk science.
Stamp collecting, witchcraft, superstition.
Physics, physical chemistry, etc.
Result: no wiser, can only add to confusion. Result: gain wisdom.
/* Data loss and fail silent is the norm. */
int write(int fd, const void *buffer, unsigned int size)
{ /* _write, _commit, _read, compare, repeat */
	int w;
	long b, a;
	char *c;

	for(i=size;i>0;i-=w) {
		if((b=_tell(fd))<0) {
			goto write_ret;
		if((w=_write(fd,buffer,i))<0) {
			goto write_ret;
		if((a=_tell(fd))<0) {
			goto write_ret;
		if(_commit(fd)<0) {
			goto write_ret;
		if(_lseek(fd,b,SEEK_SET)!=b) {
			return -1;
		if(_read(fd,c,w)!=w) {
			goto write_ret;
		if(memcmp(buffer,c,w)!=0) {
		if(_lseek(fd,a,SEEK_SET)!=a) {
			goto write_ret;
	free(c); /* alloca() is easier */
	return size;
/* Give up and use something better. */

Visual Studio 6.0: C Run-Time Libraries

Just use write(2).