©CC BY-NC-SA 4.0
🚩加入 Nostr!moe 社区: join.nostr.moe
🚩加入 Nostr!moe 社区: join.nostr.moe
好离谱, 阿里云的公共 DNS 个人专属的无鉴权 DoH/DoT 接入只支持一个客户端并发请求. 要是一个客户端在请求这个地址, 另外一个客户端再同时请求就直接返回 SERVFAIL 了. #吐槽
「模因」和「逆模因」
模因是一种类似基因的「概念」, 被当作是信息和文化的最小单位, 如同分形艺术中组成复杂图案(信息)的最小几何元素(单位), 当承载模因的信息被人理解后, 其中的模因就完成了一次传播(或者是 "感染", "污染"). 模因的传播和变异速度之快, 甚至还对模因宿主的人反向作用于其行为, 可能只是会导致继续传播这种模因, 也可能会因此产生类似的行为, 在互联网中更是加剧了模因的污染, 比如正向的类似的因模因传播导致的 "学习", "理解", "思考", 又或者是非正向地诉诸 "网络暴力", "复读", "跟风".
逆模因的产生伴随模因在一些文字创作里一同出现, 和模因本质相同但属性完全相反, 逆模因无法被直接传播, 因为逆模因本身阻止传播的主要表现就是使宿主遗忘, 或者抹除宿主. 但由于载体信息不会被抹除, 所以可以通过模因来认知逆模因, 当宿主理解这段信息中的模因后会就等同于 "认知" 到逆模因, 会被迅速遗忘或消除这部分记忆, 甚至自我了结, 阻止传播. 即使逆模因自身存在反传播的属性, 但并不会影响到逆模因载体的传播, 这种传播的方式更类似于逆模因生于模因, 以及信息的传播并不需要其中的模因和逆模因被认知. 大多数时候, 逆模因都只是一个相对与模因而存在反向概念, 因为 "设定" 上, 具体的逆模因无法被人永远认知, 因此更不可能被传播, 而传播出来的 "逆模因" 这一概念中包含的也其实只是模因.
听起来模因和逆模因就像两种病毒, 现在也都很喜欢用 "病毒式营销" 来作为一种手段来传播信息, 不过对于真正涉足传播学这一领域中时, 并没有多数认同模因这一概念, 它看起来只不过是 "概念" 的另外一个说法. 并且由于诞生于基因这一「概念」, 也被人用其和基因不符的强烈突变性和随机性驳斥, 而逆模因就更是无从说起, 如今也都只存在于部分文字创作里.
----------------------
● 模因学 - 维基百科，自由的百科全书
● 弄懂模因学 - SCP基金会
● 模因与反模因：基金会最大的敌人(上） | 机核 GCORES
● 模因与逆模因：基金会最大的敌人（下） | 机核 GCORES
#note #模因
via CXPLAY's Memos
模因是一种类似基因的「概念」, 被当作是信息和文化的最小单位, 如同分形艺术中组成复杂图案(信息)的最小几何元素(单位), 当承载模因的信息被人理解后, 其中的模因就完成了一次传播(或者是 "感染", "污染"). 模因的传播和变异速度之快, 甚至还对模因宿主的人反向作用于其行为, 可能只是会导致继续传播这种模因, 也可能会因此产生类似的行为, 在互联网中更是加剧了模因的污染, 比如正向的类似的因模因传播导致的 "学习", "理解", "思考", 又或者是非正向地诉诸 "网络暴力", "复读", "跟风".
逆模因的产生伴随模因在一些文字创作里一同出现, 和模因本质相同但属性完全相反, 逆模因无法被直接传播, 因为逆模因本身阻止传播的主要表现就是使宿主遗忘, 或者抹除宿主. 但由于载体信息不会被抹除, 所以可以通过模因来认知逆模因, 当宿主理解这段信息中的模因后会就等同于 "认知" 到逆模因, 会被迅速遗忘或消除这部分记忆, 甚至自我了结, 阻止传播. 即使逆模因自身存在反传播的属性, 但并不会影响到逆模因载体的传播, 这种传播的方式更类似于逆模因生于模因, 以及信息的传播并不需要其中的模因和逆模因被认知. 大多数时候, 逆模因都只是一个相对与模因而存在反向概念, 因为 "设定" 上, 具体的逆模因无法被人永远认知, 因此更不可能被传播, 而传播出来的 "逆模因" 这一概念中包含的也其实只是模因.
听起来模因和逆模因就像两种病毒, 现在也都很喜欢用 "病毒式营销" 来作为一种手段来传播信息, 不过对于真正涉足传播学这一领域中时, 并没有多数认同模因这一概念, 它看起来只不过是 "概念" 的另外一个说法. 并且由于诞生于基因这一「概念」, 也被人用其和基因不符的强烈突变性和随机性驳斥, 而逆模因就更是无从说起, 如今也都只存在于部分文字创作里.
----------------------
● 模因学 - 维基百科，自由的百科全书
● 弄懂模因学 - SCP基金会
● 模因与反模因：基金会最大的敌人(上） | 机核 GCORES
● 模因与逆模因：基金会最大的敌人（下） | 机核 GCORES
#note #模因
via CXPLAY's Memos
Windows 下的 UTF-8 编码问题 - 续二
第二坑很快就踩到了, 这次是 Windows 文件系统的路径编码问题. 在启用 UTF-8 默认支持后, 系统里已经安装的软件如果没有强制硬编码了使用某一种编码, 那么这些软件里曾经在 GBK 环境下引用的路径也会一律会以 UTF-8 编码读取. 于是这些原本是 GBK 编码存储的路径变量或者配置文件无一例外全都 UTF-8 解码后变成了乱码(比如我正在使用的 FS Capture 和 eDiary).
特别是 Windows 中的库目录, 会随着语言区域的切换变换命名语言, 所以中文语言设置下的库目录都是非 ASCII 字符(中文). 然而大多数的软件又都喜欢用这几个默认的库目录(比如文档, 音乐, 图片等等).
这次的结论是: 最好在 Windows 初始化好, 还没有开始安装配置其他软件的时候就启用默认 UTF-8 编码支持. 否则在系统和其他软件配置完成后再切换编码, 很容易导致这样的路径编码问题.
#Windows
via CXPLAY's Memos
第二坑很快就踩到了, 这次是 Windows 文件系统的路径编码问题. 在启用 UTF-8 默认支持后, 系统里已经安装的软件如果没有强制硬编码了使用某一种编码, 那么这些软件里曾经在 GBK 环境下引用的路径也会一律会以 UTF-8 编码读取. 于是这些原本是 GBK 编码存储的路径变量或者配置文件无一例外全都 UTF-8 解码后变成了乱码(比如我正在使用的 FS Capture 和 eDiary).
特别是 Windows 中的库目录, 会随着语言区域的切换变换命名语言, 所以中文语言设置下的库目录都是非 ASCII 字符(中文). 然而大多数的软件又都喜欢用这几个默认的库目录(比如文档, 音乐, 图片等等).
这次的结论是: 最好在 Windows 初始化好, 还没有开始安装配置其他软件的时候就启用默认 UTF-8 编码支持. 否则在系统和其他软件配置完成后再切换编码, 很容易导致这样的路径编码问题.
#Windows
via CXPLAY's Memos
好快的踩坑. 果然在启用 UTF-8 的默认支持后就出现了问题. 这次是在 zip 压缩格式上的字符编码上, 准确一点来说是中文编码. 如果在 Windows 的 GBK(
cp936) 语言区域设置下使用 zip 打包并加密了一个文档, 将其密码设置为中文字符, 那么这个加密之后的文档在启用了 UTF-8(cp65001) 默认支持的 Windows 系统上是验证不了密码的(也就是密码错误). 除非更换到相同的系统编码配置(取消 UTF-8 默认支持). 但这实际上是 zip 字符编码的问题, 因为相同的 GBK 编码环境下打包的 rar 和 7z 加密格式在 UTF-8 默认支持环境下验证密码完全没有问题. 类似的情况会发生在任何默认不使用 UTF-8 支持的 Windows 上.这次问题的结论是: 不要在 zip 归档中使用非 ASCII 字符作为密码, 即使最新的规范中 zip 允许使用 UTF-8 编码, 但没有规定密码应该使用的编码, 并且几乎所有的软件都不遵守(不会设置 UTF-8 标志), 甚至会随意使用除了 zip 规范里规定的 cp437 和 UTF-8 之外的编码(日语 Shift-JIS(
cp932) 和简体中文 GBK(cp936) 是最常见的重灾区). 在 7z 的实现里 zip 归档时甚至默认不允许使用非 ASCII 字符作为密码, 但另外一个有名的压缩软件 WinRAR 却支持使用任意字符的 zip 密码, 包括中文字符甚至 Emoji.#Windows
via CXPLAY's Memos
Electron 的软件存 cookie 的方式怎么也都和浏览器一模一样, 如果用了 AdGuard 修饰了 cookie 的生存时间, 即使是设定第三方 cookie(软件里哪来的第一方?), 都会被一律修饰掉, 然后第二天你又要重新登录这个 Electron 软件了. #吐槽
● GitHub: theappbusiness/android-proxy-toggle: Small application to help android developers to quickly enable and disable proxy settings
● Releases: Releases · theappbusiness/android-proxy-toggle
Releases 里面包含构建好的 APK 和 ADB 推送脚本, 脚本不包含权限设置. 卸载客户端之前必须要先断开代理状态, 否则会一直保留代理状态.
#software #Android #networkrelay #opensource
via CXPLAY's Memos
今天把哔哩哔哩客户端(Android)的首页分析完了, 发现广告是真的多的. 首页视频流一次时间线刷新(默认的双列模式)算作整体浏览空间的话, 大多数情况一次就有 30% 的面积都是广告, 如果恰好刷出了轮播广告, 比例会提到 40% 以上.
这些广告除掉固定位置的搜索栏滚动关键词外, 包括:
1. 轮播广告.
2. 剧集推荐.
3. 外链网页广告.
4. 卡片式(占双列)视频广告, 通常是自有UP上传的产品相关视频.
5. 外链网页广告(动态封面版).
6. 游戏推荐.
7. UP买推广出来的自荐视频.
8. 另外一种视频广告(占双列), 通常是广告主直接投的广告片.
#吐槽
这些广告除掉固定位置的搜索栏滚动关键词外, 包括:
1. 轮播广告.
2. 剧集推荐.
3. 外链网页广告.
4. 卡片式(占双列)视频广告, 通常是自有UP上传的产品相关视频.
5. 外链网页广告(动态封面版).
6. 游戏推荐.
7. UP买推广出来的自荐视频.
8. 另外一种视频广告(占双列), 通常是广告主直接投的广告片.
#吐槽
