一个坐吃山空的人管他作甚。。。

咱们一般的开发者还是要冷暖自知，小马过河的故事听过没有

他能坐吃山空，一般人有那个山可供坐吃吗

我又多想了几步，你这个项目的竞品 GitLab, 什么 Gitee ，再就是 GitHub Enterprise ，这几位有个特点就是都是 Ruby 项目。

我现在家里装个 GitLab 隔三差五就是 email 说安全漏洞让我 update-asap ，这五年多就从来没断过，也不知道他哪来那么多安全漏洞，修也修不好，敢情他家漏洞比隔壁 PHP 那边的难兄难弟还多几倍。

Ruby 现在江河日下，跟不上时代，还不如 C++上进，马上就要步 Perl 的后尘。
只需要推波助澜，替天行道，加速 Ruby 进入历史的垃圾堆。

有些事长痛不如短痛，一个语言跟不上时代之后，人才就会持续流出，因为学习它的收益很低，并且落后于行业，由于人员的流出，这个语言的项目就更难得到发展，而维护难度和费用却不断增长，最终进入价高质低陷阱。
之前 Cobol 和 Perl 的淘汰都已经展示了这套运行机制，需要吸取教训。

所以说在进行市场活动的时候，可以指出竟品维护的可持续性及成本的问题，提醒甲方不要花钱买个大爷。
另外借上 Java 的东风，就说总之是个 Java 项目甲方自己也可以改，并且 Java 的从业人员简直不要太好找。

基于这些假设甚至可以主动出击，对 Ruby 釜底抽薪，比如找人发表一篇 九评 Ruby ，
再比如对其他 Ruby 的遗产项目比如 HomeBrew 进行打击，用 Python 重写 brew ，甚至借助 GPT4 的力量直接把整个生态平移。这个项目本身体量小但影响大，四两拨千斤。

这种打法我愿称之为降维打击

我觉得你的这个方案很适合需要私有 GitLab 类似物，但是不愿意运行 Ruby 的情况。
Ruby 什么时候死，你的项目就什么时候起飞。
这件事迟早要发生，坚持住，提前做好布局，到时候就是你的主场。

插件的问题，语言模型管不了那么多

@OPLUS 我记得 temperature 不一样，可以检查一下，temperature 太高了之后幻觉大于记忆， 比较直观的是低 temperature 的时候出师表背得挺好，调高之后就胡言乱语。
包括线上的 130b 版本背出师表也是胡言乱语，但是本地 6b 低 temperature 就背得挺好。

@OPLUS 没有，这个就是最初的版本，而且是没有-32k 优化的。
官方的说法是如果 context 没有大于 8k 那么原来的模型效果其实更好。

ipv6 是直接转发的，一般来讲没有 NAT6 ，没什么好 offload 的，只有你手动对 ipv6 进行 NAT 的时候才有意义

妈问

犹如易语言追上 C++

踏马营销鬼才

那你用 int4 量化的版本

大差不差，你看看前端娱乐圈不也是么，一丘之貉，狗苟蝇营，互捧臭脚， 真正有能力有见地的，他都不屑混这个圈子

而立 不惑 知天命 耳顺

很多人在整个职业生涯也做不到而立，只能做个墙头草，当时什么热就搞什么

@qiguai2017 我觉得你这个解释是有问题的，按这么说，全网 AGPL 的 Neo4j 应该都共产了，数据全开放访问，这显然不是事实

除了房子你家还愿意拿钱做什么呢？

年轻人好说，有挺多能消费的东西。

但是父辈呢？ 60 后的父辈消费啥东西吗？
除了房子，没有任何东西能让他们正经把钱拿出来。
不消费，不是没钱，而是就想攒着。
关键是因为时代原因，他们还掌握了大部分的财富。
要让他们就这么攒下去，就成大明了

划个重点， 没有手术

夕阳产业了