你税真交全了吗

自己高兴就好。。。

启动快 5 倍，那不加载代码可不就快了吗，跟 vite 似的，启动是快了，访问的时候等着

@robinshen 关系很大，但不是直接关系，生态吸收不到人才，已有的人才流出，新的语言概念得不到应用，架构得不到换代，这些都会间接作用在项目质量上，而且是无解的。

微软花多少成本在维护 GH ，GL 又花了多少成本维护，而你一个人就已经把项目做到了这个程度，这就是云泥之别。

所谓云原生完全就是炒作概念，换句话说，云原生就代表离开云就运行不了，那岂有此理。首先需要重新定义云，把云替换解释成 k8s ，这样才可控，否则就为他人做嫁衣了，很多人做了半天都是给 AWS 在做销售。只要做到 k8s 全兼容就可以称云原生了，和语言无关。

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

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

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

我又多想了几步，你这个项目的竞品 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 量化的版本

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