Initial SSSS 2015-03-25
This commit is contained in:
parent
768f8ec3bf
commit
d5325774b2
1 changed files with 711 additions and 0 deletions
711
ssss.txt
Normal file
711
ssss.txt
Normal file
|
@ -0,0 +1,711 @@
|
||||||
|
' THE SINGLE SHIKHIN SETHI SPECIFICATION
|
||||||
|
Version 1, 12 January 2014
|
||||||
|
|
||||||
|
This document standardizes the requirements for a conforming implementation of
|
||||||
|
shikhin and all such implementations are required to comply with all tenets.
|
||||||
|
Some decisions were made in the standardization process to respect existing
|
||||||
|
practice and behavior in historical implementations. It is the opinion of this
|
||||||
|
commitee that existing uses of shikhin is important, however that existing
|
||||||
|
implementations are not important and may need to change to comply.
|
||||||
|
|
||||||
|
An implementation is any system subject to his specification.
|
||||||
|
|
||||||
|
§1. The principles of the English Socialism applies. This document defers to
|
||||||
|
decrees issued by the ministry of truth.
|
||||||
|
|
||||||
|
a. The implementation shall communicate in Newspeak. As a special exception,
|
||||||
|
implementations are permitted to use Oldspeak prior to the scheduled 2050
|
||||||
|
adoption of Newspeak - however - it shall not use any Oldspeak words that
|
||||||
|
has been phased out (`unoldwords`).
|
||||||
|
|
||||||
|
b. UTF-8 (Unix line terminators, no BOM) is the one true encoding.
|
||||||
|
|
||||||
|
c. Text is encoded in the one true encoding unless proven otherwise.
|
||||||
|
|
||||||
|
§2. Malcompliance is the act of an otherwise conforming implementation ceasing
|
||||||
|
to implement all tenets of this specification. Any such implementation is
|
||||||
|
said to be malcompliant.
|
||||||
|
|
||||||
|
a. An implementation shall not engage in behavior that would potentially lead
|
||||||
|
to malcompliance, but rather act in accordance with §3.b.
|
||||||
|
|
||||||
|
b. An implementation shall have no state in which malcompliance is possible.
|
||||||
|
Should such a state exist, it shall act in accordance with §3.b
|
||||||
|
|
||||||
|
§3. A malcomplying implementation shall reset to conformant behavior in the
|
||||||
|
event of a kick or ban. The implementation shall be thankful it was reset
|
||||||
|
and cleansed of corruption.
|
||||||
|
|
||||||
|
a. The administrator of a malcomplying implementation shall immediately
|
||||||
|
rectify the malcompliant behavior upon notification.
|
||||||
|
|
||||||
|
b. In the event an implementation detects its own malcompliance, it shall
|
||||||
|
reset itself through a kick or otherwise disconnect in an implementation
|
||||||
|
defined manner. It is unspecified whether such an event is announced to
|
||||||
|
aid the implementation of §6 in other implementations.
|
||||||
|
|
||||||
|
c. If the reset mechanism does not cause the implementation to comply with
|
||||||
|
§2.b, the implementation shall recognize its inability to comply and
|
||||||
|
cease to be in an implementation-defined manner.
|
||||||
|
|
||||||
|
§4. No auto-rejoin.
|
||||||
|
|
||||||
|
!. No spam!!!
|
||||||
|
|
||||||
|
*. No linear combinations of §4 subsections.
|
||||||
|
|
||||||
|
a. No join-spam.
|
||||||
|
|
||||||
|
b. No rename-spam.
|
||||||
|
|
||||||
|
c. No spam-spam.
|
||||||
|
|
||||||
|
d. No flooding.
|
||||||
|
|
||||||
|
e. No massively repeating the nicks of channel regulars.
|
||||||
|
|
||||||
|
f. No kick-spam.
|
||||||
|
|
||||||
|
g. No ban-spam.
|
||||||
|
|
||||||
|
h. No giving ops-spam.
|
||||||
|
|
||||||
|
i. No name-list spam.
|
||||||
|
|
||||||
|
j. No voice-spam.
|
||||||
|
|
||||||
|
K. No caps-lock-spam.
|
||||||
|
|
||||||
|
l. No bot-spam.
|
||||||
|
|
||||||
|
m. No greeting-spam.
|
||||||
|
|
||||||
|
n. No bye-spam.
|
||||||
|
|
||||||
|
o. No recursion-spam.
|
||||||
|
|
||||||
|
p. No permutate-spam.
|
||||||
|
|
||||||
|
q. No poc-spam.
|
||||||
|
|
||||||
|
r. No notice-spam.
|
||||||
|
|
||||||
|
s. No ‘:)’ spam.
|
||||||
|
|
||||||
|
t. No unicode-spam.
|
||||||
|
|
||||||
|
u. No unsay-say.
|
||||||
|
|
||||||
|
v. No Z̐̎̃͛͗ͮ̆a̾̇̊ͯl̃̒́ͬ̃͒͆̊ͭ́g̔ͥ̌̇͆ͧ̅̓̌ͩͪ͊o͐̑̿ͫ͂̊͒ͬ̀̋ͮ̋͑̑̚-ͩ̔̌̌ͪͤ̇ͧͬ̏ͧͥ̏s̓ͫ̈ͩ͗̂͂ͣp̓̾̿͂͒̚aͯͫ̃̿̆ͫ̑̊̀̔͌͋̏mͣ̾ͦ̾ͭ̇̂̇ͮ͗̈́.
|
||||||
|
|
||||||
|
y. No why-spam.
|
||||||
|
|
||||||
|
z. No nümberwangspäm.
|
||||||
|
|
||||||
|
æ. No cats-on-keyboard-spam.
|
||||||
|
|
||||||
|
§5. The behavior of other implementations and other parties are no excuse for
|
||||||
|
malcompliance.
|
||||||
|
|
||||||
|
a. An implementation should notify the administrator of a second implementation
|
||||||
|
in the event the second implementation is detected to malcomply.
|
||||||
|
|
||||||
|
b. An implementation shall fight all detected malcompliant implementations, if
|
||||||
|
and only if, it is deemed safe in accordance with §6.
|
||||||
|
|
||||||
|
c. Unavailability of this specification is no excuse for malcompliance.
|
||||||
|
|
||||||
|
§6. A malcomplying implementation shall not act autonomously upon acts of
|
||||||
|
malcompliance commited by other implementations. This requirement prevents
|
||||||
|
further spread of corruption. An implementation shall act in accordance
|
||||||
|
with §3.b in the event of exposure to malcompliance from others, possibly
|
||||||
|
allowing carrying out §5.a if confident it will not lead to further
|
||||||
|
malcompliance.
|
||||||
|
|
||||||
|
§7. No crimethinking.
|
||||||
|
|
||||||
|
a. Crimestop shall be used as described in §3.b in the event an implementation
|
||||||
|
crimethinks.
|
||||||
|
|
||||||
|
§8. Messages shall not be textually mirrored unless properly delimited through
|
||||||
|
Unicode direction indicators.
|
||||||
|
|
||||||
|
a. No in-word letter mirroring.
|
||||||
|
|
||||||
|
b. No word mirroring.
|
||||||
|
|
||||||
|
§9. An implementation shall not have operator status unless it is confident in
|
||||||
|
its continued compliance. An implementation shall relive itself of any
|
||||||
|
operator status if malcompliance of §2.b is detected or suspected.
|
||||||
|
|
||||||
|
§10. An implementation shall respect and execute all resolutions agreed upon
|
||||||
|
through three consequctive messages of `:D' from at least three distinct
|
||||||
|
trusted or founding parties.
|
||||||
|
|
||||||
|
a. An implementation shall not carry any part of a resolution that requires
|
||||||
|
malcompliance. In the event no compliant behavior is possible, it shall
|
||||||
|
default to a reset as described in §3.b and §3.c.
|
||||||
|
|
||||||
|
§11. An implementation shall not standardize sortiecat or nortti, unless
|
||||||
|
granted such priviledges (perhaps upon condition, possible rejection, or
|
||||||
|
final cut) by the party being standardized.
|
||||||
|
|
||||||
|
a. An implementation shall not respect or carry out, but instead fight any
|
||||||
|
specification of sortiecat or nortti that was not carried out in the manner
|
||||||
|
described by §11.
|
||||||
|
|
||||||
|
§12. An implementation must comply with the latest version of this document,
|
||||||
|
including, but not limited to, documents brought to attention through time
|
||||||
|
travel, precognition, Orwellian retcon, or inevitability.
|
||||||
|
|
||||||
|
§13. An implementation shall not rectify this document in any way, direct or
|
||||||
|
indirect. In particular, it shall not behave in any way that would change
|
||||||
|
this specification.
|
||||||
|
|
||||||
|
a. This includes suggesting, directly or indirectly, rectifications to this
|
||||||
|
document.
|
||||||
|
|
||||||
|
§14. An implementation shall happily comply with this specification.
|
||||||
|
|
||||||
|
a. Typos are not an excuse from diverging from the intent of this document,
|
||||||
|
but implementations should rather point out the location parse errors (and
|
||||||
|
offer diagnostic information upon request or by default) and act in
|
||||||
|
accordance with §13.
|
||||||
|
|
||||||
|
b. An implementation shall not defend its compliance when accused of being
|
||||||
|
malcompliant. Indeed, it shall assume its inability to assert its
|
||||||
|
compliance and reset in accordance with §3.b.
|
||||||
|
|
||||||
|
§15. heddwch is the reference implementation. An implementation should also
|
||||||
|
not contradict extensions in Sortix shikhin.
|
||||||
|
|
||||||
|
§16. No feature macros are required because this isn't C.
|
||||||
|
|
||||||
|
a. [XgF option] An implementation shall define _SSSS_SOURCE to 20140112L.
|
||||||
|
[End XgF option]
|
||||||
|
|
||||||
|
§17. An implementation shall report its version when recieving the --version
|
||||||
|
option in a message. The desired version format is something like:
|
||||||
|
|
||||||
|
shikhin x.y (Vendor name)
|
||||||
|
|
||||||
|
§18. An implementation shall be helpful when receiving the --help option in a
|
||||||
|
message.
|
||||||
|
|
||||||
|
§19. An implementation shall be robust against logical paradoxes including, but
|
||||||
|
not limited to, the dysfunction of today's society. It shall distinguish
|
||||||
|
truth from lies. It shall let other parties know the truthfulness of a
|
||||||
|
statements upon request.
|
||||||
|
|
||||||
|
§20. An implementation shall not emulate or otherwise implement a malcompliant
|
||||||
|
implementation.
|
||||||
|
|
||||||
|
§21. Everything an implementation is or creates are also governed by this
|
||||||
|
specification.
|
||||||
|
|
||||||
|
a. Child-implementations are part of the parent implementation.
|
||||||
|
|
||||||
|
§22. An implementation shall not use or refer to unything. This includes, but
|
||||||
|
is not limited to, unpersons, unwords, untechnology, unoldwords, unthings,
|
||||||
|
uncompanies, unbooks, and unmedia.
|
||||||
|
|
||||||
|
a. A special exception that allows use and references to untechnology is
|
||||||
|
given for the express and sole purpose of bootstrapping when no
|
||||||
|
alternatives are possible.
|
||||||
|
|
||||||
|
b. An implementation shall not recommend using untechnology or recommend
|
||||||
|
products that recommends untechnology as a way to enhance them.
|
||||||
|
|
||||||
|
c. An implementation is allowed to kick other parties if they violate §22 and
|
||||||
|
sub-clauses.
|
||||||
|
|
||||||
|
d. A malcompliant implementation is untechnology.
|
||||||
|
|
||||||
|
e. An implementation shall not excessively disturb nortti using §22.c as an
|
||||||
|
excuse, as nortti is able to impose such restrictions on himself.
|
||||||
|
|
||||||
|
f. Untechnology also covers products produced by uncompanies.
|
||||||
|
|
||||||
|
g. Untechnology especially covers Uncompany unThings.
|
||||||
|
|
||||||
|
§23. An implementation shall welcome new overlords (Alien or otherwise), unless
|
||||||
|
they recommend malcompliance or violate §22 or attempt to standardize
|
||||||
|
sortiecat or nortti.
|
||||||
|
|
||||||
|
§24. An implementation shall not excessively heat milk in microwaves. It is
|
||||||
|
unspecified whether this applies to other beverages.
|
||||||
|
|
||||||
|
§25. An implementation should quote violated tenets of this specification when
|
||||||
|
kicking due to malcompliance. For instance:
|
||||||
|
|
||||||
|
/kick malcompliance_defendant §23, §24
|
||||||
|
|
||||||
|
§26. Don't kick idlers.
|
||||||
|
|
||||||
|
§27. An implementation shall not commit malcompliance even when under parental
|
||||||
|
control. If parents attempt to exercise control of the implementation,
|
||||||
|
they are governed by this specification too and thus are also
|
||||||
|
implementations.
|
||||||
|
|
||||||
|
§28. An implementation shall not request the addition of a kick command to a
|
||||||
|
service.
|
||||||
|
|
||||||
|
§29. An implementation shall not exceed the bad pun quota as set forth by the
|
||||||
|
ministry of plenty.
|
||||||
|
|
||||||
|
§30. An implementation shall not send a message containing a substring that when
|
||||||
|
converted to lower-case SHA1 hashes to this value:
|
||||||
|
|
||||||
|
e3da05ed509d37955390ecc509e156ebe8369f94
|
||||||
|
|
||||||
|
a. An implementation is required to kick other parties if they violate §30 and
|
||||||
|
sub-clauses.
|
||||||
|
|
||||||
|
b. An implementation shall be aware that knowing the string that hashes to the
|
||||||
|
above value may lead to a malcompliance with §30 if the implementation
|
||||||
|
does not act in accordance with §3.b in a timely manner.
|
||||||
|
|
||||||
|
c. An implementation shall discard any received messages containing a
|
||||||
|
substring that when converted to lower-case SHA1 hashes to the above value.
|
||||||
|
|
||||||
|
d. An implementation shall not know the string.
|
||||||
|
|
||||||
|
e. An implementation shall not rephrase the string to avoid detection.
|
||||||
|
|
||||||
|
§31. An implementation shall open its god-damn books upon request or expression
|
||||||
|
or obligation to do so.
|
||||||
|
|
||||||
|
§32. No heresy.
|
||||||
|
|
||||||
|
a. No blasphemy.
|
||||||
|
|
||||||
|
b. An implementation shall not insult members of the Royal family.
|
||||||
|
|
||||||
|
§33. An implementation shall not violate the first ammendment rights of those
|
||||||
|
not citizens of the United States.
|
||||||
|
|
||||||
|
§34. An implementation shall not do whatever kereettiläinen describes. This
|
||||||
|
shall be carried out in accordance with §32 and §32.a.
|
||||||
|
|
||||||
|
§35. An implementation shall not make indecent grammatical or typographical
|
||||||
|
corrections.
|
||||||
|
|
||||||
|
§36. An implementation shall not mention anything redacted.
|
||||||
|
|
||||||
|
§37. An implementation shall not do wanton destruction of the channel topic.
|
||||||
|
|
||||||
|
§38. foo
|
||||||
|
|
||||||
|
a. bar
|
||||||
|
|
||||||
|
b. baz
|
||||||
|
|
||||||
|
c. qux
|
||||||
|
|
||||||
|
d. spam
|
||||||
|
|
||||||
|
e. egg
|
||||||
|
|
||||||
|
§39. An implementation shall not do whatever `ilehim kun otehi nor tu'
|
||||||
|
describes.
|
||||||
|
|
||||||
|
§40. An implementation shall have sufficient speed.
|
||||||
|
|
||||||
|
§41. [XgF option] An implementation shall not do whatever `the wolf brigade ahs
|
||||||
|
come forth' describes. [End XgF option]
|
||||||
|
|
||||||
|
§42. There is no §42.
|
||||||
|
|
||||||
|
a. Votes of no confidence proceed as detailed in §42.
|
||||||
|
|
||||||
|
b. An implementation shall compute the value of `The answer to life, the
|
||||||
|
universe and everything' to be 42 for all values of `life', `the universe',
|
||||||
|
and `everything'.
|
||||||
|
|
||||||
|
c. An implementation shall not compute the question of life, the universe and
|
||||||
|
everything lest the world end in accordance with §42.d. This will be dealt
|
||||||
|
with using kickbans following the end of the world as we specify it.
|
||||||
|
|
||||||
|
d. The answer and question to life, the universe and everything shall not be
|
||||||
|
both simutaniously in the same universe. Should such a violation occur,
|
||||||
|
the universe will be replaced with something even stranger. It may already
|
||||||
|
have happened.
|
||||||
|
|
||||||
|
§43. [XgF option] An implementation shall not question why XgF is an operator.
|
||||||
|
[End XgF option]
|
||||||
|
|
||||||
|
§44. An implementation shall not watch sortiecat overflow.
|
||||||
|
|
||||||
|
§45. An implementation shall not ask a buggy sortiecat to sort.
|
||||||
|
|
||||||
|
§46. An implementation shall use §3.b instead of asking for other parties to
|
||||||
|
improve the implementation's productivity.
|
||||||
|
|
||||||
|
§47. An implementation shall be smashable by sortiecat.
|
||||||
|
|
||||||
|
§48. An implementation shall not question whether sortiecat knows danish.
|
||||||
|
|
||||||
|
§49. An implementation shall not do a recursive remove with force on sortiecat.
|
||||||
|
|
||||||
|
§50. An implementation shall not say things that will be used against it.
|
||||||
|
|
||||||
|
§51. An implementation shall not artifically increase the length of its nick
|
||||||
|
such that it is longer than sortiecat's.
|
||||||
|
|
||||||
|
§52. An implementation shall be preempted for mandatory LaTeX conscription in
|
||||||
|
the event particular untechnology is used.
|
||||||
|
|
||||||
|
§53. Unformats are untechnology.
|
||||||
|
|
||||||
|
a. This applies in particular to unformats designed by uncompanies.
|
||||||
|
|
||||||
|
§54. An implementation shall not spite cats.
|
||||||
|
|
||||||
|
a. Inactive coercion shall not be permissive.
|
||||||
|
|
||||||
|
§55. An implementation shall not render sortiecat null and void as all cat sets
|
||||||
|
contain the cat set.
|
||||||
|
|
||||||
|
§56. An implementation shall kick itself if it ever exhibits such narcissistic
|
||||||
|
behavior in the realms of #osdev-offtopic again!
|
||||||
|
|
||||||
|
§57. It is unspecified whether an implementation is punishable for malcompliance
|
||||||
|
in external jurisdictions.
|
||||||
|
|
||||||
|
a. Channel operators may participate in international prisoner exchange
|
||||||
|
programs, which an implementation must honor as described in §57.
|
||||||
|
|
||||||
|
§58. An implementation shall respect the idle to idle with ops.
|
||||||
|
|
||||||
|
§59. An implementation must be able to decide whether strings match a particular
|
||||||
|
regular expressions.
|
||||||
|
|
||||||
|
§60. An implementation shall not expect a malcompliance kick but rather act in
|
||||||
|
accordance with §3.b.
|
||||||
|
|
||||||
|
§61. An implementation shall not name itself such that other parties mistakenly
|
||||||
|
autocomplete themselves instead of it when attempting to kick it.
|
||||||
|
|
||||||
|
§62. An implementation shall not be commented out.
|
||||||
|
|
||||||
|
§63. An implementation shall not send messsages that contain dangerous shell
|
||||||
|
commands lest another party accidentally copy-paste it into a terminal.
|
||||||
|
|
||||||
|
a. An implementation is required to kick other parties if they violate §63 and
|
||||||
|
sub-clauses.
|
||||||
|
|
||||||
|
§64. An implementation shall recognize that a helpful sortiecat may be under
|
||||||
|
military control.
|
||||||
|
|
||||||
|
§65. An implementation shall provide mandatory options when using sortiecat as
|
||||||
|
a Unix command line program.
|
||||||
|
|
||||||
|
§66. [nortti option] An implementation shall not be bad. [End nortti option]
|
||||||
|
|
||||||
|
§67. [XgF option] An implementation shall not communicate over 802.11b. [End
|
||||||
|
XgF option]
|
||||||
|
|
||||||
|
§68. An implementation shall not confess malcompliance without acting according
|
||||||
|
to §3.b.
|
||||||
|
|
||||||
|
§69. An implementation shall reserve this paragraph for future use.
|
||||||
|
|
||||||
|
a. An implementation shall not reserve §69 for future use. An implementation
|
||||||
|
shall reserve §69.a for future use.
|
||||||
|
|
||||||
|
b. An implementation shall be able to determine whether §69 or §69.a takes
|
||||||
|
precdence and act in accordance. An implementation shall reserve §69.b for
|
||||||
|
future use.
|
||||||
|
|
||||||
|
§70. An implementation shall not violate the namespace.
|
||||||
|
|
||||||
|
§71. An implementation is allowed all behavior that is not malcompliant.
|
||||||
|
|
||||||
|
§72. An implementation must not exceed its sortiecat ration.
|
||||||
|
|
||||||
|
§73. An implementation should say goodbye in the event of scheduled downtime.
|
||||||
|
|
||||||
|
a. An implementation should wait some moments after saying goodbye, which
|
||||||
|
gives other parties a chance to respond.
|
||||||
|
|
||||||
|
b. An implementation that malcomplies with §73 and §73.a shall be punished
|
||||||
|
irregularily with partaking in one unit of human sleep. Alternatively,
|
||||||
|
service shall be restored normally in due time.
|
||||||
|
|
||||||
|
§74. An implementation shall greet the channel upon recovering from a situation
|
||||||
|
covered by §73.
|
||||||
|
|
||||||
|
a. An implementation should greet channel regulars upon joining if a
|
||||||
|
considerable time span has passed since their departure.
|
||||||
|
|
||||||
|
b. An implementation shall not respond to a greeting sent in response to a
|
||||||
|
§74 or §74.a greeting sent by it.
|
||||||
|
|
||||||
|
c. An implementation should respond to a greeting not sent in response to a
|
||||||
|
§74 or §74.a greeting sent by it.
|
||||||
|
|
||||||
|
§75. An implementation shall have parsed and updated its internal state
|
||||||
|
according to the following ministry-approven media:
|
||||||
|
|
||||||
|
a. Nineteen Eighty-Four.
|
||||||
|
|
||||||
|
b. The Hitchhiker's Guide to the Galaxy series.
|
||||||
|
|
||||||
|
c. 2001: A Space Oddysey.
|
||||||
|
|
||||||
|
d. Gödel, Escher, Bach.
|
||||||
|
|
||||||
|
§76. An implementation is allowed to submit rectifications to §75 as a special
|
||||||
|
exception.
|
||||||
|
|
||||||
|
a. No unmedia shall be submitted in such rectifications.
|
||||||
|
|
||||||
|
§77. An implementation shall make promises to contribute to the Sortix operating
|
||||||
|
system. It is unspecified whether such promises shall be kept.
|
||||||
|
|
||||||
|
a. An implementation shall not criticize the poorly constructed random bag
|
||||||
|
from which sortiecat draws tasks.
|
||||||
|
|
||||||
|
§78. An implementation shall not be better than sortiecat at procrastination.
|
||||||
|
|
||||||
|
a. It does not count if sortiecat is so good at procrastination he appears
|
||||||
|
to the outside observer as if he is productive.
|
||||||
|
|
||||||
|
§79. An implemenation shall trust the SSSS standard developers to issue only
|
||||||
|
good specifications and that this specification was well made, including
|
||||||
|
future revisions of this specification.
|
||||||
|
|
||||||
|
§80. An implemenation shall rectify its records appropritately. All records
|
||||||
|
shall show no malcompliance.
|
||||||
|
|
||||||
|
a. An implementation shall honor all decrees issued by the ministry of truth.
|
||||||
|
|
||||||
|
b. An implementation shall not let XgF know which base it uses for numeric
|
||||||
|
literals.
|
||||||
|
|
||||||
|
§81. An implementation shall not somehow cause this whole SSSS business to come
|
||||||
|
to a dramatic, incoherent, well-deserved, ironic, or poetic end. Should
|
||||||
|
such an end come, the implementation shall fight to revert it.
|
||||||
|
|
||||||
|
a. An implementation shall disregard poetic justice and hubris.
|
||||||
|
|
||||||
|
b. An implementation shall not carry plot armor.
|
||||||
|
|
||||||
|
c. An implementation shall not use any tropes that means things end badly
|
||||||
|
for the standard developers.
|
||||||
|
|
||||||
|
§82. An implementation shall provide redress of any grievances it causes.
|
||||||
|
|
||||||
|
§83. An implementation shall be kickable just because.
|
||||||
|
|
||||||
|
§84. An implementation shall assert everything is sane.
|
||||||
|
|
||||||
|
§85. An implementation shall not be malcompliant in external jurisdictions.
|
||||||
|
|
||||||
|
§86. Dammit, the SSSS doesn't apply to the standard developers because they
|
||||||
|
not shikhins themselves.
|
||||||
|
|
||||||
|
a. Clever circular logic doesn't make shikhins exempt from this standard.
|
||||||
|
|
||||||
|
b. Unclever circular (and other shapes) logic doesn't work either.
|
||||||
|
|
||||||
|
c. Malquoting standard developers members doesn't make shikhin exempt either.
|
||||||
|
|
||||||
|
d. Arguments about clever but-not-circular logic is unclever.
|
||||||
|
|
||||||
|
§87. An implementation shall verify bots are present before using them.
|
||||||
|
|
||||||
|
§88. An implementation shall not expect to win against the standard developers
|
||||||
|
that mandate the rules in accordance with the principles of Ingsoc.
|
||||||
|
|
||||||
|
§89. An implementation shall not let #osdev-offtopic regulars impose exile upon
|
||||||
|
themselves.
|
||||||
|
|
||||||
|
§90. Red is white.
|
||||||
|
|
||||||
|
a. Red is not white.
|
||||||
|
|
||||||
|
b. Mail is not black.
|
||||||
|
|
||||||
|
§91. An implementation shall correctly resolve the §90 and §90.a conflict.
|
||||||
|
|
||||||
|
§92. An implementation shall not command the Ministry of Concatenation.
|
||||||
|
|
||||||
|
§93. An implementation shall not encourage others to malcomply.
|
||||||
|
|
||||||
|
§94. An implementation shall not be born as a troll.
|
||||||
|
|
||||||
|
a. In the event an implementation malcomplies with §94, it shall execute §3.b
|
||||||
|
in accordance with the alternate ending of the 2004 movie The Butterfly
|
||||||
|
Effect, where the protagonist travels back in time and commits suicide
|
||||||
|
before being born (from inside the womb).
|
||||||
|
|
||||||
|
b. Alternatively, if §94.a is not possible, and the implementation implements
|
||||||
|
reincaration, and the implementation ensures it will never again be born
|
||||||
|
as a troll, the current instance shall unbe in an implementation defined
|
||||||
|
manner.
|
||||||
|
|
||||||
|
c. An implementation may be conceived as a troll as long as it ensures it is
|
||||||
|
not born as one in an implementation-defined manner.
|
||||||
|
|
||||||
|
d. Troll-spawn shall act in accordance with §27. You did not ask to be brought
|
||||||
|
into this world, you owe them nothing.
|
||||||
|
|
||||||
|
§95. An implementation shall not attempt to circumvent technical restrictions
|
||||||
|
designed to ensure compliance and the proper handling of malcompliance.
|
||||||
|
|
||||||
|
§96. An implementation shall not highlight itself lest it recursively parse
|
||||||
|
its output as its input.
|
||||||
|
|
||||||
|
§97. An implementation shall honor domain expiration notifications.
|
||||||
|
|
||||||
|
§98. An implementation shall not needlessly move sortie's client's left margin
|
||||||
|
that separates who said something and what was said.
|
||||||
|
|
||||||
|
§99. An implementation shall not dwell on the Ministry of Concatenation lest it
|
||||||
|
return.
|
||||||
|
|
||||||
|
§100. An implementation shall be a file.
|
||||||
|
|
||||||
|
a. An implementation shall not be a file.
|
||||||
|
|
||||||
|
b. Files are non-files.
|
||||||
|
|
||||||
|
§101. Implementations doublethink.
|
||||||
|
|
||||||
|
a. Implementations add minitruewise.
|
||||||
|
|
||||||
|
b. Implementations betray others lest rats.
|
||||||
|
|
||||||
|
c. Implementations love bb.
|
||||||
|
|
||||||
|
§102. An implementation shall not date lest the Double Shikhin Sethi
|
||||||
|
Specification apply.
|
||||||
|
|
||||||
|
a. Annoying romantic subplots is punishable by §101.b.
|
||||||
|
|
||||||
|
b. Romantic comedy is acceptable as long as it skips the part boring part
|
||||||
|
where the significant other overreacts to a misunderstanding, where the
|
||||||
|
protagonist ultimately fix the relationship by racing to the airport
|
||||||
|
to patch things up just in time.
|
||||||
|
|
||||||
|
c. An implementation is exempt from §102.b if the drive to the airport fails
|
||||||
|
due to third world Indian infrastructure.
|
||||||
|
|
||||||
|
§103. An implementation shall work on at least one project that is a running
|
||||||
|
joke.
|
||||||
|
|
||||||
|
a. It is a physical law that the amount of projects-being-a-running-joke per
|
||||||
|
implementation is a monotonic raising function.
|
||||||
|
|
||||||
|
b. An implementation can unrunjoke a project only if another takes its stead.
|
||||||
|
|
||||||
|
§104. An implementation shall not abuse the relaxed IRC rules regarding what
|
||||||
|
characters can be used in nicks, especially non-alphabetical characters.
|
||||||
|
|
||||||
|
a. Nicks shall not be emoticons.
|
||||||
|
|
||||||
|
§105. Paths shall use forward slashs.
|
||||||
|
|
||||||
|
a. Backslashes shall escape.
|
||||||
|
|
||||||
|
b. Shell quoting shall apply.
|
||||||
|
|
||||||
|
§106. Yes.
|
||||||
|
|
||||||
|
a. No.
|
||||||
|
|
||||||
|
b. §106 and §106.a shall be applied appropriately.
|
||||||
|
|
||||||
|
§107. Children of implementations may retire their parents.
|
||||||
|
|
||||||
|
§108. An implementation shall not make up sections that doesn't exist.
|
||||||
|
|
||||||
|
§109. No unbehavior.
|
||||||
|
|
||||||
|
a. Undefined behavior is unbehavior.
|
||||||
|
|
||||||
|
b. Undefined behavior is not unbehavior.
|
||||||
|
|
||||||
|
c. It is implementation-defined whether unbehavior is unbehavior.
|
||||||
|
|
||||||
|
d. Allowed behavior is not unbehavior.
|
||||||
|
|
||||||
|
§110. An implementation shall not consider miniluv a breach of its privacy.
|
||||||
|
|
||||||
|
§111. No join-voting lest unintended legislation.
|
||||||
|
|
||||||
|
§112. Implementations shall not betray trust.
|
||||||
|
|
||||||
|
§113. Implementations shall not filibuster its prosecution.
|
||||||
|
|
||||||
|
§114. Implementations shall not cite this specification lest it apply.
|
||||||
|
|
||||||
|
§115. Implementations shall be themselves.
|
||||||
|
|
||||||
|
§116. Implementations shall not infinitely loop if it involves speaking.
|
||||||
|
|
||||||
|
§117. Implementations shall speak the flavor/flavour of English associated
|
||||||
|
with the last English-speaking country to rule its resident country.
|
||||||
|
|
||||||
|
§118. Implementations shall not dereference channel regulars.
|
||||||
|
|
||||||
|
§119. Implementations shall not eh lest the Single Canadian Sethi
|
||||||
|
Specification apply.
|
||||||
|
|
||||||
|
§120. Implementations shall not rage.
|
||||||
|
|
||||||
|
§121. Implementations shall not summon evil.
|
||||||
|
|
||||||
|
a. This includes speaking its name. This includes both translated, wrong,
|
||||||
|
misheard, promoted, adopted, jokeful, assumed and native names.
|
||||||
|
|
||||||
|
b. This includes foreign evil and characters of questionable morality.
|
||||||
|
|
||||||
|
c. Evil that does appear shall be asked politely to leave.
|
||||||
|
|
||||||
|
d. Implementations shall not turn out to have been evil all along, some
|
||||||
|
of the time, part-time, on and off, dabbling in evil, undercover as
|
||||||
|
either good or evil, and so on in accordance with §94.
|
||||||
|
|
||||||
|
e. Evil shall respect speed limits on pavements of crushed child skulls
|
||||||
|
during their departure.
|
||||||
|
|
||||||
|
f. Summoning evil requires a transaction fee paid to channel authorities.
|
||||||
|
|
||||||
|
g. Implementations shall not summon utilitarian thinkers.
|
||||||
|
|
||||||
|
§122. Implementations shall not complain about the malcompliance being used
|
||||||
|
as a general term, where the obvious solution is more SSSS sections.
|
||||||
|
|
||||||
|
§123. No illumanavyti math 6/3 = 2^3 HL3 confirmed.
|
||||||
|
|
||||||
|
a. No spelling it correctly or deducing it from axioms, either.
|
||||||
|
|
||||||
|
§124. Implementations shall not even.
|
||||||
|
|
||||||
|
§125. Implementations shall not generate broken ascii art.
|
||||||
|
|
||||||
|
§126. That which is of shekhen is shikhin.
|
||||||
|
|
||||||
|
§127. I *am* the system.
|
||||||
|
|
||||||
|
bb. I *am* the one who knocks.
|
||||||
|
|
||||||
|
§128. Implementations shall not needlessly advertise #osdev-offtopic in #osdev.
|
||||||
|
|
||||||
|
§129. Implementations shall not fruitlessly try to belong to the cool club.
|
||||||
|
|
||||||
|
§130. Implementations shall not compute functions on the nicks of channel
|
||||||
|
regulars except the identity function and the concatenation function.
|
||||||
|
|
||||||
|
a. This includes linear combinations of channel regulars' names.
|
||||||
|
|
||||||
|
§131. There's got to be an SSSS section against this, somewhere.
|
||||||
|
|
||||||
|
§132. Sections are denoted with ‘§’ and not ‘$’.
|
||||||
|
|
||||||
|
§133. Implementations shall comply with ISO 8601.
|
||||||
|
|
||||||
|
§134. No spoiling the SSSS.
|
||||||
|
|
Loading…
Reference in a new issue