©CC BY-NC-SA 4.0
🚩加入 Nostr!moe 社区: https://join.nostr.moe
🚩加入 Nostr!moe 社区: https://join.nostr.moe
dnslookup 是一个支持多种 DNS 协议查询域名解析的命令行工具, 支持明文 DNS, DoH, DoT, DoQ 和 DNSCrypt, 对 DoH 也支持 HTTP/3 查询. 使用 Go 语言编写, 支持多平台.
● GitHub: ameshkov/dnslookup: Simple command line utility to make DNS lookups to the specified server
● Release: Releases · ameshkov/dnslookup
● ref: How to query for DNS over HTTPS/DNS over TLS using command line? - Super User
#DNS #software #macOS #FreeBSD #Linux #Windows #opensource
via CXPLAY's Memos
● GitHub: ameshkov/dnslookup: Simple command line utility to make DNS lookups to the specified server
● Release: Releases · ameshkov/dnslookup
● ref: How to query for DNS over HTTPS/DNS over TLS using command line? - Super User
#DNS #software #macOS #FreeBSD #Linux #Windows #opensource
via CXPLAY's Memos
2011 年，福岛的事故刚被传出来不到一个星期，我还很清晰的记得就连我们住的小城镇上都开始疯狂屯盐，特别是各大餐饮店。连自己家的人也不免受到周边人的影响，要去考虑是否要一起抢盐。
12 年后的今天，福岛的核污染废水要排放入海了，屯盐浪潮又开始了，但这次我们同样的小城市里几乎没有人再会有动作，就算人人都在刷抖音看新闻，可能人人都知道这件事，但情况已经变得不一样。 #吐槽
12 年后的今天，福岛的核污染废水要排放入海了，屯盐浪潮又开始了，但这次我们同样的小城市里几乎没有人再会有动作，就算人人都在刷抖音看新闻，可能人人都知道这件事，但情况已经变得不一样。 #吐槽
2. 有效量化, 降低信息差, 是企业运作的核心.
3. 人性是经不起挑战的, 商业, 是切蛋糕的艺术.
----------------------
出自: 影视飓风 - 创业故事 Part.2, Tim(潘天鸿)在公司运作困境时向他的父亲(潘水苗, 圆通速递总裁)请教后得到的三条建议.
----------------------
#note
via CXPLAY's Memos
由于 AdGuard Home 的查询缓存在内存里，所以重启后就没了，命中缓存后也没办法清理指定域名的缓存。
如果发现明显错误的 DNS 响应就要么清理全部缓存（WebUi/重启），要么就只能写规则并且加上 important 修饰符强行重写 DNS 响应，直到所有的上游都命中规则并再次缓存后也许就能达到清理指定域名缓存的效果？
AdGuard Home 虽然也能用 dnsmasq 类似的分流规则，但列表一长起来就难以维护。 #吐槽
如果发现明显错误的 DNS 响应就要么清理全部缓存（WebUi/重启），要么就只能写规则并且加上 important 修饰符强行重写 DNS 响应，直到所有的上游都命中规则并再次缓存后也许就能达到清理指定域名缓存的效果？
AdGuard Home 虽然也能用 dnsmasq 类似的分流规则，但列表一长起来就难以维护。 #吐槽
好离谱, 阿里云的公共 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
