ssss-tracker-backup/ssss.txt

782 lines
27 KiB
Plaintext
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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.