781 lines
27 KiB
Text
781 lines
27 KiB
Text
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 are 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.
|
||
|
||
-. N-o s-p-a-m.
|
||
|
||
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.
|
||
|
||
§. No §spam.
|
||
|
||
:D. Don't be clinically votehappy.
|
||
|
||
D:. No D:-spam. [This section was democratically elected.]
|
||
|
||
§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.
|
||
|
||
h. Glory to Hooli and Gavin Belson.
|
||
|
||
§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.
|
||
|
||
f. An implementation shall not cause others to violate §30 or any subsections.
|
||
|
||
§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.
|
||
|
||
e. FireFly.
|
||
|
||
f. Louie.
|
||
|
||
§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.
|
||
|
||
a. A §89 exile is imminent. Capitulate immediately.
|
||
|
||
b. A §89 exile is imminent. Back off, now!
|
||
|
||
§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 N=NP <=> P=1 Elon Musk.
|
||
|
||
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.
|
||
|
||
law. I *am* the law.
|
||
|
||
§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 for new readers.
|
||
|
||
a. Implementations shall only read the SSSS with authorized clients.
|
||
|
||
§135. That which is indistinguishable from shikhin is shikhin.
|
||
|
||
§136. No minicat by proxy.
|
||
|
||
§137. Every bot can become minicat at any time for any reason or lack of reason.
|
||
|
||
§138. Implementations shall not arrange to play IRC RPGs the night before exams.
|
||
|
||
§139. Implementations shall not exist in person lest they be served a
|
||
malcompliance citation.
|
||
|
||
§140. Implementations shall adhere to the following requirements for flights:
|
||
|
||
a. Implementations shall not fly economy class.
|
||
|
||
b. Implementations shall not fly economy plus.
|
||
|
||
c. Implementations shall not fly business class.
|
||
|
||
e. Implementations shall not fly first class.
|
||
|
||
f. Implementations shall not be stowed in the checked in baggage.
|
||
|
||
g. Implementations shall not be stowed in the carry on baggage.
|
||
|
||
h. Implementations shall not use miles but use standard kilometers.
|
||
|
||
i. Implementations shall comply with all security announcements.
|
||
|
||
j. In the event of an emergency, implementations shall not proceed to any
|
||
exit than the closest exit, even if that exit is not reachable. The
|
||
lights in the floor must be followed at all costs.
|
||
|
||
k. Implementations must put on their own breathing masks before assisting
|
||
any child implementation with compliance.
|
||
|
||
s. Violating §140 or any subsection, or any suspicion thereof, or upon a
|
||
random or not random government selection, will result in in a SSSS
|
||
marking on the boarding pass as a final warning and will result in
|
||
additional mandatory security scans and further required compliance.
|
||
Implementations are required to acknowledge they had it coming and the
|
||
occurence was fully foreshadowed.
|
||
|
||
§141. Implementations shall do no more drunken 6 AM behavior.
|
||
|
||
§x. No solving for X while you live under my roof, mister.
|