[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How to treat an Amiga User By the The Shit heads of Team Amiga.

To: amiga@k332.feld.cvut.cz
Subject: How to treat an Amiga User By the The Shit heads of Team Amiga.
From: "Timothy Rue" <timrue@mindspring.com>
Date: 09 Jan 99 01:24:24 -0500
Organization: MindSpring Enterprises
Sender: cz-comp-amiga@pandion.vslib.cz

What to expect from the assholes of Team Amiga.

Fuck you Gary Peake.

1. Who is Tim Rue?
1.1 Tim as a liar.
1.2 Tim as a loon.
1.2.a Others' observations
2. VIC - stranger than fiction.
2.1 What is it?
2.2 What isn't it?
3. What can we do?
3.1 Fire with fire.
3.2 Passive aggression.
3.3 Killfile instructions for common newsreaders
3.3.a NewsRog
3.3.b Turnpike
3.3.c Outlook Express
3.3.d Thor
3.3.e Tin
3.3.f UMS - Added Jan. 7, 1999
4. Administrivia.
4.1 FAQ maintainer.
4.2 Submissions.

1. Who is Tim Rue?

Tim Rue, aka Timmy, aka T. Rue, is best described as the town fool
of the comp.sys.amiga.* Usenet hierarchy. Whether you're discussing
the future of the Amiga hardware/software platform, or simply asking
advice on which brand of modem to purchase, Timmy's guaranteed
to jump in with bizarre paranoia-filled rants about government
suppression and NDAs (non-disclosure agreements). Lately this
has shifted to include something or another about profits and freely
accessible archives. Previous tangents about "Ask the children!"
seem to have been dropped from his manifest.

Know this: anything you say to him will be interpreted as a personal
attack. If you compare something he said to something you read
earlier that day, he'll think you're accusing him of plagiarism. If you
ask him to clarify a point, then you're obviously not willing to "search
the publicly accessible archives", and therefore out to destroy him.

1.1 Tim as a liar.

As of late, Timmy's chosen the annoying habit of inventing elaborate
conspiracies involving well-liked and public Amiga figures. For
example, Team AMIGA is supposedly a shadow organization run for
the specific contradictory purposes of 1) destroying the Amiga and
2) selling merchandise to Amiga owners (which would actually
prolong the Amiga's lifespan, ironically). If Timmy cites a proper
name in his postings, you can be assured that the following
statements are lies. Of course, it's theoretical possible that Timmy
could say something positive about a public figure; however, since
that hasn't happened yet, you may safely overlook that possibility.

1.2 Tim as a loon.

Let the man speak for himself:

In <4808.577T2728T6376118@mindspring.com>:

"Actually, this very thing about illusions directly relates to the high
level of faulty information the Amiga community generates. If the base is
illusional then there really is no way to generate valid information."

In <966.577T1695T7375077@mindspring.com>:

"When there is no hope of advancement, yet unending illusions of it, it
must be clowns at work. :) So what can you do but laff at them?"

In <2964.578T891T6604073@mindspring.com>:

"I see where you are involved in Amicon, well guess what, I don't know you
or anyone involved and I'm sure there are alot of others who also don't
know. But when they go looking for information that is being mentioned
elsewhere and they cannot find it, and they say something about it, does
this give you the right to take offence. Perhaps you are trying to justify
this by saying your non-profit? Well it's no excuse to find offence and if
anything I'd say dump non-profit so as you might have motive to see
straight."

The scary part is that he *can* be almost rational for up to a paragraph
at a time. However, Deja News failed to find an entire coherent post,
and mostly he changes subjects in the middle of his sentences.

1.2.a Others' observations

"IMHO (and I wish I was clinically qualified so that I knew WTF I was
talking about (grin)), Tim's personality disorder includes a Messiah
complex - he KNOWS he's right, and his critics and detractors are all
fools. His mission is to save the rest of the Amiga world by making them
see the light of his genius. I think, even if ignored, he'll just keep on
making declamatory posts for the indefinite future. Having said that, it's
the bandwidth wastage that's the key issue here and FAQ and Killfiles are
definitely a good way forward along with simply not responding in public
to him."

[note from Ed.: Bill later forwarded this later to amplify his point]

---8<-----
Article 203794 of comp.sys.amiga.misc:

>Timothy Rue <timrue@mindspring.com> scribbled the following:

Thanks for the feedback. This along with other posts over time lead me to
see something I've not wanted to accept.

People can take this a arrogant or egotistical if they want, I no longer
care about flames.

Point blank. I'm beyond the perceptions others are at. Not only with the
VIC but also with marketing and I do wonder about other issuses to, but
these two issues I'm sure about.

I suppose the thing to do, is to see if I can raise others up to where
I'm seeing things.

[...snip....]

So in trying to raise others up, it's not easy but apparently I'm having
some success.

:) I probably do come off as a messiah to some. But I'd prefer not to be
preceived this way because all it tell me, is that some are so lost from
self awareness, or whatever blockage they have, that they don't realize
where they are really getting information from. NO IT'S NOT SOME IMAGINED
GOD.
---8<-----

Bill Bennett
----

An anonymous contributor:

A psychologist I know (off the record, this isn't a diagnosis, I'm not
responsible, etc. etc. etc.) says that Tim shows signs of schizoid or
schizotypal personality disorder (not schizophrenia, or multiple
personality disorder). This is typified by non-sequetirs, disconnected
thoughts, and paranoid delusions.

I have actually visited Tim's web site and it seems pretty clear that
this is probably a good diagnosis. I would not be surprised if Tim is,
or has been, on anti-psychotic medication.

I think the correct thing is to ignore him.

2. VIC - stranger than fiction.

The VIC saga started a while back, although its exact roots are lost
to history. In its current form, though, Timmy has evolved VIC into the
solution for all things Amiga (and possibly more).

2.1 What is it?

Timmy himself says in <5091.577T443T13023941@mindspring.com>:

"Mostly what the general, but educated in VIC use, end user will preceive
is that the VIC is a tool that allows them to easily make productive use
of the vocabularies of applications. To do so in order to automate the
things they often do. To define a single word that the user can hand the
VIC to set in motion such automation. But the VIC also allows the user to
continue to build their personal vocabulary using base vocabulary of
applications as well as vocabulay they have already defined."

This is pretty much as verbose and detailed of a description that we've
been allowed to see, so any speculation is pure conjecture.

To his credit, one tiny code fragment does really exist: an AREXX
script he calls "IQ". Noone's really sure what it's supposed to do,
but it can be safely run without trashing your hard drive.

2.2 What isn't it?

For starters: real.

3. What can we do?

Ahhh, the time-honored question. Sooner or later, something has to
be done before Timmy entirely takes over Usenet.

3.1 Fire with fire.

The first and most satisfying solution is to simply flame the hell out of
him at every turn. When he opens his mouth, flame him. When he
calls someone such as Gary Peake a liar and a thief, flame him. If
he whines about profit or children or something else, flame him.

It's fun, it's easy, and it doesn't cost much.

However, as tempting as it may be, this isn't the recommended course
of action. First off, it's often like kicking a wet bag of sand. He'll
respond with something totally unrelated, and you'll wonder why you
even bothered. Second, Timmy's cardinal sin is killing scarce
bandwidth. The last thing needed is to encourage him to dump yet
more drivel into our haven.

3.2 Passive aggression.

Although not as immediately gratifying, a long-term approach is
certain to be more effective at ending this nonsense.

1) Add /"Timothy Rue" <timrue@mindspring.com>/ to your
newreader's killfile. This is the *surest way to reclaim our turf*. If
everyone in these groups were to immediately and permanently
ignore Timmy's postings, he would be gone within a month.

2) Since someone or another is bound to reply to him, thereby
encouraging him to continue, spread the word to new users you
encounter. When you see a reply with his name in the header,
send this FAQ or your own explanation to the user. Remember,
he can't keep burning without fuel!

3) Forward particularly slanderous postings to
postmaster@mindspring.com. Don't get carried away here! This
is a last-ditch effort if you've clearly been lied about!

The key rule, though, is to JUST IGNORE HIM. Don't talk to him.
Don't trade e-mail. Don't acknowledge his existence.

Together, we can win.

3.3 Killfile instructions for common newsreaders

The killfile idea is all well and good, but if you don't know how to use
them, they're rather worthless. Therefore, here are some quick
instructions for adding Timmy to the killfiles of some common newsreaders.

3.3.a NewsRog

Easy! Click on an article by Timmy. Click on the little skull-and-cross-
bones icon above the articles listview. On the popup window, click on the
top cycle gadget until it reads "Kill all by same Author". Then, click on
the bottom cycle gadget so that it says "Kill Current & Future Articles".
Next, click on the "Expiration" gadget so that it's unchecked. Finally,
click "Kill".

3.3.b Turnpike

"Here's how to do it in Turnpike, a good newsreader supplied by Demon in
the UK to the PC users it has.

Enter the following custom rule:

^References:\s*<[^<]*@mindspring\.com>h

And it will kill any message replying to Tim Rue."

Thanks to: Alex Ingram

3.3.c Outlook Express

1) Click the "Tools" menu.
2) Click the "Newsgroup Filters" submenu.
3) This will open the "Newsgroup Filters" window. Click "Add".
4) "Group(s):" should be set to "All Servers (All Files)". If not, click
on the entry to get a pop-up menu, and choose it.
5) Click in the box next to the "From:" line. Enter:

timrue@mindspring.com

Leave the "Subject:" line blank. Make sure that the "Message has
more than..." and "Messages posted more than..." items are NOT
checked. Click OK at the bottom.
6) Click OK again on the "Newsgroup Filters" window.

3.3.d Thor

Note: This is a 3rd party submission. I haven't personally verified the
instructions, but it seems pretty reasonable. Also note that this
particular user carries the idea a little further. :)

With Thor
----------
I have two general rules using From and To fields for specific
users what, sadly, flows the "comp.sys.amiga.*" Amiga NG's.
Selects the menu item "Kill/Emphasize Database" ("Windows" menu),
and press "New" button for adding every rule. And fill the
following fields with theses contents:

(Rule #1)
>From name : ?(Tim? Rue|Mat#? Ortmann|QwertY|timrue@mindspring.com|
ortmann@informatik.tu-muenchen.de)#?
Mode : Kill
Conferences : COMP.SYS.AMIGA.#?
Level : 1

(Rule #2)
To name : ?(Tim? Rue|Mat#? Ortmann|QwertY|timrue@mindspring.com|
ortmann@informatik.tu-muenchen.de)#?
Mode : Kill
Conferences : COMP.SYS.AMIGA.#?
Level : 1

3.3.e Tin

"For TIN 1.4, hopefully I have this correct.

From within the offending message
^K (CTRL+K)
<enter> Skips to Kill Subject. <space> to toggle no.
<enter> skips to Kill From. leave Yes or <space> to toggle yes. *
<enter> Skips to Kill Msg-Id. <enter> leave no or <space> to toggle no.
<enter> at kill lines.
<enter> at score rules.
At Kill time in days <space> to toggle as appropriate. *
At Kill pattern scope <space> to toggle as appropriate. *
<enter> should be at the q)uit e)dit s)ave option.
<s> to save the settings.

(*) The important settings.

PS: You can modify your "Kill Time In days" settings from the TIN
configuration menu or in the tinrc file."

- Thanks to Dave K.

3.3.f UMS

Use the command:

sumsset Sysop PASSWORD "msgid=*"**timrue@mindspring.com*"" Expired

The second command expires every follow-up to timothy rue. Unfortunately
it also expires everything going to other mindspring customers in public.

sumsset Sysop PASSWORD "referid=*"**@mindspring.com*"" Expired

The sumsset tool can be found on aminet in comm/ums in the Sumstools
archive.

- Thanks to Richard H.

4. Administrivia.

This FAQ was first written on October 2, 1998, by Kirk Strauser (who
is actually a member of Team AMIGA, but not high-ranking enough
to be allowed to participate in the conspiracies. :).

4.1 FAQ maintainer.

Once again, that be me, Kirk Strauser.

4.2 Submissions.

If you have suggestions, additions, or corrections, please write to:

teknique AT honeypot DOT net

If you're Tim Rue, and feel like responding, be advised that I consider
all e-mail on the subject to be fair game for reprint. Stated more
clearly:

If you write to me, I'll feel free to include your letter in the next
revision.
--
Kirk Strauser Member // http://members.dialnet.net/teknique/
Team AMIGA \X/ http://csc.smsu.edu/~strauser/RA.html
New page! See http://csc.smsu.edu/~strauser/honeypot.html for system info

And why?

<HTML>

At the moment, KOSH is a website, a small group of people with a lot of ideas,
energy, vision and commitment, lot of people wishing to support it and offer
help and resources, and a dream about a truly innovative future. In order to move forwards,
we need to firm out where we want to be in the future. Once we have a picture of that
future, we have two ends of a possible path. It then becomes possible to firm out
that path. So, our direct future plan sees;

<OL>
<LI>An operating system on a CD
<LI>Machines that can run that operating system
<LI>Development tools for that operating system
<LI>Applications that run on that operating system
<LI>Individuals active in the KOSH market
<LI>A lively, interactive and vocal Kommunity deciding the direction of KOSH
<LI>A commercially strong KOSH company promoting and encouraging the Kommunity
</OL>
Points 1 & 2

Designing and developing a new OS and set of machines to run it is no easy task in the
best resourced of circumstances. That it can be done has been proved to an extent by the
Linux community, although they have been at it for a good few years. 
KOSH has to be both realistic and innovative. On the Hardware side, there is a lot
of good stuff already out there but there is also a blockage in design innovation due
to adherence to a standard architecture. KOSH will address this problem by specifying only
a set of hardware specifications. These specifications will have an open end, to allow
for HW vendor inspired hardware implementation (standard or custom) and a rigidly defined
end, that presents a common set of hardware services to a Hardware Abstraction Layer/
Hardware Services Manager. We hope that KOSH will be able to run on anything, existing and future. 
The KOSH OS will ultimately be a virtual OS. As long as it can find a HAL/HSM to which it
can dock, then hardware specifics are irrelevant. The docking will be accomplished
by a BOSS (Basic OS Services) object. This is the element that will provide the
environment in which virtual activity can exist. All application developers will either
directly call the BOSS or indirectly call it, through other elements. Applications are thus
developed for the OS, not for the underlying hardware. To jumpstart the process, we may just
hitch a ride though. 
The result of this approach, apart from great flexibility and adaptability, is that we are
moving away from gigantic, monolithic releases. With the hardware specification, a developer
*can* design a brand new custom system from scratch, but equally, an existing machine
could be used. Similarly with the OS, as long as the virtual environment can be sustained,
then the OS can be shipped. It thus becomes upto third party developers to populate that
environment. The end result is that we should be able to have a sustainable basic system up and running
quite quickly for KOSH 1. 
Whilst this all sounds great, there are potentially huge problems with trying to design
and organise across the net, and by committee. To ensure that we make the best use of resources
and the most timely progress, a rigid development plan is being created and will be adhered to
in all its aspects. This project will be done in a professional manner. Small working groups
of no more than seven, working in parallel to a time defined plan and utilising full peer
review protocols will enable us to achieve the seemingly impossible. Each of us though has
a responsibility to keep the momentum going, even when we hit the potholes, as we undoubtedly
will at some point. 
The first phase of the project, will be a requirements
definition and initial design. This will tell us whether we have the people, the ideas
and the commonality to create KOSH. The deliverables of this phase will be a requirements
definition and high level architecture. It will also include a development plan
detailing tools and machines to be used for development, and a first phase schedule.
This is scheduled to last 3 months from the inception of the Logical Architecture
Working Group (a week or so away as of 01 Dec 98). 
The second phase of the project is the full design phase. This will see the logical design
specification processed and extended, a fleshing out of the principles and logical
architecture leading to the creation of firm technical documents and specifications. This
period will see the first "real" development activity as prototyping and research is used
to solidify the implementation plan. This phase is also scheduled to last
3 months. 
The third phase is the implementation or development phase. The technical specs are handed out,
coding and unit testing starts, followed by integration to alpha, private beta and public
beta testing. On the Hardware side, the completion of the Hardware specifications should
enable hardware vendors to begin either retrofitting KOSH to existing machines and designs
or designing new machines for KOSH. Hardware templates will be developed by KOSH for licencing
out. This phase is scheduled to last 6 months, at the end of which, KOSH 1 should be sitting
on a CD awaiting installation and KOSH machines should be either ready or nearing completion. 
Points 3, 4, & 5 
Without applications, a platform is nothing but expensive furniture. Back in the home computer
days, anyone could develop an application with a bit of intelligence and some free or cheap
tools. The increasing "professionalism" of computing in the last ten years has made
this an increasinly hard pathh to take. Only in the community platforms has this occured
at all, as evidenced by the large amounts of PD and shareware generated. KOSH intends
to reverse this trend and ensure that anyone who wants to can develop on KOSH, whether it
be children with Visual Logo, hobby coders with BASIC or professionals with C/C++,
Java, E, Rebol or any other language. 
By being a Kommunity platform, KOSH expects people to get involved to see what they want come
alive. This is obviously true for the design of KOSH, which will provide full documentation
and tutorials as well as conforming to a minimalist environment design, which encourages an
ecology of applications and objects to populate it. Less obviously, the tools for development
need to be developed. The innovative nature of KOSH is screaming out for an equally as
innovative set of design, development and testing tools. True virtual engineers manipulating
components in a foundry or workshop. Again, the Kommunity has to get involved. 
It can play its part by developing and promoting a unique support package. It will be
unique because the very developers who need to use it will be the ones that design it. No
one knows what support they need better than the people who do need it. By being actively
able to participate in and construct the developer support program, they can guarantee
that they will get what they require. 
Writing an application is a time consuming and expensive task. Traditional application
development cycles call for monolithic, infrequent projects, a period of high return, declining
rapidly as development costs rise for the next release. KOSH allows this model to be broken by
promoting an object sea ecology. A developer can create a container within the sea that acts
as a home for a set of objects, and then release the objects frequently for a small amount of
money each. In this way, the massive efforts of swinging out giant applications are
replaced by frequent, continuous development, which provides the developer with a more
continuous revenue stream whilst allowing users to buy only the objects that they require,
and customise their systems according to their needs and tastes. 
Of course, the big issue, especially for commercial developers, is deciding to invest
in learning, and outfitting for a new platform. Such investment is risky at the best of
times but, with a project such as KOSH, a platform that doesn't exist yet, it is "across
the crocodile pond with nitro glycerine on a pogo stick" risky. Commercial developers,
as part of the Kommunity can only be expected to invest savings and jobs and livelihoods
in developing for KOSH if the users, retailers and journalists, the other members of the
Kommunity, let them know of their support, that they will be hungry for products.
Of course this all depends on both sections of the Kommunity seeing real progress from
the creators and the maintainers. We are
all bound together, and if KOSH is to succeed we must all play our part in it. 
The plan here is to form a development working group. It's task will be to
specify a plan, not a traditional plan for putting manuals online or taking money to get
priviledged information, but a plan that opens up the whole area of development for the
platform. KOSH is not a traditional platform - it doesn't want traditional solutions. 
In addition, because of its Kommunity nature, KOSH offers a unique opportunity to build
new economic models. Instead of the rigid producer/consumer model, KOSH's reliance upon
Kommunity allows for developers and users to work together. Developers don't have to guess
what users want and risk putting out a product that bombs. Users don't have to risk
$50 on a product that may turn out to be useless to them. The object sea model allows for
frequent releases and intimate relationships. It also allows for the true development
of the subscription model, where users get involved and pay a certain amount a month
or year for a certain set or number of objects. A working group will be formed to investigate all
these possible ways, and to help strengthen, and at the same time, break down the bonds
between the different groupings in the kommunity. 
Point 6 
Many people have said they don't like the name KOSH. However, an analysis of it will reveal
that is it the perfect name. It defines the three parts of the platform and puts the most
important part in front; the K for Kommunity. 
Komunities arise when a platform offers something more than just computing. When it offers
challenges, when it empowers, when it encourages discussion and debate, when what is put
into it makes it more than just another product, just another customer base and revenue
stream. 
In return Kommunity offers the most valuable resource possible; itself. The best usability
lab, the best support structure, the best brain storming group, the best evangelists.
Traditional companies pay consultancies millions of dollars to provide these services
but a Kommunity that is honoured and cherished provides them as part of its input into
the platform. 
For KOSH, the Kommunity IS the platform. The OS and Hardware are just tools that allow the
Kommunity to be, to express itself, to develop, communicate, show off, play and advance
forwards. KOSH helps to build them as they help to build KOSH. A lively, vibrant Kommunity
can only be built by lively, vibrant people getting involved, giving time, stepping
forwards and building that Kommunity. For those who believe in the ideals and the aims of
KOSH, please get involved. The adventure will be truly worth it and in ten years time, hopefully
you will be able to look back and say to people, I am KOSH, I helped make that become real. 
The plan for the Kommunity is open ended because the Kommunity must write the plan. Mailing
lists and IRC channels are one thing, the Monthly K is another. There are many more. Until the
platform is built, it seems strange to have a Kommunity but this is the most important time,
because getting involved now in the formative stage of the platform means a person can have
direct influence in the future, at whatever level. 
Point 7 
KOSH needs to be a commercial entity in order to provide full protection to its IP
and product line. These are very important points. KOSH will generate IP through the
actions of its members. Although we are still in discussion, the ownership of that IP
needs to be equally shared between KOSH, the entity and those who create it, whether
it be individuals or all the members of a Working Group. In doing this, KOSH benefits from
having free use of that IP and the individuals benefit in being able to licence that
IP to others and make money for their own efforts. How ownership of IP created
will be determined is a point being discussed at the moment. </TD>
</TR></TABLE></CENTER>

</BODY>

</HTML>

Follow-Ups:
- Re: How to treat an Amiga User By the The Shit heads of Team Amiga.
 - From: togath@swcp.com
- Re: How to treat an Amiga User By the The Shit heads of Team Amiga.
 - From: Kirk Strauser <teknique@honey/removethis/pot.net>

Prev by Date: Re: Linux na PPC + CVPPC
Next by Date: Re: SS 3.10
Prev by thread: Re: SS 3.10
Next by thread: Re: How to treat an Amiga User By the The Shit heads of Team Amiga.
Index(es):
- Date
- Thread