Description

While reading wikipedia these days, there is a new banner calling for against the new "Directive on Copyright in the Digital Single Market" (which will be voted on 5 July) / "EU Copyright directive" / "file 2016/0280(COD)".

The three buttons link to the following pages respectively:

• https://changecopyright.org/
• https://en.wikipedia.org/wiki/Directive_on_Copyright_in_the_Digital_Single_Market
• https://meta.wikimedia.org/wiki/EU_policy/2018_European_Parliament_vote

A brief reading shows that many organizations/foundations (e.g. EFF, Creative Commons, Wikimedia Foundation) oppose to this directive.

The context of this directive can be found at: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52016PC0593

The main against of this directive is Article 11 and Article 13, especially Article 13.

My words

I should say I agree with many of the disputes that Article 13 should be reformed before applied (explanation at the end). One most probable consequence is that MEMEs will become unavailable. (And this will be one more of the stupid things people have done in recent years, just to satisfy the stale copyright laws.)

I don't know what really works, but I found three sites describing some ways:

• https://changecopyright.org/
• https://www.change.org/p/european-parliament-stop-the-censorship-machinery-save-the-internet
• https://saveyourinternet.eu/

Explanation

The texts in the given link differs some bit between what's described in that wikipedia article. I presume this because of the different versions of the document.

Article 13 grants the censoring and blocking ability and obligation to "Information society service providers" (mostly social networking websites, including both commercial ones, e.g. twitter, facebook, and non-commercial ones, e.g. GNUSocial instances, if I understand correctly). This ability suggests them to use "effective content recognition technologies" to "prevent the availability on their services of works or other subject-matter identified by rightholders (through the cooperation with the service providers)".

Although this ability and obligation is supposed to be "appropriate and proportionate", but at least I don't believe commercial bodies (i.e. companies) will do this "appropriately" in a minimal effort way. They will overactive, both for their "compliance with the law" and for their profit purpose. Some companies in China have already demonstrated this, and I guess there are also some examples in Europe and America.

The piece of text says "identified by rightholders", but in reality "rightholders" in many cases are not a single human but a company. We have heard many stories how companies over-use their copyright to prevent what we as humans see as normal behaviours (let alone I don't totally agree with the copyright [law] nowadays because I think they are developed for paper-publishing era not digital era).

The "Information society service providers" are, most of the time, companies; companies are for profit. Therefore, the nature of capital makes them not sympathetic, and blocking the Internet doesn't really affect their profit (because "everyone" does this, leaving us no choice). https://twitter.com/EvenDragsnes/status/1014394747706925056 is definitely not a future I want.

(Terrorism and some other things shall be dealt with, but this directive has nothing to do with that.)

想將TiddlyWiki搭建在GitLab Pages已經很久。今日終於用半個小時時間完成此事，完成後覺得竟然如此簡單。然而之前始終找不到合適的教程，實在讓人糾結，故而記錄要點（並簡單介紹TiddlyWiki在該模式下的使用），以便有需要者。

簡介

TiddlyWiki是一個工作在瀏覽器中的wiki系統，其對我來說最有用的特性是：1) 支持插件（通過JS）；2) 支持自定義宏 (macro)。

由於TiddlyWiki設計爲在瀏覽器中工作，所以理所當然地可以託管在GitHub Pages或GitLab Pages這類靜態網站上。雖然使用TiddlyWiki本身的單一HTML版即可，但我總覺得這樣比較臃腫，而且不好追蹤版本變更，所以更傾向於這種使用server版功能的方式（即每個tiddler是單一文件，之後轉換爲網站）。

雖然已有前人給出的搭建模板，只用fork過來即可使用，但我個人略有強迫症，想要一個“清淨”的版本。所以簡單翻閱了GitLab的相關說明頁面後，仿照其例子自己從頭構建了一個倉庫（及對應Pages）。

本文假設讀者有基本的git知識，並且已安裝tiddlywiki服務端軟件（tiddlywiki）。下面的描述均假設當前在一個空目錄/空的git倉庫中。

初始化TiddlyWiki

TiddlyWiki支持兩種模式：單一HTML頁面模式和本地服務器模式。既然要使用版本控制，本地服務器模式更加適合：該模式下，每個頁面（即Tiddler）均分別以文件形式存放，更適宜版本控制。

首先，使用下面命令創建服務器模式的TiddlyWiki：

tiddlywiki wiki --init server

該命令將會創建一個名叫wiki的目錄，其中存放TiddlyWiki服務器模式配置。要在本地瀏覽或更改該wiki的內容，執行下面命令，並且打開瀏覽器訪問localhost:8080：

tiddlywiki wiki --server

對該wiki的編輯均會存放在wiki目錄下（的tiddlers目錄中）。而且配置、插件等也是以文件形式存在，可以說是無縫接合。

在該模式下，對tiddler的修改會自動保存（可能有較小延遲），而不需要（也不應該）使用“保存”按鈕——除非你的確想將你的wiki保存爲單一HTML。類似地，在GitLab Pages的頁面上的修改不會被持久化，因爲沒有後端服務程序在執行——但你可以將其當成一個安全的沙箱隨便修改。

GitLab Pages

GitLab Pages是使用GitLab的流水線機制而構建起來的特殊功能。其理念源於GitHub Pages，但實現方式有所區別，且GitLab Pages更爲靈活（至於github pages如要達到該靈活度，則必須依賴外部CI）。

在倉庫根目錄中，.gitlab-ci.yml控制GitLab流水線如何執行——當push發生時，GitLab會自動根據該文件執行CI。GitLab Pages在.gitlab-ci.yml中使用專門的pages節。在該CI執行結束後，倉庫（生成文件中）的public目錄中的文件會被發佈到GitLab Pages上（網址構成同GitHub Pages類似）。GitLab Pages完全依賴該配置文件中的描述，不需要像GitHub那樣手動打開Pages。

對於部署TiddlyWiki來說，所用的.gitlab-ci.yml內容其實很短：

image: node:latest

pages:
  stage: deploy
  script:
    - npm install -g tiddlywiki
    - tiddlywiki wiki --build
    - mv wiki/output public
  artifacts:
    paths:
      - public
  only:
    - master

原理上看，搭建的方法就是通過tiddlywiki的工具，在CI時生成頁面，然後放到public目錄。由於tiddlywiki是nodejs程序，所以在.gitlab-ci.yml的image部分聲明使用nodejs的docker鏡像。

注意，如前文所說，我這裏將tiddlywiki的文件結構（tiddlywiki.info所在地）放在之前所描述的wiki目錄中。該代碼片段中所有引用wiki目錄的地方均是出於此處。

至此，GitLab方面也已經設置完畢。之後只要正常將該倉庫提交，並push到GitLab上即可。

每當我們提到中國，不可避免地總會想到“歷史悠久”、“文明傳承”這類的辭彙，並且我們也毫無疑問地以此自豪。而相比其他“文明”，華夏文明之所以稱自己爲唯一的未曾斷絕的文明古國，乃是因爲語言文字並未斷流。

從篆書到隸書、從隸書到楷書，史家告訴我們文字的演變一脈相承；二十世紀發現甲骨文，雖形態不同但仍可見其脈絡。楷書確立以後，後世最大的變化也就只是將兩千漢字進行簡化，但仍是楷書形魄。這是我們所知的內容，也是大家耳熟能詳甚至感慨耳朵磨出繭子的事實。但有意無意地，我們似乎忘記了語文乃是“語言文字”——除了文字（形），還有語言（音）。

的確，語言本身的變化遠比文字變化難以描述——文字有記載、有實物、可以被書寫繪畫，但在沒有留聲機的年代幾乎無法記錄語音。先民竭盡所能，也僅是使用轉寫、擬音的方式部分描繪語音變革——這算是我們的表意文字的唯一遺憾了吧。所幸，古代語音並非完全被埋沒於時光之中，音韻學家仍然找到方法去嘗試還原古音的面目——通過《廣韻》等著作，加之歷代反切註音，外加詩詞歌賦等韻文。我對該方面的粗淺瞭解到此爲止，不過至少我抓住了其中一個重要信息：語音演變也有脈絡可循。

該認知促成了我對當代標準漢語（普通話）語音規定的認知。就如我在知乎問題《为什么角色的角念jue，却仍有人念Jiao ？》下的回答所說：

和大多數人會稀泥似地認爲“語言是在變化的所以你不應該糾結”不同，我的看法是“有的讀音是可以接受的（符合演變規律的），有的讀音是不可以接受的（不符合演變規律胡來的）”，並且認爲“官方標準應該儘量取中道”。

該認知的基礎認知是：語言文字是交流的工具，但不只是同代之人交流的工具，也是歷史長河中前人和後人交流的工具。最優的選擇顯然是兩者兼顧，如果不能則在儘量兼顧的基礎上選擇“危害”更小的那個。但不幸的是多數情況下人們/機構們會優先選擇照顧前者——畢竟他們“認識”和“打交道”的都是同代之人，而非歷史上的先人或後人。

而今日看到一篇題爲《说shuō客？坐骑qí？我怕是上了个假学！》的文章，（再次）歷數語改委在語音標準上幹的事情，讓我既是慶幸又是無奈：語改委還是當年那個語改委——腦殘、吃乾飯。

近些年語改委做得最多的就是修改普通話文字讀音，而修改目的幾乎無一例外都是爲了“符合大衆認知”，換句話說就是“讀得錯了的多了也就成了對的”。這是典型的不顧歷史的做法，而且其對當代人交流的作用恐怕也極爲有限。人民的自我學習能力遠比語改委那幫老爺們想像得要強——我們可以理解、認知其他人和我們的不同讀音所指的是同一辭彙，就算不理解也可以去“詢問”。而如果說這是爲了在教育中減負，那就更是滑天下之大稽了。始終會有（不小的一部分）人和“標準”的讀音不同（不論是由於方言、誤聽、遵循歷史沿革還是什麼），所以始終需要在中小學教育中普及“標準”。既然需要普及“標準”，那麼這份努力始終需要，故而這些時間始終需要花費。在這件事上，考慮“有較多學生需要着重記憶標準”還是“有較少學生需要着重記憶標準”並沒有什麼意義。

該文中還特別點出了一件事：部分“標準”曾經由“符合歷史”改爲“符合多數當代人認知”（且不提樣本是否具有代表性）又改爲“符合歷史”。這件事更是顯示了語改委對該定義什麼樣的標準沒有自己的認知。

當然，看起來，《说shuō客？坐骑qí？我怕是上了个假学！》對“大衆要求這些字的語音標準照舊”這件事持淡淡的嘲諷態度——其作者要麼是認爲“（語音標準）只需要符合當代人需求就好”，要麼僅僅是習慣性嘲諷。首先作者似乎認爲只能在“完全不要變”和“隨便變”之間選擇一種。其次，作者看來，人民對於語音標準變化的態度大抵是“符合我的習慣的我就支持，不符合的我就反對”——這從作者列舉了數次“之前的”語音乃至語義改變，並說人們對此沒有意見可見一斑。最後，作者似乎是認爲人民對語音標準這件事只是被動的接受者，而一切變化全部取決於語改委的老爺。

然而這三點，恕我無法苟同。

如前文所述，語音的選擇應該是一個權衡的過程，要“在儘量兼顧的基礎上選擇‘危害’更小的那個”。其核心不是考慮“變”還是“不變”，也不是考慮“聽哪個人的”，而是考慮歷史和當下的平衡。而如上文所述，其實無論標準是什麼，對當下的影響都微乎其微，所以我認爲應該側重歷史。而當下對標準修改的反應是可以預期的：部分（是的，始終都只有部分）人會反對。那麼，爲什麼標準制定者不可以在頒佈標準的同時頒佈理由呢？人民不是傻瓜，只要說得在理，絕大多數人是會聽從的。

作者似乎並不知道，在萬維網的一些區域，許多人在不斷重新發掘詞的原始意義、字的合理讀音，並自發地總結其中規律並形成系統，且不斷告訴其他人這些東西本該是什麼樣。作者或許是認爲這些人太少，但我看到的卻是這些人越來越多，而且越來越多的人接受了對於“正確”的普及。只不過由於這種變化太過潤物細無聲，作者或許已經見過其結論，但並沒有意識到其來自於何處。

而對於標準制定者，也就是語改委，我一如既往地對其進行嘲諷。如果認同人民共和國，那麼語改委應該兢兢業業堅持尋求當代與歷史的平衡，並且向人民說明，而不是像現在這樣尸位素餐；如果是古代的士人成館，那麼語改委應該堅持先王之道，而非數易其化。無論是哪種，語改委都沒有做正確的事情，所以受這一聲嘲諷並無不妥。而無論是古代還是現代，無論是東方還是西方，政府始終是應當聆聽乃至受命於人民的。現在的部分部門不這樣做，不是我們應該認可他們行爲的理由——恰恰相反，這是我們應該更努力指出並反對的理由。

寫本文的契機爲近日聽之前緩存的播客《太医来了》中《再论中西医之争》一篇，其中講述者的一些觀點和我的不謀而合，但同時仍覺得有不同之處。加之博客的“關於”頁面中極其簡略地提了我對中西醫的觀念，故而忽然覺得有必要將其展開描述一下。

本文儘可能完整地描述我對醫學、中醫、西醫（名稱後文再議）以及各個相關內容的觀點，以及其理由。有不同觀點歡迎討論，但迷信者請自覺閃開。

另：我並非是醫學專業學生或從業人員，所以很可能文中對（醫學直接相關）事情的認知並不準確；但我會儘量將我理解到的東西及其依據描述出來。歡迎指出錯誤之處，但請指出時儘量直指要害，節省大家的時間。

簡單版

1. 西醫（現代醫學）可信，其可信在於其背後的證據，而非其理論使用“科學”名詞
2. 中醫可信與否不在於其用了陰陽五行等詞彙來描述/解釋現象，而應該取決於事實
3. 神棍、騙子不是中醫從業者，其理論、做法及錯誤性不應當和中醫掛鉤
4. 我經歷過不少中醫手段效果達到其承諾的例子，故而我相信中醫理論中有相當部分可信
5. 我同樣認爲中醫理論需要更新（現代化），且中醫（從業者）需要更好地和大衆解釋
6. 現代化≠西醫化，而在於重證據（後驗）、剔先驗
7. 醫學理論最好可以整合，如果實在無法整合爲一，則釐定邊界、共同使用