next »

[CodeLobe]

Arrays of yellow cables race through the air to and fro hanging like thick spiderweb.  Beneath them black racks of servers whir and chatter softly in a language only they understand, "He's here".  Drives seek and blink small red LED eyes dimly illuminating the coolness in waves emanating from one lonely sysop in the corner.

Cody Love perches atop a stack of obsolete hardware fashioned into a makeshift desk; His face lit by a sole terminal's CRT glow; Fingers tap dance noisily on the rustic keyboard in his lap.  A file tree listing struggles to scroll up the old monitor causing the aged drive to chirp and groan while sending small pulses of activity through the severs' room.



A beige case creaks beneath Cody.  He manages to blurt out "2038?!" before bursting into a fit of hearty laughter.  "How can I clean OLD files off this workstation if the data is from the FUTURE!?  HA Hahahh..ha...hmm", he ponders momentarily.  A clatter of keys slings the contents of one of the files onto the screen.



"I don't really remember making any of this", remarks the system operator leaning in close to the screen, bathing his glasses in mirrored reflections, "but these are my files".  Strange yet almost familiar lines of source code scroll up the display littered with esoteric symbols and names, bits of Latin, and even stellar constellations.  "No", Cody thinks aloud, "code isn't familiar... some of the source style is, but these symbols--"  He stops short as a page fills with code tracing the shapes of sacred eastern geometry.



The [PG DN] key gives a loud hard smack.  Page after page of maddening sigils flash by whitening Cody's finger, compelling it to press even harder.  He stands up abruptly and shakes his head free of the spellings that were forming in his mind.  Reaching behind the small tower at his feet Cody flips the unit off and unplugs its cables in one expert motion.  "I either wrote this when I was blasted out of my gord, and forgot.  Or else...  naw, it couldn't be."

Computer case slung under one arm, Mr. Love peers suspiciously up and down the hallway.  "Coast is clear.  You're coming with me",  he says to the deaf metal box. Scurrying as nonchalantly as possible down the hall he passes his desk, swipes at a secure exit at the end, and expels himself from the building's rear.

"Another one bites the dust!", Cody barks a little too loudly at a disinterested security guard whos gaze lifts not even one eyebrow.  "Just act cool!", Cody silently commands himself. "Acting normal would have been not saying a damned thing", a cooler sysop replies, "I've done the same thing 5 times today, no big deal"   The workstation is gently placed into a dumpster near several other of its dead kin.  Cody carefully waterproofs it by tucking a bag of shredded paper around it, whispering, "Sit tight, we're almost home."


Compiler Hunter (working title) is a game designed for computer science wizards, apparently.  After decoding a series of esoteric messages and demonstrating some basic CS skills a virtualized computing environment of some kind springs to life out of a batch of files from decades in the future.  The eve of March 1st, 2038 to be precice.

Having compiled itself for the machine architecture the system finds itself on (I've tested 32 bit & 64 bit x86, on BSD, Linux & Windows), the system occupies a significant amount of memory (over 3GB) and consumes nearly all system compute resources, pegging as many cores as available at 100%.  Not exactly sure why yet (probably has something to do with the way it executes its "logic").  Despite the high CPU load, the host OS remains fairly responsive. Maybe it's just playing "nice"?

When unable to connect to the workplace network, this system attempts to periodically send data to a known website address, but I am not yet sure why.  Thus, for now it is left completely disconnected from the web (I'm not sure if the system would defeat a software firewall or not, better safe than sorry).

This "system", which I'm now calling Fusys (abbreviation of "Future System", or "F@%& you, Sysop"), runs as a userland executable yet defies attempts to inspect its memory while it is executing. Somehow the host OS is crashed when a debugger is attached (on all Windows OSs & Linux kernels I can find, as well as the newest version of FreeBSD, amazingly).  Trying to single step from the first program instruction seems like a randomized walk through the program memory: Every couple of instructions accesses some random looking memory value, mixes it through pre-existing register values, stores a cryptic value in memory and on the stack, then issues "ret" to "randomly" jump somewhere else.  This continues for longer than I have patience, but if allowed to run the host OS will eventually hang, BSOD or "Kernel Panic" so long as the debugger is attached.  Might be due to sending garbage parameters to an OS syscall, but I can't be 100% sure.

In addition to the binary executable itself, memory snapshots of the program when stored in the /swap/ partition upon suspending the host OS seem to be encoded somehow -- it's all gibberish, no plaintext or apparent blocks of data or CPU instructions (but surely there must be, surrounded by what looks like noise).  The memory seems opaque except for two 4k pages of RAM.  One which is all zeros, the other all zeroes except three 32bit values 0x93000004, 0x0a090307, 0x402f3e5f.  Modifying any but those two pages in the /swap/ storage crashes my host system upon resume from suspend.

After a bit of probing a simple ASCII text protocol can be discovered: The two (mostly) empty 4K memory regions are apparently memory mapped to /tmp/[fusys].io (where [fusys] is a bunch of gibberish).  The tech wizard then develops a small application to decode, display, and communicate with Fusys by reading and writing to the aforementioned pages / memory mapped .io file.  A quirky shell-like environment is encountered displaying colored ASCII text (though I'm not 100% sure yet which indexes should map to what colors in the palette):


..........
...@/>_...
..........

?

Within the shell there are a few files that can be viewed via command line.  Some are executable programs which can be ran.  Other files document a (partial?) list of terminal commands.  A few files are .txt containing cryptic riddles.


That was level one, apparently.

Now, I suppose the next stage of the game is to try and discover more about the OS "architecture" (if it has one) by finding a compiler, or creating one.  Hence the (working) name "Compiler Hunter".  The player is unaware what CPU architecture Fusys is emulating, but if it's x86 or ARM or MIPS then the binary files are encoded somehow (doesn't look like any standard instruction set I've seen).  Perhaps the player will have to discover more documentation or begin by modifying the contents of the "binary" executables seen in the terminal?  Those initial bootstrapping files with all the weird symbols might have a clue?  We shall see.

Perhaps the player will begin by making a "hello world" program (with raw hex opcodes, by trial and error if need be).  Then proceed to construct an assembler / disassembler so the system can be explored beyond what's listed in the shell.

I haven't figured out a way to save & load game state yet, so for now one has to do everything over again from scratch if Fusys crashes or is terminated (or if it decides to crash the host OS).  This has slowed my progress somewhat, but hasn't been too much of a bother yet.


I realize the target demographic of this game may be severely limited due to the skills required to play, but if even just one player "beats the system", I think it might be worth it.

Note: Tentatively marked 10% complete since the Fusys "virtual environment" currently exists in this timeline.  I am not sure what percent complete I'm actually at, to be honest.

I plan on creating a bridge between a network attached PC and the isolated PC running FuSys somehow, using some "sanitized" data transport (no complex NIC hardware talking to eachother directly, I don't trust it with any direct connection between Integrated Circuits).  Hopefully this will ensure FuSys can't "escape" its containment (not sure if it's even trying to, but just to be safe). 

Once a clean data transport is established I can implement a "telnet" style interface or a client served by the relay machine so others can access the system remotely.  I had thought about just uploading the core files to everyone, but I have a bad feeling about that for some reason.

However, if Fusys really is from 2038... then its creator(s) may be able to anticipate ANY move I make.  Future me would have had decades to figure out a way to defeat whatever precautions I take, and I don't know who I'd be working with or what their motives are -- I could be under duress in the future, or even dead!  Well, certainly dead given a long enough projection, but you know what I mean.  I don't know if I should trust future folks nor their time-traveling Operating Systems.  Hmm.

More research is required.  I'll keep you posted.

[CodeLobe]

A serial port requires an integrated circuit to modulate and demodulate a stream of data (typically RS232 modem).  However, those old "obsolete" parallel printer ports do not need any additional ICs!
 
Therefore, a parallel printer port is incredibly "sanitary".  No worries about something getting in through a bug in the modem chip and changing a system's RAM.  The 1's and 0's in memory map directly to the pins on those old parallel ports, 1 is +5v, 0 is Ground.  Couldn't be simpler.

Unfortunately I didn't have much to work with at home, no nice plastic adapters, and no electronics store open at 3am either.  So I used a bit of a paint stirring stick as a "circuit board" and soldered the parallel port wires to some thin solid copper wire such that I could plug it into a bread board. 



The resistors are required so I don't blow the LEDs.  Now I have a way to get data out of the PC with Fusys.  But I don't have a parallel port on my other systems, they're all somewhat new (I didn't even notice the PCs I bought didn't have parallel ports).  USB has taken over, but it's a SERIAL bus... and I know bad things can easily happen over USB.

My program to interface with Fusys reads the system's "output" page and sends it byte by byte over the parallel port.  I could do the same to read from the port and write to the "input" memory page of Fusys.  However, I don't have any parallel ports on my new systems (and for some reason I'm wary of just direct connecting the systems).  Fusys is VERY tricky.  At times I feel like it has anticipated my actions -- or someone knew what I would do and preprogrammed a response.

In any event, I'll have to figure out some way to get data into the other relay system and also send data back in so that the game can have players besides me anyway.


What's mildly "troubling" is that this particular solution seems ideal and was so easy to stumble upon just by looking at the ports on the old machine.  Almost too easy.  I feel like I'm missing something.  I don't think there's any way something can hop across such a simple 1 = 1, 0 = 0 interconnect, but I can't be 100% sure.


I've realized that certain programs executable within the Fusys shell have strange command line options that don't do exactly what one expects.  I must re-investigate everything I thought I knew.

[CodeLobe]

Recent events have had me considering new theories of space and time travel.

Many people (including my past self) assumed that the motion of the earth itself would eliminate (or incredibly complicate) time travel;  However, upon researching the issue, I've discovered there have not been any experimental results which indicate the core of this assumption to be true...  Light & electromagnetic experiments consistently failed to detect displacement of the aether -- which most popular theories of movement predict (if a luminous aether exists).

Einstein attempted to dispel the aetheric medium yet did not explain by what mechanism light would propagate then -- it certainly propagates through water, must not "vacuum" actually be "something" too, and therefore match the nebulous "luminous aetheric medium" description through which light propagates?  The Lorentz Tranform was invented to fit the lack of observation of the aether into physics.  However, instead consider that the earth's aether may be quantumly entangled with the earth.  The "aether" (or spacetime) could simply be entanglement itself.  Then EM fields and light propagation would actually operate as observation indicates.  The non-euclidean geometries of "stretchy" entanglement fabric would only really be seen over vast distances (or under small careful lab experiments -- such as teleporting quantum entangled atoms).

If the fabric of space itself is quantumly coupled to the local environment via entanglement, (inversely proportionate to distance squared!) and therefore moving with the earth (near its surface anyhow), then time can be decoupled from space.  More interaction in one region can create More Entanglement, and thus More Time happens in more dense environments (time would accelerate, not slow).  Time would slow in orbit because there is less matter to interact with, not because of reduced gravity.

This hypotheses poses a hard problem for astronomers who still claim to see light bending around galaxies and attribute it only to "gravity lensing" (a result of gravity bending spacetime). Does not light bend frequently here on earth sans super massive black holes?  Diffraction causes light to bend and scatter.  Curved rays can also be explained by light passing through a denser gas envelope surrounding a galaxy; Like light bends as it passes from air into a crystal ball...  Can not refraction exist in the heavens as it does on earth?  Is the sun's light not bent by the atmosphere causing sunsets to be orange?  Couldn't a galaxy's atmosphere bend light?  Perhaps it is not such a radical concept to imagine that "warped spacetime" may exist much differently than first imagined?  Clearly much more research needs to be done to put these questions to bed.

However, if entanglement was the fabric of space then this would mean that so long as a time machine were near a physical thing it wanted to appear near in the past, it could use that physical thing/place as an entanglement reference point -- an anchor containing the entanglement signature required -- much the way the two entangled photons allow a Boron atom to be transported through space by destroying one photon.  Thus space & time could be far more stretchy and non euclidean than the Standard Model currently predicts.

---

Imagine if matter from the future instantly materialized in the past somewhere near earth's surface.  It would no doubt occupy the same position as existing matter, even if it was only air.  A person's blood would be full of bubbles.  Or, the potential energy release caused by smashing a whole body of atoms together could be on the order claimed of thermonuclear blasts.  Survivability of organic life would be exceedingly difficult at best.

However, digital information stored on old tapes and drive platters are essentially just magnetic fields.  Note: SSDs work differently.  It would be far safer to transport some electromagnetic waves into the past which just harmlessly jiggle a magnetic field causing some bits to flip in an old hard drive.

If it were possible to evacuate a region of matter (air) to create a hard vacuum state, then perhaps popping into said vacuum out of the quantum foam would be possible (and far safer than becoming a super-collider).  One MIGHT be able to use a strong electromagnetic / electrostatic effect to repel or pull away the matter from a region -- if you do a small region at a time one might be able to "slowly (and painfully?)" move matter into the past?  This means that IF time travel to the past IS possible, then sending electromagnetic waves back in time would probably still be a primary requirement.  And if it's a prime requirement then why not just send data back from the future as EM waves?  Someone would certainly want to test that.  Perhaps some would want to send something more advanced than simply, "Hello Timetravel" back in time?  What purpose would they give a system like fusys?!  The mind reels at the possibilities.   

If you were looking for a good candidate to send data back in time it would be best to target a machine that you had a detailed schematic and part list of (check, we have those on file), and the machine would have to sit in a precise location in the past, unmoved and not powered up (drive not spinning) for a long time -- the longer the better. (Check, those old machines were piling up in the storage closet for years, some nearly a decade, and left permanent visible marks in the press-board shelves).  AND you'd want to be sure the machine would be turned on at some point to discover the "new" data from the future (Check, per our hardware disposal policy).

I've searched around and not found anyone who is deliberately creating an environment conducive to reception of electromagnetic data transfer from the future, but who knows what's done in secret?  Perhaps I just accidentally myself into being a good test candidate?  Perhaps the invention of SSD / solid state storage also limits the available window of data projections?  What if the future folks could only send data back to certain points in time because of this?  Couldn't very well send EM waves back into a clay pot and have cavemen do anything meaningful with it, or could they?

On the other hand, the whole Fusys shebang could just be an elaborate prank to screw with me.  Seems a bit "advanced" for something made in a stupor and simply forgotten for years.  But wouldn't it be risky too as the data could have easily been just deleted -- or got destroyed by some other coworker?  On the gripping hand, I have been the only dude who messes with crap in that closet for many years, and if you have the records of the past in the future then perhaps gambling isn't?

To preserve sanity I've got to approach this as a silly game, but a little caution doesn't hurt.  A game, that's what it has to be, or maybe will be in a few decades?  I'm shooting for sooner rather than later.  Maybe nothing will happen at all.  OR!  Maybe I won't even exist in this timeline by the morning?  (Note to self: Call relatives & tell them they're loved).

[CodeLobe]

I was going to participate in Lundum Dare #41, and started working on a game for about 30min, but my Internet@home went down for most of the weekend, so meh.  Internet now works again for my home desktops & servers, and most (but not all) notebook computers.  Strangely some devices can no longer connect to WIFI!  The ISP assures me there was only a brief service interruption in my area, and no changes were made to the service, but now my phone, a laptop, and a few other devices don't see any connection to the Internet after (re)connecting to the (ISP supplied) Wireless router/modem.  I've completely reconfigured the blasted modem/router and factory reset a phone to give a blank slate, and still no connection, very odd.  Other devices CAN use the wireless without problem, which is incredibly WEIRD.  I've never seen anything like it, and I am a pro at diagnosing networking issues.  There is no software or hardware commonality between the devices that now fail to connect.

So what else would I do with the time I would Jam?  Try to examine Fusys some more, of course.  I get goosebumps just thinking how this outcome feels like part of some damned plan goading me in certain directions!  But Fusys is just on an old workstation, it doesn't even connect to my networks or have a wifi card, let alone control the Internet availability in a segment of a densely populated metropolis... At least, it sure as Hell better not!  How would future folks even coordinate such an eventuality?  It seems ridiculous that they'd have influenced my choice of dwellings and etc. minutia for so long just to get me to work on the Fusys project for 48hrs rather than a game jam, but human brains are influenced by EM waves, as new research into trans-cranial stimulation proves.  Hmm.  Well, if you could flip bits in the past, it doesn't seem far fetched that you could misconfigure or even cook a few chips in some network hardware relatively simply.  If it were me, I could do so by flipping a single bit in an ISP's gateway/routing table or perhaps the CPU power regulation circuit (now baked right into most Intel chips, see: "Dynamic CPU Voltage Offset" via Intel Extreme Tuning Utility, under voltage = crash).

Then again, it could just be pure coincidence, a spot of bad luck, and I'm just over-thinking things again.  Note to self: I need a stiff drink and a pedicure, preferably simultaneously.


Unfortunately, I have not yet decoded any single opcode of the binary executables, but I have made some progress in that direction.

Unable to discover a similar command (or program) in the shell I have managed to build a copy command within Fusys via the terminal's say command.

I am not sure how the shell script became marked executable!  There was no "shebang" line "#!/[path-to-exe/]" or similar signal to the shell, just a file with a few shell commands.  A "text" file created with the say command is not normally executable, and attempting to execute such a file prints an error message "Willn't execute negexecutable data: [file name here]" (also note the nonstandard linguistics).  The script I wrote to create a copy command was not executable either at first, and I know not how to mark a file as executable (no *nix chmod as of yet discovered).  However, after a brief time the file became listed as "executable" (i think) as is indicated by its change of color (which i've assigned to green in the simple terminal "client" / frontend, as such matches the Linux terminal). I can now execute the file without error.  I had just been using the file with commands in it to copy / paste rather than type out commands.  If you had future knowledge or if I'm creating the past now, then maybe future folks flipped the execute bit for me?

I have also discovered that either the Fusys shell or the say command uses some standard and nonstandard string escape sequences.  In C "\012\015" are octal escapes for decimal bytes 10 and 13. However, passing that string to the say command will echo back bytes 18 and 21.  Passing "\10\13" puts bytes 10 and 13 (decimal) into the "output" memory mapped page.  Thus the 0 prefixed values in Fusys strings seem to indicate hexadecimal encoding: In C (or Javascript, etc.) "\x12\x15" would be decimal byte values 18 and 21.  To create the newline / return string (decimal byte values 10 and 13) one can use "\10\13" or hex: "\0a\0d" (or "\0A\0D").  The standard character representations "\n\r" will produce decimal values 10 and 13.  I haven't discovered an octal encoding, perhaps Fusys doesn't use it.  Such subtle differences will no doubt make porting programs to Fusys a pain in the ass.

Note: The "\n\r" sequence is emitted to the Fusys "output" memory mapped page when the [Enter (or Return on Apple* Macintosh* keyboards)] is pressed or to begin a "new line".  At first glance I assumed this "\n\r" (10,13) sequence was the familiar MSDOS* line termination character sequence.  However, it is not!  The common sequence (also used in HTTP standards) is Carriage Return, Line Feed: "\r\n" NOT "\n\r".  Fusys outputs the pair reversed for no apparent reason, as "\r\n" seems to achieve the same effect as "\n\r" (advancing a line and returning to the first column), just in a different order.

I'll need to investigate more escape code mappings, I've seen garbled text in my terminal that are obviously due to control characters I do not yet implement (or understand), but for now I've moved on to a more important task:

By grokking these say / Fusys shell escapes I've been able to construct binary files in the Fusys shell.  Some things I've done previously seemed to increase the memory consumption of Fusys slightly, but strangely creating text files & scripts did not increase the RAM consumption of Fusys one byte.  I am not sure why or how Fusys is able to store new data without allocating more space.  Perhaps it's using some sort of compression?  Wait, if you already knew what files I was going to create, they could already exist in the system? and then just get "enabled"?  Hmm.  More research is required, those are just guesses.

When I have made modified copies of data by placing escapes in the say string prior to the copied executable via the "\0hh" escapes the program fails to become executable (even if bytes are duplication of data that appears at the start of the file).  I'm not yet able to write over data in the existing files, nor have I figured out how to make a copy of the Fusys executable binaries that can be modified, but I can insert bytes and strings into the front of the files in a sort of "concatenation" operation from within the shell.  However, as mentioned, I have not been able to execute the resultant files.

Appologies for the walls of text, I took some pictures of the screen Friday night but network difficulties distracted me & kept me from uploading them, so I'll have to upload them later -- unless me attempting to upload pictures of Fusys CAUSED the network outage?  I can't be sure but I really am starting to feel like there are strange powers afoot.  The universe seems to work much differently than I've ever been taught.


A few ideas have started to form about how to get data in/out of the Fusys workstation safely and allow others to connect to it, but I haven't attempted to do so yet.  If things continue to be WEIRD then I may need to rethink my strategy if not the entire premise of my existence.


* Apple, Macintosh, and MSDOS are trademarks of their respective owners and have no affiliation or relation with myself, including but not limited to any creation, product, descendant, or ancestor thereof.

[CodeLobe]

Strings are apparently stored into the 4KiB output memory in 32bit big endian, though the host OS architecture (x86) is little endian, and some 32bit values stored in memory seem to be little endian.

For example, the initial hex octets 0c 00 indicate 12 characters follow. That is a little endian 16bit (or 24bit or 32bit?) value.  I have seen the value go up to 2000 (0x07D0 = d0 07 in memory). 2000 chars fit a classic 80x25 screen display. This consumes 4000 subsequent bytes as each character byte is paired with an attribute byte.

I don't know what 0x93 means in the output.  Changing this byte does nothing since the output 4K page is overwritten.  0c is seemingly a 16bit or 24bit value that indicates the number of characters encoded within the subsequent memory.

The text seems to be stored in big endian format though.  Thus, "Hello World!" is output as:

Code:

0c 00 00 93 - 07 07 07 0f - 07 0f 07 07 - 07 07 07 07 : ................
6c 6c 65 48 - 6f 57 20 6f - 21 64 6c 72 - xx xx xx xx : lleHoW o!dlr....

Which my current client renders as
...Hello World!...

The 4K region doesn't typically contain a full screen of output, just recently "printed" characters and their color( or attributes?).  The terminal "client" program just appends the bytes to its buffer, and this has worked OK so far (except when unrecognized control codes are output).   

In the example above there are 12 bytes of attribute data following the word 0x9300000c word (little endian 16bit values: 0x00c0, 0x9300 ?), and then 12 bytes of (ASCII?) character data in big endian (first byte is most significant byte value of a 32bit little endian word).  I feel like this is a clue to the internal representation of Fusys, but haven't been able to confirm (output could be sent through a transform just to f&@k over sysops).

I'm not sure if there are Unicode or other multi-byte encoded characters yet.  I can "say" byte ranges 00 to ff no problem into the text section of the output page, but I'm not sure what is supposed to come out on my display besides printable ASCII and a few control codes. As far as I can recall, all Fusys generated messages have had chars in the range of 0x00 to 0x7f (0..127 decimal) thus far.

For input I have been writing a 32bit little endian character length followed by a text string encoded as the above format "big endian text within 32bit little endian words".  The error messages which echo the input confirm that Fusys is interpreting input strings in the format detailed above.   Not sure if Fusys is polling for changes, but it does detect duplicate writes as a "change" / new command, even if the same exact data is (re)written, so perhaps it detects the memory mapped changes at the OS or filesystem level.

Note the 0x07 attribute i've assigned to "light gray on black" and 0x0f to light white on black, which is fairly standard as far as 16 color palettes go.  These colors may change if I discover what Fusys is trying to display.


I erased the images of the Fusys workstation enclosure. Internet issues with my phone went away shortly thereafter.
Perhaps this was just a coincidence?  The phone didn't receive any over the air updates or change any settings.  The laptop still did not  connect to wifi until I rebooted it (again) but this was AFTER the phone's radio connection started working again (the particular smartphone is one I use for development and has no mobile data plan, just WIFI).  I still have images of just the screen output, but I want to make a post and do some experiments just incase attempting to upload them caused any issues.  I'd like to re-take the images of the enclosure, just to test some hypotheses, but for now I won't tempt the fates.



It occurs to me the non-standard newline format could be a hint about Fusys internals. The Newline Wikipedia entry only lists the use of LF/CR order (not CR/LF) as used by:
   "Acorn BBC and RISC OS spooled text output"



The "Acorn BBC Micro" (pictured above) ran a 2Mhz 6502 (a little-endian 8-bit processor).  That doesn't explain the strange "mixed endian" text.  Not sure if the Acorn BBC Micro or RISC OS has anything to do with Fusys.

The 4K I.O. pages seem to use 16bit or perhaps 32bit values, but that doesn't mean the system internally uses them.  We used to emulate 32bit and 64bit words on 16bit or 8bit hardware, and most C compilers did or can do this.  I would need to trap the actual MOV instruction(s), and other preceding instructions, but attempts to do so have crashed the machine.  I would normally be able to intercept memory accesses and opcodes via custom OS code + Hypervisor mode, but this old workstation hardware does not support such virtualization features.  I'm not sure if I should run Fusys on another system (or more than one system).  Multiplying the "F%#k you sysop" factor doesn't seem smart at this stage.