#吐槽
In reply to nevent1q…3qvc
_________________________
所以在线表格哪家强? 海外能选的好像就只有 Google Sheet, Excel Online, 飞书国际版. 国内倒是有金山文档, 腾讯文档, 飞书, 石墨文档.
via Nostr@cxplay
In reply to nevent1q…3qvc
_________________________
所以在线表格哪家强? 海外能选的好像就只有 Google Sheet, Excel Online, 飞书国际版. 国内倒是有金山文档, 腾讯文档, 飞书, 石墨文档.
via Nostr@cxplay
CXPLAY (npub1gd…ch58h)
Short Text Note by CXPLAY
seen on relay.westernbtc.com
#吐槽
Notion 的表格太过简单了, 但也不能把 #Notion 的数据库当作表格用, 最多只能叫做一种数据的视图类型, 类似 Windows 资源管理器的详细信息视图的那种, 虽然用函数可以让数据互相引用, 但始终不能突破行列关系, 具体一点就是单元格无法合并.
via Nostr@cxplay
Notion 的表格太过简单了, 但也不能把 #Notion 的数据库当作表格用, 最多只能叫做一种数据的视图类型, 类似 Windows 资源管理器的详细信息视图的那种, 虽然用函数可以让数据互相引用, 但始终不能突破行列关系, 具体一点就是单元格无法合并.
via Nostr@cxplay
CXPLAY (npub1gd…ch58h)
Short Text Note by CXPLAY
seen on relay.westernbtc.com
#article #read
ElasticSearch 和 Kibana 再次变成开源自由软件
2021 年初，开发 Elasticsearch 和 Kibana 的 Elastic 公司宣布更改许可证，新版本将不再使用 Apache 2.0 而是使用 Elastic License 和 Server Side Public License，此举旨在禁止云服务商如 AWS 使用它的软件作为一种服务提供给客户。但许可证的更改也意味着 Elasticsearch 和 Kibana 不再是开源软件了。亚马逊随后宣布创建 ElasticSearch 开源分支 OpenSearch。三年之后，Elastic 再次宣布更改许可证，Elasticsearch 和 Kibana 将采用 Affero GPL 许可证，它们再次成为开源自由软件。
- https://www.elastic.co/blog/elasticsearch-is-open-source-again
- https://www.solidot.org/story?sid=79138
via Nostr@cxplay_clip
ElasticSearch 和 Kibana 再次变成开源自由软件
2021 年初，开发 Elasticsearch 和 Kibana 的 Elastic 公司宣布更改许可证，新版本将不再使用 Apache 2.0 而是使用 Elastic License 和 Server Side Public License，此举旨在禁止云服务商如 AWS 使用它的软件作为一种服务提供给客户。但许可证的更改也意味着 Elasticsearch 和 Kibana 不再是开源软件了。亚马逊随后宣布创建 ElasticSearch 开源分支 OpenSearch。三年之后，Elastic 再次宣布更改许可证，Elasticsearch 和 Kibana 将采用 Affero GPL 许可证，它们再次成为开源自由软件。
- https://www.elastic.co/blog/elasticsearch-is-open-source-again
- https://www.solidot.org/story?sid=79138
via Nostr@cxplay_clip
Elastic Blog
Elasticsearch Is Open Source. Again!
Elastic announces the return of open source licensing for Elasticsearch and Kibana, adding AGPL as an option alongside existing licenses. This change reinforces our long-standing commitment to open source principles and the open source community.
#吐槽
#Cryptomator 自 2017 年开始就在重构他们的 Android 客户端, 期间甚至还开发了 Cryptomator Hub 用于给加密库提供 SSO 身份管理和加密库解密. 所以到现在 Android 客户端还只是凑合能用的级别, 还不支持 Documents Provider 这种非常重要的特性(约等于挂载点功能).
> https://github.com/cryptomator/android/issues/35
这个 issue 的讨论还因为 "too heated" 被关闭了, 笑死. 在他们完成重构并给 Android 支持 Documents Provider 特性之前我估计不会考虑付费支持了.
via Nostr@cxplay
#Cryptomator 自 2017 年开始就在重构他们的 Android 客户端, 期间甚至还开发了 Cryptomator Hub 用于给加密库提供 SSO 身份管理和加密库解密. 所以到现在 Android 客户端还只是凑合能用的级别, 还不支持 Documents Provider 这种非常重要的特性(约等于挂载点功能).
> https://github.com/cryptomator/android/issues/35
这个 issue 的讨论还因为 "too heated" 被关闭了, 笑死. 在他们完成重构并给 Android 支持 Documents Provider 特性之前我估计不会考虑付费支持了.
via Nostr@cxplay
#吐槽
Hollowheart 本来应该在《Worlds》专辑中一起发行, 但由于提交地太晚没能进入专辑.
直到《Worlds》发行六年后这首歌才开始被公开讨论, 最终在《Worlds》十周年纪念日(2024 年 8 月 12 日)正式被发行.
https://www.youtube.com/watch?v=bdXPhRj10jQ
#PorterRobinson #music
via Nostr@cxplay
Hollowheart 本来应该在《Worlds》专辑中一起发行, 但由于提交地太晚没能进入专辑.
直到《Worlds》发行六年后这首歌才开始被公开讨论, 最终在《Worlds》十周年纪念日(2024 年 8 月 12 日)正式被发行.
https://www.youtube.com/watch?v=bdXPhRj10jQ
#PorterRobinson #music
via Nostr@cxplay
#吐槽
gocryptfs 和 cppcryptfs 是同一个加密方案的实现, 缺陷是不混淆文件目录结构和文件体积.
另一个专为云备份设计的加密文件系统 CryFS 对比了包括以上两种(实际上一种)以及流行的 TrueCrypt/VeraCrypt, EncFS, eCryptfs 的优缺点:
> https://www.cryfs.org/comparison
但 CryFS 的对比文章里缺少了 #Cryptomator 的对比, 根据自己的使用体验, CryFS 实际上是比 Cryptomator 更先进的一种设计, 支持了更多 Cryptomator 没有的特性, 比如: 保护文件内容免遭恶意修改, 保护文件元数据和文件大小免遭恶意修改, 保护目录结构免遭恶意修改.
这三个特性是以上所有加密文件系统都有的问题, 即只要加密后的目录结构和文件名被篡改, 整个加密库就会损坏, 无法挂载. CryFS 的为了避免这种情况, 会把所有进入加密挂载点的文件切分成 16KiB 大小的分块, 分散保存在加密后的文件系统各处, 可以做到损失部分分块和目录结构也能正常挂载加密库. 不过, 受损分块对应的完整文件是没办法恢复的, 在挂载点中对应的这个文件将会无法被操作(删除, 复制, 移动和读取).
16KiB 这个分块大小是 Linux 常用的 ext4 文件系统的默认格式化「块」(在 Windows/NTFS 叫「簇」)大小的两倍, 可能是权衡了 4KiB 性能和未加密文件最小体积的结果.
Windows 现在为 NTFS 的默认格式化的簇大小是 4KiB, 如果被格式化为了大于 4KiB 以上的簇大小, 那么 NTFS 特性之一的透明压缩功能将会无法在这个磁盘启用.
CryFS 的 16KiB 对于大多数现代的文件系统来说不是问题, 但是对于硬盘来说, 即使是现代的 NVMe SSD 来说, 16KiB 虽然并不能直接对比极限的 4KiB 性能, 但是数量一旦多起来, 跨磁盘备份操作也会非常痛苦, 一个 100MiB 的文件都能被切分为 6400 个块. 虽然 CryFS 通过分块实现了 Cryptomator 没有的功能, 但是代价是加密性能会变得更差.
CryFS 使用 C++ 编写, Cryptomator 使用 Java 编写. 前者支持良好的只有 Linux 和 macOS, Windows 上还存在大量问题, 并且目前只有命令行客户端, 虽然一个叫 SiriKali 的项目使用 QT 给包括 Cryfs 在内的文件系统加密后端适配了一个桌面 GUI, 但这个 GUI 的体验相比后者还有很大欠缺, 在 Android 上目前可以使用 DroidFS 来兼容 CryFS 和 gocryptfs 的使用.
所以目前来说, 仅在 Linux, macOS 和 Android 上, CryFS 才是 Cryptomator 的完全替代品. 但 16KiB 的分块特性可能在某些储存介质和备份方案上并不能称之为有效提升.
via Nostr@cxplay
gocryptfs 和 cppcryptfs 是同一个加密方案的实现, 缺陷是不混淆文件目录结构和文件体积.
另一个专为云备份设计的加密文件系统 CryFS 对比了包括以上两种(实际上一种)以及流行的 TrueCrypt/VeraCrypt, EncFS, eCryptfs 的优缺点:
> https://www.cryfs.org/comparison
但 CryFS 的对比文章里缺少了 #Cryptomator 的对比, 根据自己的使用体验, CryFS 实际上是比 Cryptomator 更先进的一种设计, 支持了更多 Cryptomator 没有的特性, 比如: 保护文件内容免遭恶意修改, 保护文件元数据和文件大小免遭恶意修改, 保护目录结构免遭恶意修改.
这三个特性是以上所有加密文件系统都有的问题, 即只要加密后的目录结构和文件名被篡改, 整个加密库就会损坏, 无法挂载. CryFS 的为了避免这种情况, 会把所有进入加密挂载点的文件切分成 16KiB 大小的分块, 分散保存在加密后的文件系统各处, 可以做到损失部分分块和目录结构也能正常挂载加密库. 不过, 受损分块对应的完整文件是没办法恢复的, 在挂载点中对应的这个文件将会无法被操作(删除, 复制, 移动和读取).
16KiB 这个分块大小是 Linux 常用的 ext4 文件系统的默认格式化「块」(在 Windows/NTFS 叫「簇」)大小的两倍, 可能是权衡了 4KiB 性能和未加密文件最小体积的结果.
Windows 现在为 NTFS 的默认格式化的簇大小是 4KiB, 如果被格式化为了大于 4KiB 以上的簇大小, 那么 NTFS 特性之一的透明压缩功能将会无法在这个磁盘启用.
CryFS 的 16KiB 对于大多数现代的文件系统来说不是问题, 但是对于硬盘来说, 即使是现代的 NVMe SSD 来说, 16KiB 虽然并不能直接对比极限的 4KiB 性能, 但是数量一旦多起来, 跨磁盘备份操作也会非常痛苦, 一个 100MiB 的文件都能被切分为 6400 个块. 虽然 CryFS 通过分块实现了 Cryptomator 没有的功能, 但是代价是加密性能会变得更差.
CryFS 使用 C++ 编写, Cryptomator 使用 Java 编写. 前者支持良好的只有 Linux 和 macOS, Windows 上还存在大量问题, 并且目前只有命令行客户端, 虽然一个叫 SiriKali 的项目使用 QT 给包括 Cryfs 在内的文件系统加密后端适配了一个桌面 GUI, 但这个 GUI 的体验相比后者还有很大欠缺, 在 Android 上目前可以使用 DroidFS 来兼容 CryFS 和 gocryptfs 的使用.
所以目前来说, 仅在 Linux, macOS 和 Android 上, CryFS 才是 Cryptomator 的完全替代品. 但 16KiB 的分块特性可能在某些储存介质和备份方案上并不能称之为有效提升.
via Nostr@cxplay
一些文件系统加密软件, #Cryptomator 的替代品.
● gocryptfs: https://github.com/rfjakob/gocryptfs
● cppcryptfs: https://github.com/bailey27/cppcryptfs
● eCryptfs: https://www.ecryptfs.org/
#Software #encryption #opensource
via CXPLAY's Memos
● gocryptfs: https://github.com/rfjakob/gocryptfs
● cppcryptfs: https://github.com/bailey27/cppcryptfs
● eCryptfs: https://www.ecryptfs.org/
#Software #encryption #opensource
via CXPLAY's Memos
> https://t.me/cxplayworld/1417
现在一些 Android 客户端也带有这个提高图片压缩上限的特性了. 可以有效避免 Telegram 把一部分图片压成💩.
#Telegram
via Nostr@cxplay
#吐槽
In reply to nevent1q…3c76
_________________________
FreeFileSync 应该只能算个同步软件, 一个「好的备份软件」并不只是把文件从一个位置复制到另一个位置, 于是这么多备份软件搞得选择繁杂, 坑也被埋得很深, 甚至能看到有人在备份软件的讨论底下直接推荐换文件系统(ZFS)的.
via Nostr@cxplay
In reply to nevent1q…3c76
_________________________
FreeFileSync 应该只能算个同步软件, 一个「好的备份软件」并不只是把文件从一个位置复制到另一个位置, 于是这么多备份软件搞得选择繁杂, 坑也被埋得很深, 甚至能看到有人在备份软件的讨论底下直接推荐换文件系统(ZFS)的.
via Nostr@cxplay
CXPLAY (npub1gd…ch58h)
Short Text Note by CXPLAY
seen on relay.damus.io, us.nostr.wine
#吐槽
选择你的备份软件: Arq Backup, Bacula, Bareos Relica, Borg, Borg backup, BorgBase, Borgmatic, Borgtui, Bupstash, Duplicati, Duplicay, Duplicity, FreeFileSync, Kopia, NPBackup, Restic, rustic, Syncovery, Veeam, Vorta
via Nostr@cxplay
选择你的备份软件: Arq Backup, Bacula, Bareos Relica, Borg, Borg backup, BorgBase, Borgmatic, Borgtui, Bupstash, Duplicati, Duplicay, Duplicity, FreeFileSync, Kopia, NPBackup, Restic, rustic, Syncovery, Veeam, Vorta
via Nostr@cxplay
CXPLAY (npub1gd…ch58h)
Short Text Note by CXPLAY
seen on relay.damus.io
#吐槽
In reply to nevent1q…3zfu
_________________________
今天问题再次复现了, 由于这次前后重启间隔中的操作很少, 所以很轻松查到了原因:
#123云盘 的「123同步空间」功能资源管理器注入(Copy Hook Handler, ShellExecute Hook)与 Directory Opus 12 的资源管理器注入功能发生了冲突. 禁用123云盘的注入保留 Opus 的注入之后恢复正常, 但反过来禁用 Opus 的注入保留123云盘的注入还是照常崩溃.
via Nostr@cxplay
In reply to nevent1q…3zfu
_________________________
今天问题再次复现了, 由于这次前后重启间隔中的操作很少, 所以很轻松查到了原因:
#123云盘 的「123同步空间」功能资源管理器注入(Copy Hook Handler, ShellExecute Hook)与 Directory Opus 12 的资源管理器注入功能发生了冲突. 禁用123云盘的注入保留 Opus 的注入之后恢复正常, 但反过来禁用 Opus 的注入保留123云盘的注入还是照常崩溃.
via Nostr@cxplay
#吐槽
In reply to nevent1q…0cxg
_________________________
确实, 国内仅有的几家都限制的死死的. 阿里云盘的内测 WebDAV 限制成了 5 QPS 还只能读取文件无法操作文件.
> https://www.yuque.com/aliyundrive/zpfszx/hodc0n2t9cfy9ho7#Ofu6H
via Nostr@cxplay
In reply to nevent1q…0cxg
_________________________
确实, 国内仅有的几家都限制的死死的. 阿里云盘的内测 WebDAV 限制成了 5 QPS 还只能读取文件无法操作文件.
> https://www.yuque.com/aliyundrive/zpfszx/hodc0n2t9cfy9ho7#Ofu6H
via Nostr@cxplay
DASHU (npub19y…azqwk)
Short Text Note by DASHU (reply)
seen on relay.momostr.pink, relay.noswhere.com
#吐槽
In reply to nevent1q…z407
_________________________
You're right.
via Nostr@cxplay
In reply to nevent1q…z407
_________________________
You're right.
via Nostr@cxplay
Yonle (npub1x3…3g4el)
Short Text Note by Yonle (reply)
seen on relay.momostr.pink, relay.noswhere.com
