登录 注册

关于思源笔记的一些看法

本贴最后更新于 621 天前，其中的信息可能已经东海扬尘

之前在思源三群发了个消息：

思源写作体验非常棒，算得上 PC 上 MD 笔记的写作体验的领头羊，唯一遗憾的默认存储格式不是.md，限制了玩法和使用场景，否则应该可以封神了。

然后有了如下对话：

萌新的化身[2] 2022/8/8 12:05:20
因果关系搞反了，就是因为打破了 md 的限制才有现在的思源

鸢尾 2022/8/8 12:44:28
果真 .md 格式总是成为大家对思源放不下心的原因

鸢尾 2022/8/8 12:45:17
军师 急需您写一条为什么思源不是.md 的说明

Evil Eyes 2022/8/8 12:46:59
“notion 也不是 md，有本事你去 notion 群里说啊”

Evil Eyes 2022/8/8 12:47:43
再回来的时候已经被骂得不成人形了

是 Dammy 不是 D 大 2022/8/8 12:48:34
MD 问题 D 大熟，我去翻翻 D 大语录看记下了吗，理解老深刻了

是 Dammy 不是 D 大 2022/8/8 12:50:07
坏了我没记

鸢尾 2022/8/8 12:55:05
D 大发的那个我也有点印象

有说大佬曾在群里深刻剖析过为啥不存储 md 的原因。但我进群的晚，没看到大佬的理解。不过呢，感觉对话中的两个理由都比较牵强。

首先我知道思源数据结构是基于内容块的，很多功能和复杂查询与数据关联都是基于这种特有的设计实现的，它就像一个数据库，甚至可以用类似 SQL 的语法进行查询，这种设计思路不错，不过这与最终是否存储为 MD 格式文件没有啥必然联系，因为保存现有格式的元数据与同时再生成一份 MD 文档并没有冲突，而且对直接存储 md 格式不放心的人毕竟是少数，没有啥放不放心，不行的话难道不能对是否存储 md 格式文档设置为用户可选项？

其次我个人认为思源现有的用户增量主要基于写作体验、开源、跨平台、官方同步等方面的原因，这些方面思源除了在移动端的的体验比较糟糕外其他都不错，所以用户的增长几乎是水到渠成的。但这个增速实话说却不是它应有的增速。还有大批人并不知道思源，不知道的原因除开官方推广外主要还是在于用户并没太大的主动意愿去做口碑传播，有些人知道，但用了不久又换其他笔记了，比如 ob。

刚开始我在一些平台回答笔记类的问答时也会推荐一下思源，但后来没有进行推荐了。主要原因有三：

第一、通常发问的人一般都找过许多笔记应用试用过，他们的需求一般是除写作之外的额外要求，否则 word 已是写作体验的天花板，他们也没必要发问，一些需求比较个性化，思源目前并不支持插件扩展，显然无法满足。

第二、md 笔记本身是些简单的标记格式，虽然简单，但也没到人人都懂的程度，懂得 md 语法，并且需要 md 笔记的人大多喜欢折腾，玩 nas、blog、web dev 的人居多，这些人对数据的敏感性高，同时又对数据的通用性有所要求，md 存储格式是其中一个指标，支持第三方同步也是一个指标。这两点不一定是比较重要的指标，但思源显然都不支持。

第三、推荐给一些人用了一段时间后，用的人最终大多还是没选择押宝思源，原因是多方面的，除了我前面说的那些，最主要的是偶发性的报错，思源版本更新很快，但同时也带来了一些问题，比如测试并不严谨，很多问题等新版发布一段时间后才会收到用户反馈，如果是通用型 BUG，恰好被新手体验到了，有些人会选择提交给官方，但更多的人怕是直接选择不用了。我用思源时也会经常遇到崩溃重建索引的情况，而且是连续几个新版本都存在这种偶发性错误，虽然似乎也没影响到数据，但也不太好跟人介绍了。

除上所述外还有一些其他问题，在此不一一列举。总之，思源有它独特的优势，第一眼就觉得惊艳，第二眼还是喜欢，但就目前而言尚未成熟，我知道思源是因为 Vditor，如果不是它，我可能至今也不晓得思源。这本身就是问题。

期待几年后的思源能够建立真正的 md 笔记生态，适用更多的场景，特别是深层次的插件支持，很多功能官方可以说一万个不做的理由，但对于需求者来说，只需要一个理由，扩展插件的意义就在于：你不做，我做。
我会随时关注，期待它超越 ob 的时候！

  • 思源笔记

    思源笔记是一款隐私优先的个人知识管理系统，支持完全离线使用，同时也支持端到端加密同步。

    融合块、大纲和双向链接，重构你的思维。

    18614 引用 • 69259 回帖
3 引用
关于思源笔记的一些看法 • Bard
关于思源笔记的一些看法 • Bard
关于思源笔记的一些看法 • Bard
成都 位置
1 感谢
2 收藏
1 赞同
3 引用
20 回帖
14
3
1.9k 296 278 311 6 44 913

相关帖子

20 回帖
关于思源笔记的一些看法

欢迎来到这里！

我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。

注册 关于
请输入回帖内容 ...
  • GuangDai • • 1 评论
    订阅者

    md 真的太弱了，之前我就和我的同学讨论过 markdown 的缺陷。。。。

    首先 siyuan 是开源的，只要你 Fork 一下，这个项目你就相当于永久保存了，哪怕 D 大和 V 大删了都不会影响你。你同步也可以同步到 github 等等其他地方，你随便访问你保存的目录，没有人会干扰你的自由。

    其次 Siyuan 的存储本身也是一个代码文本，不是 APP、Word 那种结构化的东西，只不过 MD 的结构复杂度远低于 Siyuan 的复杂度，导致 Siyuan 的纯文件阅读会非常困难。

    与其说 Siyuan 为什么不支持这样的纯 md，更不如说，md 本身的贫瘠功能并不足以支持 siyuan 的发展。在最早的 Siyuan 是用 MD 保存的，但后来验证很难支撑起这样一个结构化的。因为 MD 的设计初衷就是类似于一个记录的文本，是一维度、线性的。

    如果老哥写代码非常多，就知道只在编辑器里面写代码，而没有注释、代码的跳转什么的功能，就是给自己找罪受，因为这里用到一个 function，那里用到另一个 function 等等。

    要我说与其说是怀念 MD，不如说是怀念 MD 可以直接用键盘简单的进行编辑。这个是 Siyuan 的缺陷，也是那些快捷键虽然多，但记忆和掌握起来相对更复杂的问题

    MD 本身确实不具备复杂应用的特性，但并不意味着需要放弃 MD 格式本身，无论是使用数据库还是 JSON 来存储 MD 源数据都可以实现复杂的应用，唯一要解决的就是与 MD 文件的关联，而不是彻底放弃 MD 格式。MD 是展示层的东西，也可以是源数据的载体，数据库或者 JSON 完全可以作为中转区域来实现各种复杂应用，没必要完全放弃 MD 格式，放弃 MD 格式也就是放弃了整个 MD 生态，以至于它就只是一个笔记，而无法适应更多的应用场景。比如 WEB 文档、移动端更好的写作体验、个人数据统一管理等等。
    shileiye •
  • GuangDai •
    订阅者

    而且可以参考 Latex，那 Latex 可读性真的很好吗？

    现在基本上我认识的科研工作者，都是用 Latex 直接写论文，Word 太臃肿而且不方便，Latex 才是最满足他们需求的东西，即使这个东西有门槛和代码基础要求。

  • GuangDai •
    订阅者

    哦对，再提一嘴什么是开源。

    开源就是这些源码是公布的，有效的，所有人都可以看、下载、修改和编译的，你自己可以在约定的规则下编译、修改和使用的。

    那么之所以 D 大和 V 大哪怕把项目删了，都无所谓，就是代码是完全公开的，这个项目不是像 QQ、WX、Word、WPS 那种私有的，代码完全不公开，这几个公司没了这软件就不能用的。而 Siyuan 你完全可以自己编译，或者用 Github 编译，都是你的自由。你也可以感觉 Siyuan 那里写的不好，不随你的心意，只要 Fork 一下，你就有一份随便你使用的 Siyuan 代码，随便改。

    Siyuan 自带的同步是官方同步，但这个文件夹就在我本地，我随时都可以访问，明文存储，我想备份到哪都可以，我就是直接备份到我的 Github 私有项目。我这两年都来来回回重装十几次系统了，Linux、Windows、MacOS 都用过，Linux 发行版我都用过五六个，要么直接复制粘贴，要么直接 git pull 一下，都没有一点影响 Siyuan。

    所以，支持开源，相信开源。

    1 引用
  • Bard •
    订阅者 捐赠者

    Markdown 主要是用于排版的，承载不了知识管理的重任 - 读 D 宝 语录有感

  • Achuan-2 •
    订阅者 先知

    在扩展语法的道路上越走越远以后，我们发现这似乎是在开历史的倒车。随着更多特定语法的引入，Markdown 的通用性逐步散失，就好像变成了特定软件的私有格式一般。更讽刺的是，语法引入却不能解决 Markdown 最大的问题 —— 自带资源文件（虽然 TextBundle/TextPack 做了一些努力，但就目前而言基本也还是不通用）。

    对于开发者来说，另一条路是一开始就不选择以 Markdown 文本作为存储格式，而是使用更结构化的存储方式，比如数据库或者 JSON，然后在应用层面支持 Markdown 语法排版。选择这条路的开发者，也许已经预见到了将来可能的复杂场景。

    作者：88250
    链接： 纯粹的 Markdown
    来源：链滴
    协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

  • Bard •
    订阅者 捐赠者

    对于 Markdown 的不合适用于知识管理有以下几点

    1. 知识管理需要对一段知识，或者一个块进行唯一标记，但在 Markdown 设计之初就没有这样的需求，所以 ob 在这一块实现的既不优雅，也不够实用，块的定位有问题
    2. Markdown 文件无法保证文件的唯一写入，这就会造成文件损坏，权限异常等无法解决的问题，解决的办法只用思源通过 api 才能对文件保证“事务性”的操作
    1 回复
  • shileiye •
    作者

    首先，这种设计是没问题的，为了支持复杂的应用场景，纯 MD 格式肯定是很难的，但哪怕是用到再复杂的数据结构，甚至直接用数据库也不妨碍同时生成一份 MD 文档，以及反解析 MD 文档为特定数据结构，如果是为了满足知识管理、块管理等，关联特定数据结构即可，没必要彻底放弃 MD 存储格式。

    其次，所谓的唯一写入其实是伪需求，目的只是为了防止内容冲突不好合并，但如果笔记有协作需求，那思源目前来讲绝不是一个好的解决方案，除协作需求外可能产生写入冲突的地方应该是在第三方同步和其他软件直接修改 MD 文档上对吧？

    这涉及到以特定数据结构为主数据还是 MD 文档本身为主数据的问题，用特定结构数据的话自然可以更加方便的管理数据，第三方软件对 MD 文件的写入对主数据并无影响，也就是说思源打开这个 MD 文档还是会恢复为主数据库存储的数据，但这显然有些违反直觉。因此以 MD 文档为主，特定结构数据为辅未尝不可。

    结构数据的生成由 MD 决定，本身思源目前的原理也是这样，扫描 MD 文档的改动并重新建立结构数据用于各种辅助功能和查询，MD 文档作为主要数据生成的载体是可行的，因此不存在说无法实现思源目前的功能以及数据结构的问题，因为 MD 文档的普适性，决定了它的应用场景不仅仅是笔记，它是一个生态，比如市面上基于 MD 文档的各类管理系统，其数据源文件就是 MD 格式，比如在移动端一些写作体验较好的应用源文件格式也是 MD，在思源移动端体验依旧跟不上的情况下，使用第三方 MD 编辑器直接编辑 MD 文件也是最好的选择，另外第三方同步读写 MD 也比被思源锁定的特有格式有优势，唯一要解决的就是版本冲突合并罢了。就像代码协作提交前处理代码冲突，对代码进行合并，这并不是什么难事，这本身就是多端同步协作逻辑上肯定会发生的问题，不应为避免冲突而强制它不冲突，而是在冲突时给个解决方案，无论是强制覆盖，还是内容合并，或者是放弃更改，都应该是交给用户，而不是程序。

    1 回复
  • Bard • • 1 评论
    订阅者 捐赠者

    如果是为了满足知识管理、块管理等，关联特定数据结构即可

    具体如何关联特定数据结构，可以了聊聊大致方案吗，我看这是之前 MD 做知识管理一个很重要的问题，用“…即可”无法体现出解决这个问题背后的复杂性

    要满足思源的万物皆内容块，那么首先记录的最小粒度就是块，那么在存储数据上可以抽象为一个内容块就是一条记录，无论是用数据库还是 JSON 存储，以内容块作为存储单位即可。整个文档则由不同的内容块集合组成，具象化的话就是在文档表中存储包含的内容块 ID 即可，如此无论正向还是反向皆可查。解决了数据结构层面的问题，那么展现层的问题自然也不复杂，每个内容块都有单独的 ID，无论是内容定位还是类似列表的展示处理起来似乎都不算是事吧？
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    一个核心问题：如何在 MD 文件中唯一定位到一个块

    当然，要说 md 文档没有内容块的说法，这个确实是，但没有办法解决吗？当然不是，要从 MD 文档反解析数据结构为内容块，那直接定义一套规则即可，既然思源已经将#号作为划分内容块的标记，那么按照这个规则拆分文档内容存储内容块即可，多级嵌套可以理解为多级集合，较为麻烦的是内容块 ID 标记，得找一个不影响 MD 文档展示的隐藏元素来存储内容块的唯一 ID，解决了这个问题，MD 文档作为主数据源自然不是事了。至于怎样解决，方法还是不止一种的，各有优劣，选择题罢了。
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    不同意各有优劣的说法，MD 的弊端更大一些。

    而且楼上已经有朋友引用了 D 的帖子，里面说的也很明白

    1. 扩展语法的路走不通
    2. 就算扩展语法也无法解决 MD 资源文件问题
    3. 无法应对未来更加复杂的场景
    我说的这个并非需要扩展语法，只是找到一个不需要影响 MD 语法标准的写法作为 ID 标记。资源问题本身就不是问题，为什么非要把图片、视频、软件等其他资源合并到文档里呢？这本身就不科学好吧，只要刻意自定义资源存储路径，没人会在意这个。另外，再复杂的应用场景有数据库的支持还不能适应？那根本就不是 MD 语法的问题，那是整个数据应用的问题了。
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    说点“感情用事”的观点：

    1. 在已经有了 ob logseq 等用 MD 做格式的笔记软件后，思源没必要进去内卷了
    2. 在日益复杂的功能场景下，MD 格式的局限性只会越来越大，额外消耗开发资源
    首先明确目标是啥，思源的目标是啥？做个全能笔记？知识库？那当初为何选 MD 入手？成熟的笔记应用和知识库管理软件一堆，不和 MD 磕，去跟 oneNote、myBase 这些应用卷吗？感觉这种想法首先就是自我否定，然后迷茫。本末倒置了，搞那么复杂，其实有那么多需要吗？我只不过想要个全平台可用，用起来舒服，有简易文档分类的电子笔记本而已，甚至我都不需要什么双链引用和知识管理这些耗费精力的功能，这些功能从来只有极少数人用，大多数人并不需要，为了满足少数人的需求而忽略大多数人的需求，这路子似乎不怎么正啊。用产品的话说，很多东西看似重要，其实都是伪需求。
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    再就是回应一个问题

    思源基本就是文中说的“MD 做展示，而后端用独立文件格式”的形式

    甚至 MD 文件在思源可以实现自由的导入和导出

    这个逻辑没有问题啊，诉求不过是另外自动保存一份 MD 文档，而非导出。其他问题不过是这个问题延伸出来的一些可以解决的问题。
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    我对 “md 笔记生态”一说存疑

    只是有很多软件支持 md 语法，尤其是笔记软件

    再就是说的上的 md 笔记软件也就 ob 和 logseq，而且现在这俩的 md 文件很容易不兼容了

    这已经有悖于 md 的初衷了

    对了，如果说“md 笔记生态”是支持 md 语法的，那思源是属于的

    如果“md 笔记生态”是用 md 文件存储的，那我觉得及没必要，也弊端显著，不进去挺好

    2 操作
    Bard 在 2022-08-10 16:54:24 更新了该回帖
    Bard 在 2022-08-10 16:53:12 更新了该回帖
    所谓生态就是围绕一个关键因素建立的应用关联，你只看到了笔记一个场景，却忽略了整个大环境，目前 MD 文档正在成为富文本外的第二选择，许多应用系统集成了 MD 文档的直接应用，比如一些博客系统、一些文档管理系统、一些办公系统、一些信息发布系统、一些阅读系统、一些 IDE 开发工具等等，更不用说让 MD 源远流长的 Git 代码库了。你想到的只是满足个人写笔记，却没看到那些 MD 正在肆虐的地方，符合标准的 MD 文档正在成为主流。而原因，正是因为它的简洁与复杂，不矛盾，用简洁的语法实现复杂的效果，这就是 MD 的魅力，而你居然把它的优势看成一种劣势，着实有些以己度人。论复杂，请问你为啥不用富文本、HTML 写笔记？
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    我觉得评价思源不完美，有缺陷，自己不喜欢…的原因都可以

    但如果用 Markdown 的前提来诉说，我个人观点就是“格局小了”

    （无意冒犯，敬请见谅）

    如果思源不是基于 MD 我可能用都不会用，用思源本质上就是基于 MD 写作，思源要另立标准那也无所谓，再找另外的 MD 编辑器就是。是的，目前来说我只是把思源当作 MD 编辑器在使用，用它做知识管理是有风险的，不是诅咒哈，但我从不相信有啥万年不腐的软件，假使有一天思源不再更新了，那么思源独有的数据格式迁移起来就麻烦了，最明确的文件夹 + 文件本体的物理存放 MD 文档是最稳妥的方式，思源的逻辑分类实话说迁移起来比较费事，文档结构里每个分类都一个多余的 MD 文档不说，批量导出也不含资源，只能一个大分类一个大分类的导出，确实麻烦，不是我对思源没信心，只是见惯了跑路和毁前途的软件，用之前都得考虑好结局，这是底线，也是不想受制的考量。你可以说我格局小，但真不想也不愿在一棵树上吊死。
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    以下是我个人主观认为

    Markdown 是就是排版为主的，用 Markdown 做存储的只是在笔记软件探索阶段的一种阶段性尝试，ob 等软件的继续沿用，更多是一种“路径依赖”，既然是路径以来，就不能说明 Markdown 做存储的先进性

    要说先进呢直接存数据库就好，何必瞎折腾存什么物理文档。既然存在，那必然是有道理的。存数据库是方便，但跨平台同步怎么办？数据库的合并可不像文档合并那么简单，离线同步也不可能用中心化的数据库来处理，否则网络不通冲突依然存在，当然，解决方案很多，想要解决你的先进数据存储问题有很多优秀的方案可用。但为啥非得存 MD 文件？因为有地方要用啊，具体怎么用你也不用问，总之是有这个需求，无论是对接第三方系统还是个人笔记管理，都有其存在的必要性。导出固然也可以，但费事。简而言之就是想偷懒，编辑完就完了多好，还得导出解压放到指定位置去，这就增加了使用成本，因此我提这个也仅是基于使用不便来提，然后延伸出一堆问题，说了那么多我也不想再说了。思源要做成啥样我管不着，就提点看法。有无道理两说，总之我的需求只是好好管理我的 MD 文档，而不是管理所谓的知识或是笔记。这些在 MD 文档里就包含了，不需要软件替我思考该怎么管理内容，然后强制我按照这种思路去管理我的内容，即便这种方法确实很先进，但也意味着繁复，结果未必高效。
    shileiye •
  • wab77 • • 1 评论
    订阅者
    • 为何 Obsidian 比 Siyuan 更出名？
      • Obsidian 由 Dynalist 的开发者在 2020 年 5 月发布 0.0.1 版本，Dynalist 的竞品是 Workflowy，所以他们已经拥有了一批忠实的海外用户和稳定的社区，在社区中也进行过宣传。
      • 国外的软件很容易由用户传播到国内，但反之很难。
      • Siyuan 的国际化进程非常缓慢，没有专门的英文社区，因为它很难维护与沟通。
    • 为什么不用 word 写作或记笔记？
      • word 不是不能，而是不合适，因为有专门的写作软件与笔记软件。
      • 用户的需求是多样的，但是对于软件的开发者来说，不可能全部满足。所谓「重器轻用」，用一个软件最吸引你的地方，适当的提建议而非让软件变得十项全能。
    • Siyuan 不支持扩展
      • Siyuan 自身的编辑体验比较好，加上扩展只相当于锦上添花，而非如虎添翼。
      • 但是没有插件的 Obsidian 编辑体验并不好，拥有诸多插件的 Obsidian 才是如虎添翼，编辑体验直线上升。但是依靠插件让一个软件 All in one 并不是好的想法。
    • Siyuan 的快速迭代导致 Bug 层出不穷
      • 我也在想，Siyuan 进入正式版的速度是不是太快了些？
      • 作为笔记软件，最严重的问题是数据的丢失。软件一旦上云就会出现各种数据方面的问题，Siyuan 的社区中大部分是关于云端同步的问题。通过备份软件定期备份，每天或者每小时自动备份。但 Siyuan 的本地功能是非常棒的，方便后期整理。
      • 我经常在 Obsidian 中写文档，因为有的文档篇幅比较长，时间跨度大，我需要有易于查看的文档历史版本。Siyuan 的这些功能还不够好用，但是在完成后我会归档到 Siyuan 中，因为 Siyuan 的对文档的整理功能很好用。
      • Obsidian 的云同步做的很棒，这也是我用它来写文档的原因，App 也比较好用。即便如此，我也是每天定时备份着文档数据。
    • 文档格式非 md
      • 这是开发者的决策，他在博客中也有相关抉择的思考。你所想到的，开发者都有所考虑，开发者当然更珍惜自己的成果，也为了让软件走的更远。
      • 软件本身是开源的，数据不会丢失。而文档内的体系，比如双向链接这些东西是与软件捆绑的。但无论哪个软件都不例外，每个软件自己的特色功能用别的软件打开后可能就是面目全非的。
    • 不用纠结用目前还没有的功能，向开发者提出合理的建议，说出你的想法。开发者需要吸收与过滤用户的建议后才能让软件变得更好，开发者也很难，功能多会导致学习成本和维护成本急剧增加，80％ 的功能提供给了 20% 的人用，功能少则不能吸引更多的用户。所以有一些功能并非技术上不可行。
    这个回复很客观，简而言之，立场不同，考量不同。我是用户，想要什么可以提。我是开发者，要怎么做可以听用户的，也可以不听。自由选择而已，没啥对错之分。
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    诉求不过是另外自动保存一份 MD 文档，而非导出。其他问题不过是这个问题延伸出来的一些可以解决的问题。

    这个诉求的本质就基本等于“不可解”的，不能用一种类似“世上无绝对”的逻辑，假设时间无限，开发资源无限的前提，来说这事是可以做的。即使在可见范围内，这个问题都不可解，不可解的原因在之前已经罗列过了

    这句话用了两个“不过是…”，这是一种十分轻佻的表达形式，虽然相信楼主本意可能并非如此，但依旧像之前已经指出过的“理解不了这件事件背后的复杂性”一样的问题

    这么说只是为了阐明需求，与具体做事的难度无关，我觉得你把我说的理解的太复杂了，所以有必要做一些简单的陈述。不代表所述需求实施的难易程度，不要想多了。
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    所谓生态就是围绕一个关键因素建立的应用关联，你只看到了笔记一个场景，却忽略了整个大环境，目前 MD 文档正在成为富文本外的第二选择，许多应用系统集成了 MD 文档的直接应用，比如一些博客系统、一些文档管理系统、一些办公系统、一些信息发布系统、一些阅读系统、一些 IDE 开发工具等等，更不用说让 MD 源远流长的 Git 代码库了。你想到的只是满足个人写笔记，却没看到那些 MD 正在肆虐的地方，符合标准的 MD 文档正在成为主流。而原因，正是因为它的简洁与复杂，不矛盾，用简洁的语法实现复杂的效果，这就是 MD 的魅力，而你居然把它的优势看成一种劣势，着实有些以己度人。论复杂，请问你为啥不用富文本、HTML 写笔记？

    作者：shileiye
    链接： 关于思源笔记的一些看法
    来源：链滴
    协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

    “MD 语法”和 “MD 文档”并不能相提并论

    我相信 “MD 语法”正在成为富文本外的第二选择

    不认可“MD 文档”正在成为…

    “MD 肆虐的地方”与思源可以完美融入，因为开发者本身就是 MD 开发专家，支持最标准的 MD 规范

    在就像之前已经说过的，MD 简洁是排版的魅力，不是知识管理的魅力

    在知识管理和笔记软件的角度来看 MD 就是一种劣势

    “论复杂度”并不代表“MD 简单不能用，json 复杂而可以用”，意思是“当前知识管理的场景下，MD 简单到不能用”

    我都不想再辩了，如你所说，MD 文档是 MD 语法数据的载体，我只想用 MD 文档来存放 MD 文本，其他乱七八糟的格式，尤其是非明文的格式我不喜欢，仅此而已。
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    如果思源不是基于 MD 我可能用都不会用，用思源本质上就是基于 MD 写作，思源要另立标准那也无所谓，再找另外的 MD 编辑器就是。是的，目前来说我只是把思源当作 MD 编辑器在使用，用它做知识管理是有风险的，不是诅咒哈，但我从不相信有啥万年不腐的软件，假使有一天思源不再更新了，那么思源独有的数据格式迁移起来就麻烦了，最明确的文件夹 + 文件本体的物理存放 MD 文档是最稳妥的方式，思源的逻辑分类实话说迁移起来比较费事，文档结构里每个分类都一个多余的 MD 文档不说，批量导出也不含资源，只能一个大分类一个大分类的导出，确实麻烦，不是我对思源没信心，只是见惯了跑路和毁前途的软件，用之前都得考虑好结局，这是底线，也是不想受制的考量。你可以说我格局小，但真不想也不愿在一棵树上吊死。

    作者：shileiye
    链接： 关于思源笔记的一些看法
    来源：链滴
    协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

    思源没有另立“标准”，内部封装形式本质就和用户所解耦的，就是用火星文写也没关系

    在用户侧来说就是“MD 语法写，MD 文件导入，MD 语法导出”

    凡是都是有风险的，我理解楼主的担忧，但有句话是这样说的“不谈计量谈毒性，都是耍流氓”

    引申到这里，显然就是：不量化风险大小就说风险是不够严谨和轻佻的

    此处思源的核心优势就是“开源”了，相信楼主肯定会在仔细读过楼上已经有别的朋友评论过的

    哦对，再提一嘴什么是开源。

    开源就是这些源码是公布的，有效的，所有人都可以看、下载、修改和编译的，你自己可以在约定的规则下编译、修改和使用的。

    那么之所以 D 大和 V 大哪怕把项目删了，都无所谓，就是代码是完全公开的，这个项目不是像 QQ、WX、Word、WPS 那种私有的，代码完全不公开，这几个公司没了这软件就不能用的。而 Siyuan 你完全可以自己编译，或者用 Github 编译，都是你的自由。你也可以感觉 Siyuan 那里写的不好，不随你的心意，只要 Fork 一下，你就有一份随便你使用的 Siyuan 代码，随便改。

    Siyuan 自带的同步是官方同步，但这个文件夹就在我本地，我随时都可以访问，明文存储，我想备份到哪都可以，我就是直接备份到我的 Github 私有项目。我这两年都来来回回重装十几次系统了，Linux、Windows、MacOS 都用过，Linux 发行版我都用过五六个，要么直接复制粘贴，要么直接 git pull 一下，都没有一点影响 Siyuan。

    所以，支持开源，相信开源。

    作者：GuangDai
    链接： 关于思源笔记的一些看法 - GuangDai 的回帖
    来源：链滴
    协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

    以及再自行细心搜索“开源意味着什么”后

    真正的理解“使用思源的风险到底有多低”

    要是还不理解的话，楼主可以去把 D 的帖子搜出来，看看

    算了，我人好，怕楼主麻烦，已经找到了 思源笔记缘起 - 链滴

    数据可以完全离线以后，还剩下最后一个问题：软件生命周期。

    没有任何软件开发团队能保证软件能够持续可用，从开发团队来说，发生软件终止维护的可能性太多了，比如：经费不足、研发目标转移或者遇到不可抗力（比如开发人员突然离世）。

    有一种有效的方法可以在最大限度上解决软件停更造成的不可迁移，那就是 开源 。如果软件有足够价值且是完整开源的，即使主创团队无法继续维护了，其他开发者也能接过重任。从开发团队实际情况出发，完全开源是比较难办到的，虽然开源商业化模式在很多项目上已经大获成功，但并不是每一个项目都适合这样做或者说需要等待适合的时机。

    作者：88250
    链接： 思源笔记缘起
    来源：链滴
    协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

    虽然看完这篇“缘起”的帖子相信楼主已经可以进一步理解思源的部分情况

    但还是说以下万一地球毁灭，没人接手思源，应该怎么办吧

    1. 不要折腾思源的 .sy 源文件
    2. 直接导出 MD 文件包
    3. 找到支持 MD 导入的软件，导入

    要是还不行的话，思源的数据解析器也是开源的，楼主“不过是”改改解析器 .sy 文件想怎么导出就怎么导出，什么 Word，富文本，自己开发套笔记都可以

    有人说“历史虽然不重复，但总是压着相同的韵脚”

    但也有人说“历史数据不能代表未来走势”

    文档结构里每个分类都一个多余的 MD 文档不说，批量导出也不含资源，只能一个大分类一个大分类的导出

    我刚才试了，通过软件导出 Markdown 的形式都是可以的，所以我并不清楚楼主为什么这么说，我不相信楼主不自己试试就冒出来这句话，应该是我理解有误吧，希望楼主有时间的话可以进一步描述这个场景的不合理之处

    只要言之有理，我就带头提开发需求，再不行就在社区开投票贴，再不行就磨开发者，直到满足需求为止，这当然不是说服楼主转投思源，毕竟这是个开放的社区，您的建议或许可以方便的更多的用户

    说到这里，希望楼主用的不是 ob ,毕竟 ob 连开源软件都不是，从这个角度来说 ob 很有可能就死在思源前面了，谈何“超越”呢

    拜读了一下思源笔记缘起，上面所述的我基本赞同，因为二十年来我也确实在寻找一款可以长期使用的个人文档管理应用，也动过自己写一个的念头。但一是技术不到家，二是懒，所以一直在躺平。这一点上我是很佩服这些不服就干的人的。不过呢，哪怕遇见了思源也没完全满足我个人的需求。我也不想说什么代表广大用户的需求，至少二十多年来所经历的应用确实没有一个能完全满足的我个人需求的。或许我个人对文档的应用场景确实比一般人多一些，本来我也不想提这些的。因为就这些年在这行混的经验来说，很少有官方会为个别用户的需求而改变既定策略，各有各的想法，难免出现认知冲突，只是不吐又不快，我大概这辈子也很难自己去写个笔记应用，但有些东西说不说是一回事，听不听是另外一回事，如果有需求不说，那自然是我的问题。说出来有没人在意那不是我的事。所以基于此我在这里说了一下，并非指望官方就眼巴巴的赶紧给做出来，也只是让一些人知道有人有这些需求，有一些声音罢了。 至于说开源的问题，技术不到家，写写小插件还好，涉及到架构调整还是算了。官方给的源码没有说明，我至今都还没编译成功，更别提修改了。所以我改不了，即便改得了，官方也不一定接受。总之呢，思源的开源目前对于我等渣渣意义不大。否则我也不用在这里提这些“非主流”需求了。 最后，关于导出导入 MD 文档，我只是说它繁琐，不如直接保存 MD 来的实在，仅此而已。
    shileiye •
  • Bard • • 1 评论
    订阅者 捐赠者

    要说先进呢直接存数据库就好，何必瞎折腾存什么物理文档。既然存在，那必然是有道理的。存数据库是方便，但跨平台同步怎么办？数据库的合并可不像文档合并那么简单，离线同步也不可能用中心化的数据库来处理，否则网络不通冲突依然存在，当然，解决方案很多，想要解决你的先进数据存储问题有很多优秀的方案可用。但为啥非得存 MD 文件？因为有地方要用啊，具体怎么用你也不用问，总之是有这个需求，无论是对接第三方系统还是个人笔记管理，都有其存在的必要性。导出固然也可以，但费事。简而言之就是想偷懒，编辑完就完了多好，还得导出解压放到指定位置去，这就增加了使用成本，因此我提这个也仅是基于使用不便来提，然后延伸出一堆问题，说了那么多我也不想再说了。思源要做成啥样我管不着，就提点看法。有无道理两说，总之我的需求只是好好管理我的 MD 文档，而不是管理所谓的知识或是笔记。这些在 MD 文档里就包含了，不需要软件替我思考该怎么管理内容，然后强制我按照这种思路去管理我的内容，即便这种方法确实很先进，但也意味着繁复，结果未必高效。

    作者：shileiye
    链接： 关于思源笔记的一些看法
    来源：链滴
    协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

    思源是有数据库的，“重建索引”只得就是数据库

    有物理文档，是为了和数据库形成优势互补，物理文件偏重于个人备份，数据库偏重于检索功能

    并不是什么事都“存在即道理”，新冠还传播着，有道理吗？非洲还有饿死的人，有道理吗？

    多看看官方帮助文档就会知道，思源跨平台同步用的是加密后的文本就行同步的，跟数据库没关系

    不需要软件替我思考该怎么管理内容，然后强制我按照这种思路去管理我的内容，即便这种方法确实很先进，但也意味着繁复，结果未必高效。

    “己所不欲勿施于人”

    己所欲就可施与人？那似乎叫独裁。干嘛非得加密呢？就喜欢明文存储不行？想加密的加密，不想加密的明文存就是了，给用户选择，而不是帮用户做决定。存在即合理是哲学问题，怎么说都可以是对，也可以是错，就不与你探讨了。做软件如做人，得道多助失道寡助，按自己的想法思路做事当然没问题，只是大多数人喜欢你只是因为同道，不喜欢你只是因为非同道。设限于小众，那便只能服务少数人。既然这软件只是为了服务那几个人，那我自然也没啥好说的。
    shileiye •
请输入回帖内容 ...
shileiye
成都
回帖
2
 帖子
1
 积分
561

近期热议

推荐标签 标签

  • 安装

    你若安好，便是晴天。

    128 引用 • 1184 回帖
  • iOS

    iOS 是由苹果公司开发的移动操作系统，最早于 2007 年 1 月 9 日的 Macworld 大会上公布这个系统，最初是设计给 iPhone 使用的，后来陆续套用到 iPod touch、iPad 以及 Apple TV 等产品上。iOS 与苹果的 Mac OS X 操作系统一样，属于类 Unix 的商业操作系统。

    84 引用 • 139 回帖 • 1 关注
  • 七牛云

    七牛云是国内领先的企业级公有云服务商，致力于打造以数据为核心的场景化 PaaS 服务。围绕富媒体场景，七牛先后推出了对象存储，融合 CDN 加速，数据通用处理，内容反垃圾服务，以及直播云服务等。

    25 引用 • 215 回帖 • 163 关注
  • 倾城之链
    23 引用 • 66 回帖 • 97 关注
  • 智能合约

    智能合约（Smart contract）是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易，这些交易可追踪且不可逆转。智能合约概念于 1994 年由 Nick Szabo 首次提出。

    1 引用 • 11 回帖 • 10 关注
  • Sandbox

    如果帖子标签含有 Sandbox ，则该帖子会被视为“测试帖”，主要用于测试社区功能，排查 bug 等，该标签下内容不定期进行清理。

    368 引用 • 1212 回帖 • 577 关注
  • OpenResty

    OpenResty 是一个基于 NGINX 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。

    17 引用 • 35 关注
  • 运维

    互联网运维工作，以服务为中心，以稳定、安全、高效为三个基本点，确保公司的互联网业务能够 7×24 小时为用户提供高质量的服务。

    148 引用 • 257 回帖
  • Flutter

    Flutter 是谷歌的移动 UI 框架，可以快速在 iOS 和 Android 上构建高质量的原生用户界面。 Flutter 可以与现有的代码一起工作，它正在被越来越多的开发者和组织使用，并且 Flutter 是完全免费、开源的。

    39 引用 • 92 回帖 • 8 关注
  • 生活

    生活是指人类生存过程中的各项活动的总和，范畴较广，一般指为幸福的意义而存在。生活实际上是对人生的一种诠释。生活包括人类在社会中与自己息息相关的日常活动和心理影射。

    228 引用 • 1450 回帖
  • WebComponents

    Web Components 是 W3C 定义的标准，它给了前端开发者扩展浏览器标签的能力，可以方便地定制可复用组件，更好的进行模块化开发，解放了前端开发者的生产力。

    1 引用 • 28 关注
  • ReactiveX

    ReactiveX 是一个专注于异步编程与控制可观察数据（或者事件）流的 API。它组合了观察者模式，迭代器模式和函数式编程的优秀思想。

    1 引用 • 2 回帖 • 126 关注
  • 电影

    这是一个不能说的秘密。

    120 引用 • 597 回帖
  • BookxNote

    BookxNote 是一款全新的电子书学习工具，助力您的学习与思考，让您的大脑更高效的记忆。

    笔记整理交给我，一心只读圣贤书。

    1 引用 • 1 回帖 • 2 关注
  • AngularJS

    AngularJS 诞生于 2009 年，由 Misko Hevery 等人创建，后为 Google 所收购。是一款优秀的前端 JS 框架，已经被用于 Google 的多款产品当中。AngularJS 有着诸多特性，最为核心的是：MVC、模块化、自动化双向数据绑定、语义化标签、依赖注入等。2.0 版本后已经改名为 Angular。

    12 引用 • 50 回帖 • 422 关注
  • Pipe

    Pipe 是一款小而美的开源博客平台。Pipe 有着非常活跃的社区，可将文章作为帖子推送到社区，来自社区的回帖将作为博客评论进行联动（具体细节请浏览 B3log 构思 - 分布式社区网络）。

    这是一种全新的网络社区体验，让热爱记录和分享的你不再感到孤单！

    131 引用 • 1114 回帖 • 150 关注
  • Hexo

    Hexo 是一款快速、简洁且高效的博客框架，使用 Node.js 编写。

    21 引用 • 140 回帖 • 25 关注
  • Solidity

    Solidity 是一种智能合约高级语言，运行在 [以太坊] 虚拟机（EVM）之上。它的语法接近于 JavaScript，是一种面向对象的语言。

    3 引用 • 18 回帖 • 350 关注
  • CAP

    CAP 指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

    11 引用 • 5 回帖 • 563 关注
  • Firefox

    Mozilla Firefox 中文俗称“火狐”（正式缩写为 Fx 或 fx，非正式缩写为 FF），是一个开源的网页浏览器，使用 Gecko 排版引擎，支持多种操作系统，如 Windows、OSX 及 Linux 等。

    7 引用 • 30 回帖 • 455 关注
  • 链滴

    链滴是一个记录生活的地方。

    记录生活，连接点滴

    131 引用 • 3639 回帖
  • WebClipper

    Web Clipper 是一款浏览器剪藏扩展，它可以帮助你把网页内容剪藏到本地。

    3 引用 • 9 回帖 • 4 关注
  • Logseq

    Logseq 是一个隐私优先、开源的知识库工具。

    Logseq is a joyful, open-source outliner that works on top of local plain-text Markdown and Org-mode files. Use it to write, organize and share your thoughts, keep your to-do list, and build your own digital garden.

    4 引用 • 55 回帖 • 7 关注
  • WebSocket

    WebSocket 是 HTML5 中定义的一种新协议，它实现了浏览器与服务器之间的全双工通信（full-duplex）。

    48 引用 • 206 回帖 • 398 关注
  • Swift

    Swift 是苹果于 2014 年 WWDC（苹果开发者大会）发布的开发语言，可与 Objective-C 共同运行于 Mac OS 和 iOS 平台，用于搭建基于苹果平台的应用程序。

    34 引用 • 37 回帖 • 496 关注
  • 分享

    有什么新发现就分享给大家吧！

    242 引用 • 1746 回帖 • 1 关注
  • jQuery

    jQuery 是一套跨浏览器的 JavaScript 库，强化 HTML 与 JavaScript 之间的操作。由 John Resig 在 2006 年 1 月的 BarCamp NYC 上释出第一个版本。全球约有 28% 的网站使用 jQuery，是非常受欢迎的 JavaScript 库。

    63 引用 • 134 回帖 • 745 关注

最新标签