Initial SSSS 2015-03-25
This commit is contained in:
parent
768f8ec3bf
commit
d5325774b2
|
@ -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 New Issue