-
如何评价“开源本来就是为爱发电,不应该有任何负面评价”这种思潮?
2024-08-08 11:48其实“下载量”“收藏量”不也是一种变相的评分吗?要是担心开发者的“玻璃心”破碎,这些完全可以全部取消,不允许任何筛选、排序条件,只有按名字拼音排序,不显示下载数量,这样就能保护开源作者的玻璃心了
-
如何评价“开源本来就是为爱发电,不应该有任何负面评价”这种思潮?
2024-08-08 11:41评分和评论我是赞同的,但有点费力不讨好,开发很麻烦的,现阶段的思源做不了这个事情。至少要等到集市像 Obsidian 那样规范化了再说。
问题在于你的论据有问题,做不了评分和评论是客观因素制约,被你上升到了道德层面。
用户不同意你的观点,开发者不同意你的观点,说明你脱离了群众,被骂是正常的,要接受负面评价。你这明显转移话题了,我的观点“开源本来就是为爱发电,不应该有任何负面评价”,想表达的是开源程序开发者的心态问题,包括但不限于思源。你强行把话题转向思源笔记本身的开发,我又不是思源笔记的开发者,开发难度是怎么样我又怎么会知道?话说,你是思源笔记开发者之一吗?怎么了解这么清楚?
-
如何评价“开源本来就是为爱发电,不应该有任何负面评价”这种思潮?
2024-08-08 11:16很简单,用户评论和评分,开发者可以不管不顾啊,你们都给差评和低评分我也不改进也可以,因为没有义务。用户评论评分的目的只有一个:就是为了让后来的用户方便的找到较好的插件
-
如何评价“开源本来就是为爱发电,不应该有任何负面评价”这种思潮?
2024-08-08 10:45我都不用看你贡献了什么?简历谁都会把自己写得很漂亮。我只需要知道核心的:你只有 103 followers,相比之下 D 大 1.7k,在思源笔记社区估计都没几个人认识你,装什么?
-
如何评价“开源本来就是为爱发电,不应该有任何负面评价”这种思潮?
2024-08-08 10:15这个世界离了开源还真的活不了。
目前所有主流的语言(除了 java)的编译器和解释器(如果是解释型语言的话)都是开源的:rust,gcc,clang,llvm,python,等等等等等。
目前世界上几乎所有服务器都是 Linux,Linux 是开源的。
目前所有嵌入式设备,包括嵌入式开源设备用的 freeRTOS 和 chibios 都是开源的。而且你这里完全偷换概念了,
你这里列举的编程语言,其实已经非常接近自然界存在的石头、水这些唾手可得的东西了,就像人们不可能、也没必要研发一个新东西来替代石头、水一样,人们不可能、也没必要研发一个新东西来替代各类编程语言
这个和绝大多数开源 app 项目是有本质区别的,你们只是开源,并不是基座,并没有不可替代性
-
如何评价“开源本来就是为爱发电,不应该有任何负面评价”这种思潮?
2024-08-08 10:04很简单,没有人会对山上的石头收费,但是石头碾碎成沙子就要收费,做成房子更是收费。也没有谁对江河海里的水收费,经过净化的水就会收费,用水做成的饮料、奶茶就会收费
-
如何评价“开源本来就是为爱发电,不应该有任何负面评价”这种思潮?
2024-08-08 09:56我们用户可没有优越感,反而是你们这些开源作者总是一副高高在上的姿态,真的让人不爽。难道离了你们的免费开源还能活不了?
-
商业化运营 SiYuan 的内容社区
2024-08-04 10:17SiYuan 是我用过所有笔记软件中最优雅的一个。
这只不过是先入为主 + 用过的软件太少罢了
但是 SiYuan 的内容社区却非常的荒芜。
有没有可能因为不好用,所以用的人少,所以社区荒芜?
只沉浸在思源的社区和粉丝小圈子,自然认为思源就是笔记软件,笔记软件就是思源
我可能说话很难听,主要是想提醒各位不要坐井观天
-
关于实现“相关性”笔记功能的可行性思考,以及困惑
2024-08-02 06:18“相关性”的本质就是全局搜索当前页面标题的结果,并将其展示在面板上(不管这个面板叫相关性面板 or 反链面板)。也就是说,只要支持全局搜索的软件,都可以轻易做到相关页面,后续只需要优化搜索逻辑即可
-
从 2024 年的视角来看,以 Roam Research 为首的双向链接似乎已经降温
2024-08-01 10:10但是笔记这东西 AI 也不能完全取代吧?ai 的在回答常规问题时确实还可以,深入点就不行了
-
从 2024 年的视角来看,以 Roam Research 为首的双向链接似乎已经降温
2024-08-01 06:13不管是本地还是在线,只要能实现,我觉得都有意义,我并不觉得本地就高人一等。
flomo 去看了一下,好像新功能确实是有这个“相关页面”,就是不知道效果如何
-
从 2024 年的视角来看,以 Roam Research 为首的双向链接似乎已经降温
2024-08-01 06:10- 传递型引用,正链用于在日记记录时指定内容归属,反链用于在主题中汇总其他位置下的所属内容;
- 接 MOC 链,正链用于以链接形式组织分类,反链用于跳转回上层分类;
- 关联型引用,正链用于以锚文本调用内容本体,反链用于汇总与内容本体有关的其他主题;
- 内容重述,正链用于指向内容原始形式的本体,反链用于查看本体内容的其他表述形态。
我怎么感觉你用的太复杂了?
- 传递型引用:完全可以用同步块来实现更好的效果
- 接 MOC 链:并不是所有页面都需要跳转回上层分类,因为很多时候我们只需要聚焦于本页面,上层分类是什么样的本页面并不关心,如果上级分类很重要,那他自然会出现在“相关页面”的面板上(而且不是还有手动创建的单链保底吗)
- 关联型引用:这个“相关页面”能完成得更好。“反链用于汇总与内容本体有关的其他主题”,如果两个页面彼此相关程度很高,但是彼此没有相互引用,反链面板就不能展示两者的关系,但是相关页面就会展示出来
- 内容重述:“反链用于查看本体内容的其他表述形态”,说实话,这个功能设想就太鸡肋了,你还不如支持标题的同义词合并呢,参考维基百科
-
从 2024 年的视角来看,以 Roam Research 为首的双向链接似乎已经降温
2024-07-31 21:28我完全理解你的意思了。所以我认为反链面板这条路是死胡同。如果是【相关页面】面板,就不存在这个问题了:你在 A 页面随便建立链接指向 B,但是 B 的相关页面就不一定收录 A,甚至在我的理念里,【相关页面】他就不关注是否建立引用,只关注和 B 相关的程度