Re: A snapshot of the LuxAsm developments

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 12/18/04 

Date: Sat, 18 Dec 2004 14:50:51 GMT

Annie wrote:
> The Half A Wannabee said:
> > Today's Topics:
> >
> > 1. luxasm/_nasm/include syscall.inc,1.3,1.4 (Beth Stone)
> > 2. Territorial Pissings (Beth)
> > 3. Re: Territorial Pissings (C.R. Chafer)
> > 4. Re: luxasm/test hi.asm,NONE,1.1 (Frank Kotler)
> > 5. Re: Territorial Pissings (C.R. Chafer)
>
> Hmmm. Sounds like there's some dissension within the ranks.

Yes, but it would be more worrying if there _wasn't_ the occasional
"dissension within the ranks" from time to time, I'd say...

The other simple point to note is that Wannabee has grabbed posts off the
LuxAsm list like this in the past, many months and months ago...in other
words, he appears to be acting as some kind of "sentry" for RosAsm
"propoganda"...looking for problems and then posting them up here to help
with the "anti-LuxAsm" propoganda efforts...

I mean, it's clear that there could be no other possible reason for
Wannabee posting up this stuff to the newsgroup, other than to delibrately
"cause trouble"...as noted, the LuxAsm mailing-list _IS_ completely public
(and we _ARE_ aware of that - as, in fact, whether it's public or private
is a _SETTING_ we choose to make because you can set it to be "members
only" as much as "public" with a simple switch - in posting to it) so none
of this is "trade secret"...otherwise, indeed, Wannabee wouldn't know about
it to re-post it here...

And, as RosAsm "sentry" on the LuxAsm list, he's found two "disputes" worth
posting on this newsgroup in a year or so...oooh, big deal...that's hardly
a massive "track record" of terrible continual conflicts or
anything...indeed, he posted something like this before, if you
remember...and that was months and months ago and, yet, LuxAsm is now being
worked on much a'pace...so if this is sounding any "death bell", then,
ummm, didn't happen last time...

Perhaps in Rene's "dictatorship" there is no arguing or disputing with the
"King's" decisions...but that's not how we work over here...and, yes, it
involves fighting and arguments from time to time, to let everyone have
their say...this is not at all proof that "democracy" doesn't work, it
proves it's very much alive and functioning well...if there is a problem,
then we _CAN_ argue over it...on the other hand, when Rene clearly screws
up his "hash algorithm", then, in the "dictatorship", no-one does or can
dispute with the clear errors in the code...

A fight is often the prelude to a _solution_...if the Israelis and
Palestinians (or Republicans and Loyalists in Northern Ireland) are put
together at a table to discuss peace, there's _BOUND_ to be fights and
conflict...BUT that's not necessarily a bad thing if everyone's committed
to staying at the table...then the problems can be negiotiated and
_solutions_ found...if peace erupts in these places, it will surely be
preceeded with some very "hard bargaining"...this itself isn't a
problem...it's actually a very healthy sign for peace, if they are
_fighting over a table_ to _work out a solution_ rather than firing guns at
each other instead...

Indeed, in this case, C's proved to my satisfaction that his macros are
actually, indeed, sensible...though the "__NR_" constant forms should be
retained (my point) because there is also the C-level interface to consider
(whose names are "write", "read" and such - ELF has no "_" underscore to
separate C from ASM - so, to avoid "name conflicts", C's change from
"__NR_" constants should really be restored)...

In consequence, what you'll find from this dispute is that both C and I
will be likely to now adopt a "more comments" policy...that C might post
some explanations of what he's done to the list so that everyone else
understands what is going on better...that we'll discuss through changes
more before making changes...that we'll both be more tolerant of each
other's "modifications" (and, ummm, _BOTH_ of us might actually start
_READING_ the other's code before overwriting it on the CVS ;)...

We'll naturally develop out of this "fight" a means of working with each ot
her on the CVS...thus, in fact, this "fight" is going to improve things
overall and if we'd not had the "dispute" then things would have carried on
in an unsatisfactory manner for both of us...far, far better we "got it out
in the open", fought over it, worked out each other's positions and can now
proceed to _WORK ON THE CODE_ rather than work at fighting each other...

"What doesn't kill me, only makes me stronger"; Hence, in a democracy, you
don't fear people's "freedom of speech" because that's how a "happy medium"
is found, how everyone gets their "voice"...in a sense, that _IS_
"democracy" in a nutshell (after all, a vote is, if you like, just a
formalised way of giving everyone their say :)...

Disputes are not the fear...the far, far greater fear would be "fascist
dictatorship" where one rules over all and everyone else is to afraid of
saying anything...not just from the personal angle that being "oppressed"
is hardly fun but also from the simple practical point-of-view: If there's
a "dictator" and that "dictator" is _WRONG_, what then? Everyone suffers
eventually, dictator included...

The RosAsm hash algorithm was clearly WRONG but because of Rene's
"dictatorship", this _ERROR_ was not going to be fixed while the "dictator"
refused to believe it was wrong...and, in the end, it took an "outsider" -
Randy - to, in a sense, force the "dictator" to do something about it (oh,
indeed, not to suggest Randy was bringing it up to necessarily be
"altruistic"...but it has had that effect to improve RosAsm overall,
whatever the motivations..."attack" or "bugreport")...

It's similar to what the security experts say...they point out that the
lack of "biodiversity" is a _POINT OF WEAKNESS_...that is, if you write a
virus that can disable any Windows machine because most machines are
Windows machines, then you can worryingly take down a large proportion of
machines on Earth with a single virus (and when the big viruses show up, we
see the effects...like that latest one that shutdowns the machine
automatically (making it a pain in the arse to fix because it shuts down
the machine before you get a chance to download the "patch"...rebooting
many times just to find the Google page which says how to disable the
automatic shut down to give you enough time to actually get the "patch" in
the first place...a cleverly malicious design there ;)...it was taking out
emergency services and coastguards and other vital services out of
action...quite seriously risking people's lives for a virus "prank")...

Anyway, yes..."biodiversity" is a _STRONG_ and _ROBUST_ model (as always,
we should pay attention to Mother Nature more often because her designs are
usually excellent "role models" for our own designs :)...you can't take out
all machines with one virus when there's a _variety_ of machines...I mean,
that's also a principle of the internet's design too...designed to survive
an all-out nuclear assault for as long as possible was the main design
criteria of the internet which brought about its "total decentralisation" -
absolutely no "centre" to it at all (well, no, not completely
true...security experts, indeed, point out that DNS servers are a "weak
link"...not that bringing down DNS servers would bring down the internet
but it would remove the "convenince" of "www." names and unless you note
down the IP addresses, it's "as good as" dead for you...the problem that
DNS was added on _AFTER_ the original DoD design and wasn't framed in the
same "total decentralised" design principle :)...or, you can look at the
way Napster and other peer-to-peer (total decentralised design too) file
sharing can't actually really be stopped physically but, instead, they try
to sue the "servers" or grab the individual downloaders...try to scare some
"compliance", realising that there's no physical way they can do
it...sueing people scares them but it doesn't shut down the "network" for
the fearless who don't really care at all...

And the point is that "democracy" is also a _decentralised_ model (okay, in
practice, there's no "true democracy" and we have "representatives" and
such for practical purposes...we can't spend all day long just voting on
every minute detail...a referendum on every detail of the budget, a
referendum on when to hold the other referendums, etc....the practical
problem with that idea is simply that we'd all be spending our entire lives
in "referendums" on everything and have no time for the rest of life...and
how does one deal with "national security" in such a setting? A ballot
*** where the names are blacked out so you don't know what you're voting
for? Either that or publicly revealing all security details to all
terrorists whilst trying to explain it all to the electorate? Again, it's
all to do with practicalities, really :)...while "dictatorship" has no
"biodiversity"...

And, simply, what this means is that "democracy" is a more _ROBUST_
model...if "dictator" Rene is wrong, the errors go uncorrected while he
refuses to believe there's a problem...if Rene walks, the whole thing
collapses because it depends solely on Rene as a "lynchpin" to
everything...on the other hand, though, yes, this "democracy" is _messy_
and ends up in lots of "fights" and things from time to time, the point is
that there's no "dictator" and there's "biodiversity"...if C is wrong then
I Hopefully can pick up on that...if I'm wrong then I can depend on C to
pick up on that...when we're both wrong, Frank steps in to separate the
warring "children" :)...

And here's the other point...if I did walk, then LuxAsm continues with
Frank and C, no problem...if C walked - it would be a big loss - but the
project could continue...other people could take up the reigns and carry it
on...this is not "theory" either because NASM no longer has its original
authors involved but the development still continues...granted, with
LuxAsm, we're still small and at the beginning that a loss would be a big
deal...but this "democracy" is more robust...it's not the end of the
project itself unless everyone walks away and no-one else joins on...

On the contrary, the "fights" are a _HEALTHY_ sign...a demonstration that
mistakes and misunderstandings are _worked out_...that everyone can have a
"voice" in what's going on...that the "democracy" is working...

> It appears to me, as an uninvolved outsider, that it's all Beth's fault.

You may be "uninvolved" but you're hardly "unbiased"...

> She obviously needs to:
>
> 1. Stop taking things personally.

When such as you, Annie, stop waging personal wars against me, then I'll
gladly enjoy the luxury of not having to take such things personally...

> 2. Always comment ALL her code and code changes.

Correct; But so does everyone else...C is as guilty of not doing this as
me...

> 3. Clearly and CONCISELY communicate her ideas and concepts
> beforehand...remembering that if an explanation takes more
> than 25 words, it's too long and convoluted.

Actually, communicating ideas concepts _BEFOREHAND_ is exactly what I've
been doing and trying to encourage C to also do sometimes...

> 4. Temporarily excuse herself from the project during certain
> phases of the lunar cycle. Hehehe!

Probably...

Beth :)