Sure, as long as the logo is clearly recognizable, so we can either use the default icon of the nips repository (which I like) or the term "Nostr" itself (like Google does). But there's no way to avoid font design when using letters as your logo, and almost all companies that use letters as their logo have their own fonts that they use exclusively for their logos, and they retain the copyrights to the fonts as well.
社交就是发表自己的评论. 评论别人, 评论自己, 评论事件, 评论立场, 评论行为, 然后再评论别人的评论.
上个星期日推到了队长的《哪里都是你》, 因为很久日推里面没有出现华语了, 并且这首歌本身也很不错, 于是听完日推后就循环了几遍. 结果之后的一个星期直到现在, 日推里面每天都有华语热榜上出现过的曲子, 让人接受不了的《雪 Distance》和《向云端》都來了, 大量的 Hip-Hop 和民谣, 突然让我有点应付不过来.
队长的《哪里都是你》甚至还有个 2.0 版本, 但个人感觉并没有第一版的好, 就像买辣椒也用券的《起风了》一样, 第一版的中文 cover 其实是最好的, 但是后来还是出了第二版, 个人也感受不到第一版的味道了(好像第一版还下架了).
印证了之前的遇到的问题: 康师傅相同口味的泡面也会随供应地区不同发生口味上的变化.
> https://t.me/cxplayworld/290
主要是 "泡椒牛肉" 口味的泡面, 供应川渝地区的版本酱包含有红油, 其他地区的没有; 川渝版本的泡椒包里的泡椒是整个的辣椒, 其他地区版本的泡椒包里的泡椒是切碎的. 包装方面, 川渝版本的颜色更浅(偏黄绿色), 包装图案上印刷的泡菜坛是瓦罐, 面碗里有明显的红油, 其他地区版本的包装绿色更深, 印刷上的泡菜坛是透明玻璃坛子, 面碗里的汤色较清淡. 但是由于网图的拍摄扫描到显示后出现的色彩问题, 这两种版本光从网图包装颜色上基本难以区分, 主要的包装特征就只有图案上的泡菜坛子和碗里的汤色.
口味上川渝地区的酸辣味非常足, 其他地区版本的甚至还不如藤椒口味, 配料里泡椒的味道更像是剁椒.
另外还有一种自己亲身感到与之类似的是 "酸辣牛肉" 口味, 从川渝地区尝到的味道明显比华东地区的要更辣更酸, 味道和酸辣粉类似. 华东地区吃到的更像油泼辣子口味, 辣味很淡, 只有醋味突出. 但是不敢确定, 网上也没有地方提到这种情况. 包装上不同供应地区的商家给的图也有些差别: "老陈醋" 字样使用的字体, 面碗里的面条形状, 无法排除是新旧包装更替造成的.
第一次遇到这种包装食品的相同口味在不同地区还有很大差别的, 不知道康师傅自己有没有考虑到网购时代买错版本的人的感受(生草).
上一次听说工业化的包装食品成地区特供的还是子弟原切土豆片这种受食品原料供应问题产生的特供. 东北地区原本是中国土豆的主要产区, 但是后来大面积改种了大豆小麦水稻, 土豆转移到了西南. 顺便继续发扬光大了, 如果照常东北种土豆, 那说不好原切土豆片的市场特供地区会是东北呢.
除非每次打开之前都要通过这个弹窗质询, 没有地方设置 csv 的默认数据处理方式.
Excel 总是自作聪明把 csv 数据列的前导零(leading zero)删掉, 还没地方设置 csv 的默认数据读取格式, 打开就是常规数据格式, 还要在保存前切换为文本数据格式, 不然只要用 Excel 保存一下数据列就全坏了.
产品或者项目的运营甚至不需要是其核心人员, 甚至不能是. 如果开发, 生产或者创作要面临不属于职责范围内的事务, 可能要考虑把他们用运营包装或者「隔离」开来. 核心成员的职能在被分解之后就变成了流水线作业, 扁平化和等级制是比较流行的结构. 外部事务还是应该尽量交给无关内部事务的人处理, 那可能就会有开不完的会, 提不完的要点, 写不完的报告. 但是之于协作问题带来的麻烦也都比被外部风险直接侵蚀内部核心的简单得多. 但是衡量风险也不轻松, 很多咨询公司专门有这种「风险管理」的服务.
再看一次, 一点都不羡慕.😎
发现 #原神 的枫丹野外有这种很像木槿的植物, 仔细观察后发现应该和蜀葵更接近. 这两种灌木都原产于中国, 即使现在园艺发展到世界各地都有种植, 但这种植物频繁出现在其他国家文化背景下的游戏场景里还是觉得怪怪的, 特别是野外.
PS: 物 种 入 侵 !
要说现在钛合金材质也会要在大屏移动设备上使用, 用来提供更轻的重量和更高的强度. 但是好像这两点在体积更富余的平板上并不用这种更贵的材料就可以做到.
融合套餐可以借续宽带的钱一起把移动套餐也续了, 现在电信都有续十二个月送一个月的常驻优惠, 折算下来等于九二折话费. 想拉一条联通或者移动的宽带了.
这几天年末归档本地数据改用了 7z, 发现 7z 也支持 ADS 数据流, 不过只能在 WIM(Windows Imaging Format) 归档格式里用, 这是种 Microsoft 开发来专门用作磁盘镜像的文件格式, 类似于 VHD 和 VHDX.
另外尝试了一下 Directory Opus, 发现它默认使用 ADS 数据流为文件保存的描述储存在 SummaryInformation 标签里, 文件夹是 OpusMetaInformation 标签; 具体的数据格式也是专门设计的, 从 Directory Opus 范围之外覆写并不轻松[1][2].
如果文件和文件夹元数据连流行的归档格式都不支持, 甚至限定在某种文件系统里, 某种专有软件里, 那作为解决办法就非常局限且不可靠了.
[1]: Edit the NTFS ADS OpusMetaInformation from the command line? - Help & Support - Directory Opus Resource Centre: https://resource.dopus.com/t/edit-the-ntfs-ads-opusmetainformation-from-the-command-line/41287
[2]: Reading OpusMetaInformation powershell - Help & Support - Directory Opus Resource Centre: https://resource.dopus.com/t/reading-opusmetainformation-powershell/31850
接下可能会尝试使用 Descript.ion, 因为它是个结构简单的纯文本文件, 目前受部分流行的第三方文件管理器支持.
但是它起源于 1989 年的 MS-DOS 时代, 又不是 Microsoft 执行的标准, 发展到现在它的 "标准" 已经变得混乱. 据说他是为了解决 8.3 文件名无法写入更多信息产生的[1]... 真是讽刺.
与之类似的东西还有 BBS 时代的 file_id.diz 和 *.nfo, 当然现在也还有. 常常出现在各种盗版软件的资源包里, 也是用来描述元信息文件, diz 是描述文件和文件夹用途的, nfo 是描述开发者的. 更现代一点, 是 README.md 这种约定俗成的自述文件. 但是这些东西都不是专门用来记录文件和文件夹元信息的(diz 也是种自述文件).
[1]: windows - "descript.ion" file spec? - Stack Overflow: https://stackoverflow.com/questions/1810398/descript-ion-file-spec#comment1699208_1810398
很多文件都有自己的独特元数据扩展, 典型的就是 JPG 图片的 EXIF 信息. 在管理大量文件的时候注意到元数据的重要性, 写给计算机看的元数据是文件头, 是数据包头. 写给人类看的, 规范的文件元数据很少, 应用广泛的除了 EXIF, 还有用在音频文件的 IDv2, IDv3 标签, 视频封装容器格式中用来保存封面的元信息, 电子书的书籍信息, 电子文档里面 Microsoft 给 Excel, Word, PPT 都添加了各种各样的元信息, 一些归档软件还能给 ZIP 添加注释.
对于这类基于文件格式的元信息还是主要看操作这类文件格式的软件的适配, 而更加深入一层的是文件系统的元信息, 比如 NTFS 的备用数据流(Alternate data stream, ADS):
- **NTFS #Alternate data stream (ADS) - Wikipedia**: https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
- [MS-FSCC: NTFS Streams | Microsoft Learn](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c54dec26-1551-4d3a-a0ea-4fa40f848eb3)
应用程序可以直接在文件系统上给文件添加额外的元信息, 目前使用这种原理的软件给文件添加额外信息的软件只发现了一个: Directory Opus. 当然也能自己用 PowerShell 给文件添加和读取备用数据流:
)
- [Streams - Sysinternals | Microsoft Learn](https://learn.microsoft.com/en-us/sysinternals/downloads/streams)
但是说了这么多, 上面提到的元信息都是只针对文件的, 对文件夹的元信息, 就算是 NTFS 的备用数据流也没有办法. 虽然直接用文件夹名称存储元信息是一种直观的办法, 但是限制就会变得很多, 比如特殊字符, 来自操作系统的路径长度限制, 来自归档文件格式算法的路径长度限制([tar 限制 255 个字符](https://www.gnu.org/software/tar/manual/html_section/Formats.html)), 来自文件系统的路径长度限制(NTFS 限制 65535 个字符), 如果不选择更好的办法, 用文件夹名称的写元信息就会陷入一个来自方方面面的 "木桶效应". 没有任何文件系统支持给文件夹添加元数据, 或许就只能另辟蹊径了, 比如给文件目录建立索引, 然后在索引里面写元信息, 类似于给文件目录建数据库, 当然最后还要用其他的软件读取数据库和目录建立操作关系, 相当于要重写一个文件管理器软件. 更加简单的索引比如 [Descript.ion](https://zh.wikipedia.org/zh-hans/Descript.ion) 目前还在使用, 被 ACDSee, XnView, Total Commander 还有 7-Zip, 以及上面提到过的 Directory Opus 采用. 这些软件要么本身就是一个文件管理器, 要么就是附带操作文件目录的功能的软件.
文件夹也需要元信息, 但解决办法还没有找到, 或许以后也只能求助于第三方文件管理器了.
这几天年末归档本地数据改用了 7z, 发现 7z 也支持 ADS 数据流, 不过只能在 WIM(Windows Imaging Format) 归档格式里用, 这是种 Microsoft 开发来专门用作磁盘镜像的文件格式, 类似于 VHD 和 VHDX.
另外尝试了一下 Directory Opus, 发现它默认使用 ADS 数据流为文件保存的描述储存在 SummaryInformation 标签里, 文件夹是 OpusMetaInformation 标签; 具体的数据格式也是专门设计的, 从 Directory Opus 范围之外覆写并不轻松[1][2].
如果文件和文件夹元数据连流行的归档格式都不支持, 甚至限定在某种文件系统里, 某种专有软件里, 那作为解决办法就非常局限且不可靠了.
[1]: Edit the NTFS ADS OpusMetaInformation from the command line? - Help & Support - Directory Opus Resource Centre: https://resource.dopus.com/t/edit-the-ntfs-ads-opusmetainformation-from-the-command-line/41287
[2]: Reading OpusMetaInformation powershell - Help & Support - Directory Opus Resource Centre: https://resource.dopus.com/t/reading-opusmetainformation-powershell/31850
搞得我也想用 8.3 文件名了.😅
