27.xhtml 14 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <!--
  3. h t t :: / / t /
  4. h t t :: // // t //
  5. h ttttt ttttt ppppp sssss // // y y sssss ttttt //
  6. hhhh t t p p s // // y y s t //
  7. h hh t t ppppp sssss // // yyyyy sssss t //
  8. h h t t p s :: / / y .. s t .. /
  9. h h t t p sssss :: / / yyyyy .. sssss t .. /
  10. <https://y.st./>
  11. Copyright © 2016 Alex Yst <mailto:copyright@y.st>
  12. This program is free software: you can redistribute it and/or modify
  13. it under the terms of the GNU General Public License as published by
  14. the Free Software Foundation, either version 3 of the License, or
  15. (at your option) any later version.
  16. This program is distributed in the hope that it will be useful,
  17. but WITHOUT ANY WARRANTY; without even the implied warranty of
  18. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  19. GNU General Public License for more details.
  20. You should have received a copy of the GNU General Public License
  21. along with this program. If not, see <https://www.gnu.org./licenses/>.
  22. -->
  23. <!DOCTYPE html>
  24. <html xmlns="http://www.w3.org/1999/xhtml">
  25. <head>
  26. <base href="https://y.st./en/weblog/2016/02-February/27.xhtml" />
  27. <title>The Unknown Man surfaces, then disappears again &lt;https://y.st./en/weblog/2016/02-February/27.xhtml&gt;</title>
  28. <link rel="icon" type="image/png" href="/link/CC_BY-SA_4.0/y.st./icon.png" />
  29. <link rel="stylesheet" type="text/css" href="/link/basic.css" />
  30. <link rel="stylesheet" type="text/css" href="/link/site-specific.css" />
  31. <script type="text/javascript" src="/script/javascript.js" />
  32. <meta name="viewport" content="width=device-width" />
  33. </head>
  34. <body>
  35. <nav>
  36. <p>
  37. <a href="/en/">Home</a> |
  38. <a href="/en/a/about.xhtml">About</a> |
  39. <a href="/en/a/contact.xhtml">Contact</a> |
  40. <a href="/a/canary.txt">Canary</a> |
  41. <a href="/en/URI_research/"><abbr title="Uniform Resource Identifier">URI</abbr> research</a> |
  42. <a href="/en/opinion/">Opinions</a> |
  43. <a href="/en/coursework/">Coursework</a> |
  44. <a href="/en/law/">Law</a> |
  45. <a href="/en/a/links.xhtml">Links</a> |
  46. <a href="/en/weblog/2016/02-February/27.xhtml.asc">{this page}.asc</a>
  47. </p>
  48. <hr/>
  49. <p>
  50. Weblog index:
  51. <a href="/en/weblog/"><abbr title="American Standard Code for Information Interchange">ASCII</abbr> calendars</a> |
  52. <a href="/en/weblog/index_ol_ascending.xhtml">Ascending list</a> |
  53. <a href="/en/weblog/index_ol_descending.xhtml">Descending list</a>
  54. </p>
  55. <hr/>
  56. <p>
  57. Jump to entry:
  58. <a href="/en/weblog/2015/03-March/07.xhtml">&lt;&lt;First</a>
  59. <a rel="prev" href="/en/weblog/2016/02-February/26.xhtml">&lt;Previous</a>
  60. <a rel="next" href="/en/weblog/2016/02-February/28.xhtml">Next&gt;</a>
  61. <a href="/en/weblog/latest.xhtml">Latest&gt;&gt;</a>
  62. </p>
  63. <hr/>
  64. </nav>
  65. <header>
  66. <h1>The Unknown Man surfaces, then disappears again</h1>
  67. <p>Day 00357: Saturday, 2016 February 27</p>
  68. </header>
  69. <p>
  70. We spent the beginning of the day finishing up our cleaning of the house so that my mother&apos;s friend could come over.
  71. She came and stayed the night, the event that she came to participate in will be tomorrow.
  72. </p>
  73. <p>
  74. <a href="https://ronsor.net/">Ronsor</a> added a feedback form on his website, asking for users to rate the site.
  75. Strangely enough, any input added to the form will then be sent to your mail client upon submission, then you send the email for it to reach Ronsor.
  76. I&apos;ve never heard of a setup like that.
  77. He asked <a href="https://opalrwf4mzmlfmag.onion/">wowaname</a> and I to try it out, so I disabled JavaScript in <a href="apt:iceweasel">Iceweasel</a> to try out the site, as I thought that the site made heavy use of JaveScript for some reason and wanted to be sure to test for accesibility.
  78. If I was going to give a rating, I was going to actually put in the effort to provide feedback that would actually lead to fixes.
  79. However, the site seemd to work pervectly.
  80. I didn&apos;t test out the chat page, and that probably does require avaScript, but the main pages of the site should and did function.
  81. Next, worrying about the heavy use of frames, I tried the website in the <a href="apt:links">Links</a> text-based Web browser.
  82. Surprisingly, I found that Links actually handles frames in a reasonable way! I suspect that frames still don&apos;t work in some other text-based browsers, but if Links can handle it, maybe that&apos;s something that other text-based Web browsers need to fix.
  83. With my two major accessibility concerns alleviated, I commented about the fact that the page doesn&apos;t pass <abbr title="World Wide Web Consortium">W3C</abbr> validation and that <abbr title="Hypertext Transfer Protocol Secure">HTTPS</abbr> support would be much appreciated, even if using only a self-signed certificate.
  84. I never did go back and check to see if the page validates, as I only care on my own pages when not actively submitting reviews, but Ronsor did set up <abbr title="Hypertext Transfer Protocol Secure">HTTPS</abbr> access to his website!
  85. </p>
  86. <p>
  87. Ronsor did mention that <abbr title="Hypertext Transfer Protocol Secure">HTTPS</abbr> support was only set up on his main site though, not the mirrors.
  88. The mention of mirrors intrigued me, so I asked about them.
  89. For them to be relevant, they needed to be at the same domain as the main site, using some sort of round robin system or the like.
  90. If that was the case, I couldn&apos;t link to the <abbr title="Hypertext Transfer Protocol Secure">HTTPS</abbr> site, as it wouldn&apos;t always work depending on which server was queried, but I wouldn&apos;t call having several servers on using the same <abbr title="Domain Name System">DNS</abbr> address &quot;mirrors&quot;.
  91. The alternative would be that there actually were mirrors, but in that case, why even mention them? He obviously cannot control whether mirrors use <abbr title="Hypertext Transfer Protocol Secure">HTTPS</abbr> or not, plus there is not mention of mirror addresses on his site.
  92. As it turns out, he did indeed actually mean mirrors, and has asked people to mirror his website.
  93. He says he&apos;ll add instructions for mirroring to the site, so I&apos;ll check back later and maybe set up a mirror here in onion space.
  94. </p>
  95. <p>
  96. On <a href="ircs://kitsune6uv4dtdve.onion:6697/%23Volatile">#Volatile</a>, The_Black_V1PER was trying to figure out how to retrieve weather forecasts from <a href="https://wttr.in/">wttr.in</a>, which seems to be a pretty cool weather service.
  97. In-browser, it sends text colored via <code>&lt;span/&gt;</code> tags, but when used via the command line (for example, using Wget), it colors text using terminal-compatible color byte sequences.
  98. I&apos;m not sure exactly how it tells the difference between clients.
  99. I suspect that it uses the User-Agent string sent by the client, but if that&apos;s the case, it defaults to the <abbr title="Hypertext Markup Language">HTML</abbr> version; it sends the <abbr title="Hypertext Markup Language">HTML</abbr> version to my Web browser, but my Web browser is set not to send that header.
  100. <a href="https://github.com/chubin/wttr.in">Source code</a> is available for anyone that wants to run their own instance of the service or study how it works.
  101. </p>
  102. <p>
  103. I managed to get in touch with <a href="http://zdasgqu3geo7i7yj.onion/">The Unknown Man</a> today.
  104. With my <abbr title="Internet Relay Chat">IRC</abbr> server up and operational, he decided not to invest in an <abbr title="Internal Revenue Service">IRS</abbr> server hosting service, which I think is for the best.
  105. We don&apos;t have enough users to require multiple servers yet, so it would be wasted money.
  106. Hopefully by the time we need more servers, some users will want to add their own machines to the network instead of renting hardware.
  107. He also gave me a new email address to reach him at, but <a href="apt:evolution">my email client</a> is being a pain.
  108. It doesn&apos;t have an option to manually choose which key to use for encryption and his <abbr title="Pretty Good Privacy">PGP</abbr> key specifies his old email address.
  109. The email address attached to the key is of course no longer valid too.
  110. I need to figure out what to do about this once I have caught up on everything again.
  111. </p>
  112. <p>
  113. My check from the <abbr title="Internal Revenue Service">IRS</abbr> came today, but I got distracted and didn&apos;t get a chance to open the envelope.
  114. More importantly, my insurance card came.
  115. Oddly enough, twelve insurgence cards came, but two were blank and nine were voided out.
  116. It seems like a waste of paper, but whatever.
  117. I still find it idiotic that health insurance has become mandatory, but at least i have that out of the way for this year.
  118. </p>
  119. <p>
  120. I added client certificate recognition to NickServ.
  121. It only involved uncommenting a single line.
  122. I&apos;m not sure why this is disabled by default, to be honest.
  123. In any case, if you configure your NickServ account with your client certificate fingerprint, you will now be identified by NickServ automatically.
  124. </p>
  125. <p>
  126. I was discussing <abbr title="Secure Digital">SD</abbr> cards with someone on Tox today, and came across some interesting information.
  127. I had thought it stupid that mobile devices can only handle <abbr title="Secure Digital">SD</abbr> cards up to a certain size.
  128. After all, an <abbr title="Secure Digital">SD</abbr> card is an <abbr title="Secure Digital">SD</abbr> card, right? However, I didn&apos;t really question it.
  129. However, if the person I was speaking to is correct, the information about maximum <abbr title="Secure Digital">SD</abbr> card size is actually a lie.
  130. A regular <abbr title="Secure Digital">SD</abbr> card can only be built to carry so much, but a different standard, <a href="https://en.wikipedia.org/wiki/Secure_Digital#SDXC"><abbr title="Secure Digital Extended Capacity">SDXC</abbr></a>, can be used to create cards that hold even more.
  131. He said that a device that can handle one size of <abbr title="Secure Digital Extended Capacity">SDXC</abbr> card can handle an <abbr title="Secure Digital Extended Capacity">SDXC</abbr> card of any size.
  132. The <abbr title="Secure Digital Extended Capacity">SDXC</abbr> standard covers <abbr title="Secure Digital">SD</abbr> cards with sizes ranging from 64 gigabytes to 2 terabytes, so because my device can supposedly handle cards up to 64 gigabytes in size, it should also be able to handle larger cards up to 2 terabytes in size.
  133. This is awesome! I don&apos;t need a card quite that big yet, but when I get there, I won&apos;t need to trim my music collection, I&apos;ll just need to get a bigger card.
  134. By that time, <abbr title="Secure Digital">SD</abbr> card prices will probably have fallen even lower too.
  135. </p>
  136. <p>
  137. I read an interesting article on <a href="http://www.hxa.name/articles/content/The-Illusion-Of-Decentralisation_HXA7241_2015.html">the illusion of decentralization</a>.
  138. Basically, the point the article makes is that you cannot decentralize everything; it simple isn&apos;t possible without making communication impossible.
  139. When communication is centralized, these central authorities are able to create whatever &quot;standard&quot; that is used for their platforms.
  140. You end up with many different services, each with their own protocol.
  141. The development of such communication protocols is decentralized.
  142. However, in order to create a platform in which communication is decentralized, all participants must agree on a standard.
  143. There could be thousands of servers deployed by varying individuals and companies, but development of the protocols must be centralized.
  144. Without centrally-developed protocols, the many nodes are not speaking the same language and are unable to properly interact.
  145. The article argued that this later strategy, what we normally think of as &quot;decentralized&quot;, is actually even more centralized than &quot;centralized&quot; services.
  146. What these &quot;decentralized&quot; services actually offer isn&apos;t decentralization, but a consistent and stable set of rules.
  147. We need to stop focusing on &quot;decentralization&quot;, and instead ask ourselves and each other what set of rules actually work best for us as users.
  148. Personally, being able to keep our own data in our own hands seems to be a pretty good reason for sticking with standardized protocols, but we need to make sure that these protocols are well-designed enough to actually provide us with what we need.
  149. </p>
  150. <hr/>
  151. <p>
  152. Copyright © 2016 Alex Yst;
  153. You may modify and/or redistribute this document under the terms of the <a rel="license" href="/license/gpl-3.0-standalone.xhtml"><abbr title="GNU&apos;s Not Unix">GNU</abbr> <abbr title="General Public License version Three or later">GPLv3+</abbr></a>.
  154. If for some reason you would prefer to modify and/or distribute this document under other free copyleft terms, please ask me via email.
  155. My address is in the source comments near the top of this document.
  156. This license also applies to embedded content such as images.
  157. For more information on that, see <a href="/en/a/licensing.xhtml">licensing</a>.
  158. </p>
  159. <p>
  160. <abbr title="World Wide Web Consortium">W3C</abbr> standards are important.
  161. This document conforms to the <a href="https://validator.w3.org./nu/?doc=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2016%2F02-February%2F27.xhtml"><abbr title="Extensible Hypertext Markup Language">XHTML</abbr> 5.1</a> specification and uses style sheets that conform to the <a href="http://jigsaw.w3.org./css-validator/validator?uri=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2016%2F02-February%2F27.xhtml"><abbr title="Cascading Style Sheets">CSS</abbr>3</a> specification.
  162. </p>
  163. </body>
  164. </html>