From d5325774b2d892a0c0e8105790852cd0e82d8c4a Mon Sep 17 00:00:00 2001 From: Juhani Haverinen Date: Wed, 25 Mar 2015 18:27:59 +0200 Subject: [PATCH] Initial SSSS 2015-03-25 --- ssss.txt | 711 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 711 insertions(+) create mode 100644 ssss.txt diff --git a/ssss.txt b/ssss.txt new file mode 100644 index 0000000..907345f --- /dev/null +++ b/ssss.txt @@ -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. +