昨天趁着 Apple Music 解密成功, 验证了一下 Apple 的音乐流媒体质量.
> 上文: https://t.me/cxplayworld/1111
Apple Music 有 "无损", "高解析度无损", "数字母带", "Dolby Atoms" 三种标签.
至于音频质量标签, 其中只有 "无损", "高解析度无损" 才是质量标签, 类似 HQ, SQ, Hi-Res 这样的. "无损" 代表质量最高可达 48kHz/24bit, "高解析度无损" 代表质量最高可达到 192kHz/24bit, 要注意范围限制词. "无损" 是 44.1kHz/16bit 及以上就是, 即 44.1kHz/16bit, 48kHz/16bit, 44.1kHz/24bit 都能标上 "无损". 而 "高解析度无损" 则是高于 48kHz/24bit 任意其一条件的都能标上 "高解析度无损", 即 96kHz/16bit, 192kHz/24bit 都是 "高解析度无损". 并且一张标 "高解析度无损" 的专辑并不代表全部曲目都是一样的质量, 只要有其中一首达到了最高要求, 那么就会被标上标签.
至于 "数字母带" (以前的 Mastered for iTunes), 这其实是种 Apple 对音乐人或者版权方的要求, 只要满足了 Apple 数字母带的制作标准并通过流程交付给 Apple 的都能被标上 "数字母带", 具体要求是[^1]:
- 音频的位深度必须为 24 位, 并使用支持的格式交付.
- 可接受的采样率为 44.1, 48, 88.2, 96, 176.4 和 192 kHz.
这里面除了要求交付的音频不低于 44.1kHz/24bit, 还要求 "使用支持的格式交付", 是什么格式呢? 答案是 AAC, ALAC, FLAC.
Apple 在自己的数字母带技术手册里面甚至宣称只有为 AAC "这种格式专门制作母带才有意义" (It only makes sense to create masters specifically for this format).
2. 有效量化, 降低信息差, 是企业运作的核心.
3. 人性是经不起挑战的, 商业, 是切蛋糕的艺术.
----------------------
出自: 影视飓风 - 创业故事 Part.2, Tim(潘天鸿)在公司运作困境时向他的父亲(潘水苗, 圆通速递总裁)请教后得到的三条建议.
----------------------
#note
via CXPLAY's Memos
「模因」和「逆模因」
模因是一种类似基因的「概念」, 被当作是信息和文化的最小单位, 如同分形艺术中组成复杂图案(信息)的最小几何元素(单位), 当承载模因的信息被人理解后, 其中的模因就完成了一次传播(或者是 "感染", "污染"). 模因的传播和变异速度之快, 甚至还对模因宿主的人反向作用于其行为, 可能只是会导致继续传播这种模因, 也可能会因此产生类似的行为, 在互联网中更是加剧了模因的污染, 比如正向的类似的因模因传播导致的 "学习", "理解", "思考", 又或者是非正向地诉诸 "网络暴力", "复读", "跟风".
逆模因的产生伴随模因在一些文字创作里一同出现, 和模因本质相同但属性完全相反, 逆模因无法被直接传播, 因为逆模因本身阻止传播的主要表现就是使宿主遗忘, 或者抹除宿主. 但由于载体信息不会被抹除, 所以可以通过模因来认知逆模因, 当宿主理解这段信息中的模因后会就等同于 "认知" 到逆模因, 会被迅速遗忘或消除这部分记忆, 甚至自我了结, 阻止传播. 即使逆模因自身存在反传播的属性, 但并不会影响到逆模因载体的传播, 这种传播的方式更类似于逆模因生于模因, 以及信息的传播并不需要其中的模因和逆模因被认知. 大多数时候, 逆模因都只是一个相对与模因而存在反向概念, 因为 "设定" 上, 具体的逆模因无法被人永远认知, 因此更不可能被传播, 而传播出来的 "逆模因" 这一概念中包含的也其实只是模因.
听起来模因和逆模因就像两种病毒, 现在也都很喜欢用 "病毒式营销" 来作为一种手段来传播信息, 不过对于真正涉足传播学这一领域中时, 并没有多数认同模因这一概念, 它看起来只不过是 "概念" 的另外一个说法. 并且由于诞生于基因这一「概念」, 也被人用其和基因不符的强烈突变性和随机性驳斥, 而逆模因就更是无从说起, 如今也都只存在于部分文字创作里.
----------------------
● 模因学 - 维基百科，自由的百科全书
● 弄懂模因学 - SCP基金会
● 模因与反模因：基金会最大的敌人(上） | 机核 GCORES
● 模因与逆模因：基金会最大的敌人（下） | 机核 GCORES
#note #模因
via CXPLAY's Memos
模因是一种类似基因的「概念」, 被当作是信息和文化的最小单位, 如同分形艺术中组成复杂图案(信息)的最小几何元素(单位), 当承载模因的信息被人理解后, 其中的模因就完成了一次传播(或者是 "感染", "污染"). 模因的传播和变异速度之快, 甚至还对模因宿主的人反向作用于其行为, 可能只是会导致继续传播这种模因, 也可能会因此产生类似的行为, 在互联网中更是加剧了模因的污染, 比如正向的类似的因模因传播导致的 "学习", "理解", "思考", 又或者是非正向地诉诸 "网络暴力", "复读", "跟风".
逆模因的产生伴随模因在一些文字创作里一同出现, 和模因本质相同但属性完全相反, 逆模因无法被直接传播, 因为逆模因本身阻止传播的主要表现就是使宿主遗忘, 或者抹除宿主. 但由于载体信息不会被抹除, 所以可以通过模因来认知逆模因, 当宿主理解这段信息中的模因后会就等同于 "认知" 到逆模因, 会被迅速遗忘或消除这部分记忆, 甚至自我了结, 阻止传播. 即使逆模因自身存在反传播的属性, 但并不会影响到逆模因载体的传播, 这种传播的方式更类似于逆模因生于模因, 以及信息的传播并不需要其中的模因和逆模因被认知. 大多数时候, 逆模因都只是一个相对与模因而存在反向概念, 因为 "设定" 上, 具体的逆模因无法被人永远认知, 因此更不可能被传播, 而传播出来的 "逆模因" 这一概念中包含的也其实只是模因.
听起来模因和逆模因就像两种病毒, 现在也都很喜欢用 "病毒式营销" 来作为一种手段来传播信息, 不过对于真正涉足传播学这一领域中时, 并没有多数认同模因这一概念, 它看起来只不过是 "概念" 的另外一个说法. 并且由于诞生于基因这一「概念」, 也被人用其和基因不符的强烈突变性和随机性驳斥, 而逆模因就更是无从说起, 如今也都只存在于部分文字创作里.
----------------------
● 模因学 - 维基百科，自由的百科全书
● 弄懂模因学 - SCP基金会
● 模因与反模因：基金会最大的敌人(上） | 机核 GCORES
● 模因与逆模因：基金会最大的敌人（下） | 机核 GCORES
#note #模因
via CXPLAY's Memos
Windows 下的 UTF-8 编码问题
----------------------
这几天又遇到 Windows 下的字符编码问题了, 于是还是决定记录一下.
----------------------
由于 Windows NT 发布时 UTF-8 甚至都没有出现, 所以微软选择 Unicode 的时候用了 UTF-16. 虽然现在 Windows 的区域设置里有一个选项能够让 Windows 默认使用 UTF-8 来显示字符, 但直到今天 Windows 11 这个选项都还是 beta 状态不会给你默认启用.
在简体中文的设置下 Windows 默认使用
系统首选的编码是
但我也还记得我很久之前在 Windows 10 上开启过这个 UTF-8 支持选项, 但后来不知道为什么又主动去关掉了, 原因已经记不清楚了, 可能等以后踩到坑才会想起来吧.
#note #Windows #Python
via CXPLAY's Memos
----------------------
这几天又遇到 Windows 下的字符编码问题了, 于是还是决定记录一下.
----------------------
由于 Windows NT 发布时 UTF-8 甚至都没有出现, 所以微软选择 Unicode 的时候用了 UTF-16. 虽然现在 Windows 的区域设置里有一个选项能够让 Windows 默认使用 UTF-8 来显示字符, 但直到今天 Windows 11 这个选项都还是 beta 状态不会给你默认启用.
在简体中文的设置下 Windows 默认使用
cp936(GBK) 代码页, 英语设置下使用 cp850 或者 cp1252(Windows-1252). 如果开启了区域设置里的 UTF-8 支持, 则会变成 cp65001(UTF-8). 当初为了标准化各种字符集名称才使用系统内的代码页进行编号, 但 Unicode 出现后还是继续用代码页, 于是出现了这种盛况:PS C:\Users\CXPLAY> python -c 'import locale; print(locale.getpreferredencoding()); import sys; print(sys.getdefaultencoding())'
cp65001
utf-8
系统首选的编码是
cp65001, Python 解释器默认编码是 utf-8, 所以说 cp65001 等于 UTF-8, 又不等于 UTF-8?但我也还记得我很久之前在 Windows 10 上开启过这个 UTF-8 支持选项, 但后来不知道为什么又主动去关掉了, 原因已经记不清楚了, 可能等以后踩到坑才会想起来吧.
#note #Windows #Python
via CXPLAY's Memos
关于 URL 的大小写问题
1. W3C 写道: "一般来说, URL 是区分大小写的(机器名除外). 有些 URL 或 URL 的某些部分可能不区分大小写, 但要识别这些 URL 或 URL 的大小写可能并不容易. 用户应始终注意 URL 是区分大小写的." [1]
2. Google 对于搜索引擎索引: 即使不同大小写的 URL 指向完全相同的资源, 它们也始终被搜索引擎认为是完全不同 URL. 即使索引会尝试抓取所有的链接, 但对于指向相同资源的 URL 最终也要需要网站管理员选择保留其中一个, 这个过程被称为 "标准化". 而在 robots.txt 中对路径大小写也是敏感的. [2]
3. RFC 1738 "统一资源定位器(URL)" 写道: "URL 包含正在使用的协议名(scheme), 后跟冒号, 然后是一个字符串(协议具体实现), 其解释取决于协议. 协议名由字符: 小写字母 "a" ~ "z", 数字和字符加号("+"), 句号(".")和连字符("-"). 为提高弹性, 程序解释 URL 时应将协议名中的大写字母等同于使用小写字母(例如: 允许使用 "HTTP" 和 "http")." [3]
4. RFC 4343 "域名系统(DNS)域名系统不区分大小写的说明". [4]
5. RFC 2616 "超文本传输协议(HTTP)" 写道: (URI 比较) 在比较两个 URI 以确定是否匹配时, 客户端应使用区分大小写的 8 比特组逐个比较整个 URI, 但以下情况例外: [5]
● 空端口或未给出的端口等同于该 URI 引用的默认端口;
● 主机名的比较必须区分大小写;
● 协议名称的比较必须区分大小写;
● 空的 abs_path 相当于 "/" 的 abs_path.
———
● ref: Should URL be case sensitive? - Stack Overflow
● Windows 和 macOS 使用不区分大小写的文件系统, Unix/类Unix使用的文件系统区分大小写. (Git is case-sensitive and your filesystem may not be - Weird folder merging on Windows - Scott Hanselman's Blog)
● Netlify 部署站点路径不区分大小写. (My URL paths are forced into lowercase - Support - Netlify Support Forums)
● Cloudflare Page 部署站点路径区分大小写.
● Vercel 部署站点路径区分大小写.
● Amazon S3 进行静态托管时, 引用储存桶名称定位时区分大小写. (Access Denied error when using an S3 static website endpoint | AWS re:Post)
#note
via CXPLAY's Memos
1. W3C 写道: "一般来说, URL 是区分大小写的(机器名除外). 有些 URL 或 URL 的某些部分可能不区分大小写, 但要识别这些 URL 或 URL 的大小写可能并不容易. 用户应始终注意 URL 是区分大小写的." [1]
2. Google 对于搜索引擎索引: 即使不同大小写的 URL 指向完全相同的资源, 它们也始终被搜索引擎认为是完全不同 URL. 即使索引会尝试抓取所有的链接, 但对于指向相同资源的 URL 最终也要需要网站管理员选择保留其中一个, 这个过程被称为 "标准化". 而在 robots.txt 中对路径大小写也是敏感的. [2]
3. RFC 1738 "统一资源定位器(URL)" 写道: "URL 包含正在使用的协议名(scheme), 后跟冒号, 然后是一个字符串(协议具体实现), 其解释取决于协议. 协议名由字符: 小写字母 "a" ~ "z", 数字和字符加号("+"), 句号(".")和连字符("-"). 为提高弹性, 程序解释 URL 时应将协议名中的大写字母等同于使用小写字母(例如: 允许使用 "HTTP" 和 "http")." [3]
4. RFC 4343 "域名系统(DNS)域名系统不区分大小写的说明". [4]
5. RFC 2616 "超文本传输协议(HTTP)" 写道: (URI 比较) 在比较两个 URI 以确定是否匹配时, 客户端应使用区分大小写的 8 比特组逐个比较整个 URI, 但以下情况例外: [5]
● 空端口或未给出的端口等同于该 URI 引用的默认端口;
● 主机名的比较必须区分大小写;
● 协议名称的比较必须区分大小写;
● 空的 abs_path 相当于 "/" 的 abs_path.
———
● ref: Should URL be case sensitive? - Stack Overflow
● Windows 和 macOS 使用不区分大小写的文件系统, Unix/类Unix使用的文件系统区分大小写. (Git is case-sensitive and your filesystem may not be - Weird folder merging on Windows - Scott Hanselman's Blog)
● Netlify 部署站点路径不区分大小写. (My URL paths are forced into lowercase - Support - Netlify Support Forums)
● Cloudflare Page 部署站点路径区分大小写.
● Vercel 部署站点路径区分大小写.
● Amazon S3 进行静态托管时, 引用储存桶名称定位时区分大小写. (Access Denied error when using an S3 static website endpoint | AWS re:Post)
#note
via CXPLAY's Memos
----------------------
当人与人之间的信任崩塌后, 最后只能靠计算机重新构建信任网络.
----------------------
不知道什么时候开始, 大多数人下意识认为 HTTPS 就等于 "可信", 可能是浏览器的那个上锁的图标, 也可能是各种软件里面喜欢用 "可信" 等同于 "加密", 不过那时也不会有人愿意解释也不会有人听为什么 SSL 证书只能做到加密. 到了 HTTPS 在攻击, 防御和渗透中成为常客, 普通用户也经常被 HTTPS 网站钓鱼攻击的时刻, 越来越多人意识到即使 "信任" HTTPS 代表的加密应该被理解为对中心化 CA 机构的信任, 但这种责任转嫁很显然这些证书机构也不想承担, 毕竟他们也在审计这块大费周章也没有改变什么, 这样只会让 SSL 证书的价格越来越高, 诞生越来越高等级的证书, 比如 OV 和 EV 证书, 那么这些 OV 和 EV 证书就能代表 "可信" 吗? 对用户来说, 信任一家商业公司都已经变得越来越困难, 更不用说要在 OV 和 EV 证书里还要信任 n+1 的机构数量.
即使说过 SSL 证书不代表信任只代表传输加密, 宣传工作也进行了很多年, Google 也决定在 Chrome 里把那把用户首先看到的锁换成别的或是藏在二级页面. 但没有什么效果, 因为对 HTTPS 的信任危机已经演变成了对中心化的信任危机, 证书不仅要依赖中心化机构签发, 还要被操作系统 "默认" 信任. 于是连带着对域名系统的不信任的 DNSSEC 后, 对 SSL 证书不信任的 DANE 也出现了. 它们俩代表着人们发现问题并提出解决办法的行动力, 但太早期了, 先进的理念还要被市场验证, 这可能要花很长时间. #note
via CXPLAY's Memos
当人与人之间的信任崩塌后, 最后只能靠计算机重新构建信任网络.
----------------------
不知道什么时候开始, 大多数人下意识认为 HTTPS 就等于 "可信", 可能是浏览器的那个上锁的图标, 也可能是各种软件里面喜欢用 "可信" 等同于 "加密", 不过那时也不会有人愿意解释也不会有人听为什么 SSL 证书只能做到加密. 到了 HTTPS 在攻击, 防御和渗透中成为常客, 普通用户也经常被 HTTPS 网站钓鱼攻击的时刻, 越来越多人意识到即使 "信任" HTTPS 代表的加密应该被理解为对中心化 CA 机构的信任, 但这种责任转嫁很显然这些证书机构也不想承担, 毕竟他们也在审计这块大费周章也没有改变什么, 这样只会让 SSL 证书的价格越来越高, 诞生越来越高等级的证书, 比如 OV 和 EV 证书, 那么这些 OV 和 EV 证书就能代表 "可信" 吗? 对用户来说, 信任一家商业公司都已经变得越来越困难, 更不用说要在 OV 和 EV 证书里还要信任 n+1 的机构数量.
即使说过 SSL 证书不代表信任只代表传输加密, 宣传工作也进行了很多年, Google 也决定在 Chrome 里把那把用户首先看到的锁换成别的或是藏在二级页面. 但没有什么效果, 因为对 HTTPS 的信任危机已经演变成了对中心化的信任危机, 证书不仅要依赖中心化机构签发, 还要被操作系统 "默认" 信任. 于是连带着对域名系统的不信任的 DNSSEC 后, 对 SSL 证书不信任的 DANE 也出现了. 它们俩代表着人们发现问题并提出解决办法的行动力, 但太早期了, 先进的理念还要被市场验证, 这可能要花很长时间. #note
via CXPLAY's Memos
很多人都推荐给笔记本上一个支架用来提升散热效果, 但是大多数的支架并不是水平抬升笔记本, 而是带有一个斜角. 这就造成了一个问题: 笔记本内部在运动的部件, 比如风扇和机械硬盘, 这些部件的旋转速度满载工作很轻松地就能突破上千 RPM, 高速旋转的部件需要保持动平衡就会和本身运动部件产生的重力相互作用, 斜角放置会加剧影响产生更多的震动, 甚至会损坏轴承和外围部件(如机械硬盘的磁头和盘片).
笔记本风扇的这种问题和机械硬盘是一样的, 要么竖直要么水平, 在一定范围内的斜角造成的震动也许会一点问题都没有, 也许就会突然出现问题, 人根本来不及反应制止损失.
#note
via CXPLAY's Memos
笔记本风扇的这种问题和机械硬盘是一样的, 要么竖直要么水平, 在一定范围内的斜角造成的震动也许会一点问题都没有, 也许就会突然出现问题, 人根本来不及反应制止损失.
#note
via CXPLAY's Memos
保持理智和正常思维的几个必要生理条件:
● 48 小时内没有摄入酒精或其他麻醉和精神类药物.
● 24 小时内摄入充足的食物和水.
● 24 小时内至少有 1 个小时或以上的深度睡眠时间.
体质和环境对条件的影响很大, 以上结论仅供个人参考.
#note
via CXPLAY's Memos
● 48 小时内没有摄入酒精或其他麻醉和精神类药物.
● 24 小时内摄入充足的食物和水.
● 24 小时内至少有 1 个小时或以上的深度睡眠时间.
体质和环境对条件的影响很大, 以上结论仅供个人参考.
#note
via CXPLAY's Memos
社交真的是件非常昂贵的事情，包括在互联网上。
Nostr 现在存在的问题随着用户越来越多逐渐凸显，极致地去中心化带来了低效和数据不一致，最终直接影响了社交本来的目的。它距离和 ActivityPub 一较高下还有很长的距离。
#note #nostr
via CXPLAY's Memos
Nostr 现在存在的问题随着用户越来越多逐渐凸显，极致地去中心化带来了低效和数据不一致，最终直接影响了社交本来的目的。它距离和 ActivityPub 一较高下还有很长的距离。
#note #nostr
via CXPLAY's Memos
计算机领域里 "playground" 似乎没有一个合适的中文译名, 游乐场? 试验场? 操练场? 沙箱? 本身和常用名词的 playground 已经有了差异, 再用相同的译名也有点奇怪.
----------------------
terminology - What does “playground” mean in an informatics educational context? - English Language & Usage Stack Exchange
----------------------
#note
via CXPLAY's Memos
----------------------
terminology - What does “playground” mean in an informatics educational context? - English Language & Usage Stack Exchange
----------------------
#note
via CXPLAY's Memos
给数据抓取加上限制大多并不是为了 "肥水不流外人田", 而是把数据重新放到货架上 "明码标价". 不过很可惜的是, 那些卖货的自己并不生产货物, 而作为生产者的用户也并没有分到一杯羹, 用户也要为这种不公平的 "数据销售" 付出代价 —— 「免费」的代价.
当然, 作为用户本身就有权利将自己的数据作为一种代价支付给商人, 从而换取商人手里的 "面包", 在用自己的数据把自己从用户升级为客户之后, 对应也获得了与商人谈条件的权利, 这份 "面包" 是否值得我的这份数据的价值? 商人也会反过来思考这份数据是否值得换取这份 "面包"?
#note
via CXPLAY's Memos
当然, 作为用户本身就有权利将自己的数据作为一种代价支付给商人, 从而换取商人手里的 "面包", 在用自己的数据把自己从用户升级为客户之后, 对应也获得了与商人谈条件的权利, 这份 "面包" 是否值得我的这份数据的价值? 商人也会反过来思考这份数据是否值得换取这份 "面包"?
#note
via CXPLAY's Memos
有一个关于音乐串流的灵车想法：
把远程机器播放器输出用 obs 推流到哔哩哔哩，然后再用组网工具把远程机器播放器上的遥控器端口映射出来。土制音乐流媒体完成！
#music #note
via CXPLAY's Memos
把远程机器播放器输出用 obs 推流到哔哩哔哩，然后再用组网工具把远程机器播放器上的遥控器端口映射出来。土制音乐流媒体完成！
#music #note
via CXPLAY's Memos
如果服务的客户不是用户, 那这个服务很可能就是在用爱发电; 如果用户没办法成为客户, 服务的托管商原则上就不会对用户负责, 反之这类服务商提供服务吸引来的真正客户大部分会是广告主和赞助商, 交易的「货物」就成了用户数据和隐私. 能够逆转这种利益关系的只有非营利服务(公益或自托管).
#note
via CXPLAY's Memos
#note
via CXPLAY's Memos
#原神 #note
via CXPLAY's Memos
# 互联网服务常见名词和名词缩写
- TOS / ToS / T&C: Terms of service, 服务条款. 也用做 "使用条款(ToU)".
> 服务提供方向客户交付服务时使用的协议, 客户必须同意这类协议才能使用, 这份协议有时还包括免责条款和隐私协议.
- Disclaimer: 免责声明.
> 用于免除服务提供方的部分责任, 通常包括服务水平责任和法律责任.
- Privacy Policy: 隐私政策
> 服务提供方披露的用户数据收集, 存储, 使用, 发布和共享的方法和策略, 用户数据通常包括用户个人身份信息, 用户生成的数据和终端设备信息等. 相对于 ToS, 隐私政策的条款更加明确, 也与大部分国家地区的法律直接挂钩, 针对不同国家地区实行的不同策略实际都是在法律上对公民信息处理规定的适应, 比如欧盟 GDPR(欧盟通用数据保护条例)和美国加利福尼亚州的 CalOPPA(加州网络隐私保护法) 以及 COPPA(加州儿童网络隐私保护法).
- EULA: 最终用户许可协议, End User License Agreement.
> 供应商和最终用户(End-User)之间的服务使用协议, 开发商通过供应商(发行商, 中介等)提供给用户, EULA 规定了服务提供时供应商, 开发商和用户的责任分配和相互责任关系. 这一般规定了用户不能将服务或软件应用于某种目的和领域, 比如使用软件或服务进行违法犯罪和对软件和服务进行逆向工程及再分发, 有的 EULA 还规定了用户违反协议时进行法律纠纷的途径甚至场地, 一般用于消除用户使用造成的法律层面影响, 从而保护开发商和供应商.
- End-User: 最终用户.
> 使用软件和服务的最终一级用户, 用于区分相对开发商依旧处于用户层面的软件和服务系统的系统管理员, 开发人员和维护人员. 最终用户并不具备产品设计和技术能力, 他们在交付流程中只 "负责" 使用服务, 并不会也不需要去理解产品开发设计甚至底层原理, 这通常和用户的技术水平有关, 在某些产品中对拥有一定技术水平的用户会增添 "高级" 功能或配置选项, 针对不同的用户给出不同的支持级别的支持和使用文档. 一个典型的例子: 软件开发商开发了一套金融信息系统交付给商业银行公司, 商业银行培训职员使用这套信息系统, 在这个例子中, 银行公司只是软件开发商的客户, 而使用这套软件的银行职员才是最终用户.
- AUP: 可接受的使用政策, Acceptable Usage Policy, 有时也作合理使用政策(Fair Use Policy, FUP)使用.
> 主要用于在 "无限(Unlimited)" 的服务使用保证上附加的服务终止政策, 避免不合理的用户使用造成影响, 使得整体服务系统无法对其他用户提供服务, 通常会和 EULA 结合使用. "无限制" 的服务使用是在服务商能够保证整体服务质量的前提下做出的保证, 因此又需要一个 AUP 或 FUP 来保护服务提供商和其他用户的权利.
- SLA: Service Level Agreement, 服务级别协议.
> 服务提供方向客户提供服务时保证执行的服务质量(QoS), 服务可用性和责任协议. 通常定义了不同级别的 MTBF(平均故障时间, Mean time between failures), MTTR(平均修复时间, 平均恢复时间, Mean time to repair)等, 以及达成 SLA 的 SLO 标准, 规定了造成 SLA 降级时的责任分配.
- SLO: Service Level Objective, 服务级别目标.
> 可被定量衡量的服务质量(QoS)特征, 用于构成 SLA 的标准评定规则, 避免甲乙方由于对服务级别目标标准不一而引起的纠纷.
- OLA: Operational Level Agreement, 操作级别协议.
> 服务提供者内部各层级服务小组之间的责任协定, 用于明确各服务部门支持关系的描述. 用于组织内部协作达成 OLA 后交付 SLA.
- SOA: 面向服务的架构, Service Oriented Architecture.
> 一种软件架构设计风格, 将一整套服务分解为三层: 服务提供商, 服务代理商, 服务消费者, 是现代云计算的核心理念. 对于消费者来说, 这种架构下的服务往往无法探知内部结构(原则设计上就要求消费者不需要了解运作过程), 无法得知其中存在有多少层级的和数量的代理商和服务商, 这类服务对消费者而言是一个黑盒. 对于服务提供者来说, 这类设计理念从小至微服务架构到规模化 SOA 都能轻松应对市场需求, 各个服务间使用通用的互联网标准或行业标准进行通信, 按照各自的服务条款履行各自的职责, 使得各构件都能做到极细的粒度, 实现轻易相互组合和复用.
- QoS: Quality of Service, 服务质量.
> 对服务整体水平的描述, 特别是客户一方能够得到的服务水平. 在不同的领域有不同的对客户侧衡量标准, 依赖于其他服务的服务往往会首先要求依赖服务的 QoS 来达成自身 QoS, 比如网络通讯服务要求基础网络连通性. 在整体资源有限的情况下, 需要应用各种技术来解决资源分配的问题, 比如 ISP(互联网服务提供商) 对客户提供的互联网接入服务. 这种定义对于尽力而为型交付(Best-Effort)不适用.
- Best-Effort: Best-effort delivery, 尽力而为型交付.
> 一种网络服务交付方式, 这种网络服务不保证任何数据成功交付从而满足 QoS, 对所有客户都适用. 这种服务往往不会专门为客户或客户群分配服务资源, 对客户而言, 当前的服务质量受制于当前服务提供者的服务系统负载和容量. 简而言之, 这类服务就是的在交付时不实行 QoS 的服务.
- Service Assurance: 服务保障.
> 服务提供者通过一定技术来确保达成目标 QoS 的策略和流程, 通常用来确保客户体验(Customer Experience, CX).
- LTS: Long Term Support, 长期支持.
> 一种软件生命周期管理中的特殊软件版本, 发行这类版本的软件意味着这个版本的软件特性(Feature)已经冻结, 在支持有效期内将只会针对软件漏洞, 错误和保证现有功能而进行补丁更新. 如果发行的补丁会造成软件生命周期回归(因带入新特性打破了特性冻结), 那么一般会选择发布子版本(小数点版本, Point Release, Dot Release), 服务版本(Service Pack, SP)或维护版本(Maintenance Pack, MP). 长期支持并不一定包含技术支持(Technical Support). #note
via CXPLAY's Memos
- TOS / ToS / T&C: Terms of service, 服务条款. 也用做 "使用条款(ToU)".
> 服务提供方向客户交付服务时使用的协议, 客户必须同意这类协议才能使用, 这份协议有时还包括免责条款和隐私协议.
- Disclaimer: 免责声明.
> 用于免除服务提供方的部分责任, 通常包括服务水平责任和法律责任.
- Privacy Policy: 隐私政策
> 服务提供方披露的用户数据收集, 存储, 使用, 发布和共享的方法和策略, 用户数据通常包括用户个人身份信息, 用户生成的数据和终端设备信息等. 相对于 ToS, 隐私政策的条款更加明确, 也与大部分国家地区的法律直接挂钩, 针对不同国家地区实行的不同策略实际都是在法律上对公民信息处理规定的适应, 比如欧盟 GDPR(欧盟通用数据保护条例)和美国加利福尼亚州的 CalOPPA(加州网络隐私保护法) 以及 COPPA(加州儿童网络隐私保护法).
- EULA: 最终用户许可协议, End User License Agreement.
> 供应商和最终用户(End-User)之间的服务使用协议, 开发商通过供应商(发行商, 中介等)提供给用户, EULA 规定了服务提供时供应商, 开发商和用户的责任分配和相互责任关系. 这一般规定了用户不能将服务或软件应用于某种目的和领域, 比如使用软件或服务进行违法犯罪和对软件和服务进行逆向工程及再分发, 有的 EULA 还规定了用户违反协议时进行法律纠纷的途径甚至场地, 一般用于消除用户使用造成的法律层面影响, 从而保护开发商和供应商.
- End-User: 最终用户.
> 使用软件和服务的最终一级用户, 用于区分相对开发商依旧处于用户层面的软件和服务系统的系统管理员, 开发人员和维护人员. 最终用户并不具备产品设计和技术能力, 他们在交付流程中只 "负责" 使用服务, 并不会也不需要去理解产品开发设计甚至底层原理, 这通常和用户的技术水平有关, 在某些产品中对拥有一定技术水平的用户会增添 "高级" 功能或配置选项, 针对不同的用户给出不同的支持级别的支持和使用文档. 一个典型的例子: 软件开发商开发了一套金融信息系统交付给商业银行公司, 商业银行培训职员使用这套信息系统, 在这个例子中, 银行公司只是软件开发商的客户, 而使用这套软件的银行职员才是最终用户.
- AUP: 可接受的使用政策, Acceptable Usage Policy, 有时也作合理使用政策(Fair Use Policy, FUP)使用.
> 主要用于在 "无限(Unlimited)" 的服务使用保证上附加的服务终止政策, 避免不合理的用户使用造成影响, 使得整体服务系统无法对其他用户提供服务, 通常会和 EULA 结合使用. "无限制" 的服务使用是在服务商能够保证整体服务质量的前提下做出的保证, 因此又需要一个 AUP 或 FUP 来保护服务提供商和其他用户的权利.
- SLA: Service Level Agreement, 服务级别协议.
> 服务提供方向客户提供服务时保证执行的服务质量(QoS), 服务可用性和责任协议. 通常定义了不同级别的 MTBF(平均故障时间, Mean time between failures), MTTR(平均修复时间, 平均恢复时间, Mean time to repair)等, 以及达成 SLA 的 SLO 标准, 规定了造成 SLA 降级时的责任分配.
- SLO: Service Level Objective, 服务级别目标.
> 可被定量衡量的服务质量(QoS)特征, 用于构成 SLA 的标准评定规则, 避免甲乙方由于对服务级别目标标准不一而引起的纠纷.
- OLA: Operational Level Agreement, 操作级别协议.
> 服务提供者内部各层级服务小组之间的责任协定, 用于明确各服务部门支持关系的描述. 用于组织内部协作达成 OLA 后交付 SLA.
- SOA: 面向服务的架构, Service Oriented Architecture.
> 一种软件架构设计风格, 将一整套服务分解为三层: 服务提供商, 服务代理商, 服务消费者, 是现代云计算的核心理念. 对于消费者来说, 这种架构下的服务往往无法探知内部结构(原则设计上就要求消费者不需要了解运作过程), 无法得知其中存在有多少层级的和数量的代理商和服务商, 这类服务对消费者而言是一个黑盒. 对于服务提供者来说, 这类设计理念从小至微服务架构到规模化 SOA 都能轻松应对市场需求, 各个服务间使用通用的互联网标准或行业标准进行通信, 按照各自的服务条款履行各自的职责, 使得各构件都能做到极细的粒度, 实现轻易相互组合和复用.
- QoS: Quality of Service, 服务质量.
> 对服务整体水平的描述, 特别是客户一方能够得到的服务水平. 在不同的领域有不同的对客户侧衡量标准, 依赖于其他服务的服务往往会首先要求依赖服务的 QoS 来达成自身 QoS, 比如网络通讯服务要求基础网络连通性. 在整体资源有限的情况下, 需要应用各种技术来解决资源分配的问题, 比如 ISP(互联网服务提供商) 对客户提供的互联网接入服务. 这种定义对于尽力而为型交付(Best-Effort)不适用.
- Best-Effort: Best-effort delivery, 尽力而为型交付.
> 一种网络服务交付方式, 这种网络服务不保证任何数据成功交付从而满足 QoS, 对所有客户都适用. 这种服务往往不会专门为客户或客户群分配服务资源, 对客户而言, 当前的服务质量受制于当前服务提供者的服务系统负载和容量. 简而言之, 这类服务就是的在交付时不实行 QoS 的服务.
- Service Assurance: 服务保障.
> 服务提供者通过一定技术来确保达成目标 QoS 的策略和流程, 通常用来确保客户体验(Customer Experience, CX).
- LTS: Long Term Support, 长期支持.
> 一种软件生命周期管理中的特殊软件版本, 发行这类版本的软件意味着这个版本的软件特性(Feature)已经冻结, 在支持有效期内将只会针对软件漏洞, 错误和保证现有功能而进行补丁更新. 如果发行的补丁会造成软件生命周期回归(因带入新特性打破了特性冻结), 那么一般会选择发布子版本(小数点版本, Point Release, Dot Release), 服务版本(Service Pack, SP)或维护版本(Maintenance Pack, MP). 长期支持并不一定包含技术支持(Technical Support). #note
via CXPLAY's Memos
算是两年来第一次重新开始社交🌚不过也和两年前使用 mastodon 的感受一样: 这地方很热闹, 但好像和我没什么关系, 没有几个人是认识的. 当然 nostr 并不只是为了社交媒体才被设计的, 未来还有很多可能.
欢迎关注我的 nostr 主页: cx.ms/sns #note
欢迎关注我的 nostr 主页: cx.ms/sns #note
cx.ms
CXPLAY on Nostr
Share With You.
互联网中常见的几种通讯方式按照效率和碎片化程度排行的话: 1. 博客(Blog) 2. 电子邮件(Email) 3. 短信(SMS) 4. 社交媒体(SNS) 5. 电话(Tel.) 6. 即时通讯(IM) 越靠后效率越高, 但碎片化的概率也越高. #note
via CXPLAY's Memos
via CXPLAY's Memos
试试 nostr：
Pub:
Relay:
Pub:
npub1gd8e0xfkylc7v8c5a6hkpj4gelwwcy99jt90lqjseqjj2t253s2s6ch58hRelay:
wss://nostr.cx.ms #note