acorngyl

这就是酒精计算器吧。
刚开始查酒驾那几年用得挺多的，喝完酒，算算要等多久才能开车。给出来时间都挺长的，一杯白的，冲着 20+h 去了。大家觉得不靠谱（时间太长，等不了），就都不用了。

@wymisgod #33 看完鸡皮疙瘩落一地。哈哈哈哈。
我已经准备装个带提手的 pc 的，平时放办公桌底下，平时 Remote Desktop 打字，周末拎上回家打游戏。

新闻上说的都是批发价。饭店都是冷库买，10-20kg 一箱的，你也可以从网上找批发商，一般一箱也给你发物流（要自己去物流园拉）。说每斤价格，和内蒙鲜肉批发便宜 10%？毕竟羊肉一斤 30 左右，差个 2-3 元的样子。肉质感觉内蒙的好点，其实差不多。集采用进口肉，主要是因为品质稳定，拿羊腿举例，进口腿，只要不换品牌，大小口感基本差不多，如果买鲜肉，每批肉都不一样，天天找货比较头疼。

再说下“冰鲜”这事，现杀的肉就现吃，回家别冻，也别买贩子冻的。冷链的肉都是低温速冻，鲜肉出来，直接进 -20+的冷库，这样的肉可以保险个几个月。但是不能解冻，解冻了再冻，因为家里冰箱温度不行，就开始风干、变质了。超市、大部份批发鲜肉也都是这种肉，冷链来了解冻卖，解冻了卖不完也不新鲜了。

@Gilfoyle26 #78 鹅厂是要的做是 wegame ，只不过借用下 switch 的用户群，估计是发现机能和用户群都不满意，现在放弃了。最近刚放出消息，他们找 intel 开发自己的掌机去了。

@zjiajun #24
我把我这的整理了一下。有启发的话，就用吧，如果感觉太乱了，就打搅。
本来还想分下类的，结果看见 30+的隐藏目录，我已经无力吐槽了。

1. .AzureToolsForIntelliJ：Azure 插件为 IntelliJ IDEA 生成的配置目录，用于存储连接 Azure 的配置信息。
2. .android Android 开发工具的配置目录（如 Android Studio ），存储模拟器和 SDK 配置信息。
3. .cargo Rust 编程语言的包管理器 cargo 的配置和缓存目录。
4. .conda：Conda 虚拟环境管理工具的配置目录，存储环境和包管理信息。
5. .docker：Docker 的配置目录，存储 Docker CLI 的设置和缓存。
6. .gitconfig：Git 的全局配置文件，包含用户的 Git 设置（如用户名、邮箱等）。
7. .ipython：IPython 的配置目录，用于存储交互式 Python 的历史记录和配置。
8. .keras：深度学习框架 Keras 的配置目录，存储模型和预训练权重缓存。
9. .m2：Maven （ Java 构建工具）的配置和本地仓库目录。
10. .matplotlib：Python 数据可视化库 Matplotlib 的配置目录，存储字体缓存和样式。
11. .mysql_history：MySQL 客户端的命令历史记录文件。
12. .node_repl_history：Node.js REPL （交互式命令行环境）的历史记录。
13. .npm：Node.js 包管理器 npm 的全局缓存目录。
14. .pgadmin：数据库管理工具 PgAdmin 的配置目录。
15. .python_history：Python 交互式命令行的历史记录。
16. .rustup：Rust 编程语言的版本管理工具 Rustup 的配置目录。
17. .swiftpm：Swift Package Manager 的配置目录。
18. .yarnrc：Yarn （ JavaScript 包管理工具）的配置文件。
19. .vscode：Visual Studio Code 的用户配置和扩展缓存目录。
20. .lemminx：XML 语言服务器的配置目录。
21. .redhat：Red Hat 工具（如 Red Hat Language Server ）的配置目录。
22. .visualdl：VisualDL 的配置文件，用于深度学习可视化。
23. .equo：一些 Equo 相关工具的配置目录。
24. .labelImgSettings.pkl：LabelImg 图像标注工具的设置文件。
25. .labelmerc：LabelMe 图像标注工具的配置目录。
26. .ollama：Ollama 相关工具的配置文件。
27. .modelscope：ModelScope 模型管理工具的配置目录。
28. .hawtjni：HawtJNI 是 Java Native Interface 的工具库，其配置目录。

@mMartin #1 @ericshen #18 只知道 conda 可以管理 py ，maven 和 node 也行吗?


@conn457567 #16
@liununu #17
@zieglar #19 貌似 mise 是我说的意思。

我就希望所有包或者依赖都在一个目录里，比如～/mise/install/ 下边它们想几个文件夹都无所谓。我～/ 下，现在光 带 “ . ” 的文件夹都一屏了，看着都头大。新电脑应该就有 sh 、Downloads 、Documents 等十几个的。等换电脑的时候试试 mise ，然后给老电脑彻底格了。

@lasse #18 看来咱俩需求差不多。看测评，本地 LLM 最多吃到 64G ，再往的非量化和 7B 微调，基本就是能加载加载项目，跑不动的状态。128G 属于彻底没用。
但是吧，现在都是 api+工作流的用，本来也不用本地跑，再加上有 autoDL ，一天几十块钱。本地最多自己试试 MXL 能不能用。所以比较纠结要不要 Max ，如果 Max 刷网页比 pro 续航少得多的话。

刚问了 gpt 两个问题
1 、768 个 1 加 768 个 1 （ 1111....1 + 11....111=?）。
gpt 的回答是 768 个 2.
点开计算过程，生成了段 python
# Calculating the sum of two large numbers
num1 = int("1" * 768) # 768 digits of 1
num2 = int("1" * 768) # 768 digits of 1

result = num1 + num2
result

2 、如果直接问 11+11 就是直接给的 22.
说明 gpt 的代码做了分支，如果简单计算，用的是 LLM ，直接“transformer”答案了；如果计算比较复杂，会用二次 prompt 调计算引擎。按理说 transformer 算概率的话，没办法这么精准的算上百个数字的。但是它现在学会“作弊”了，我生成不了你，我会写代码啊，哈哈哈。如果说 transformer 是黑盒，智能不智能得解释不清楚，这都出来 python 代码了，这就不能是 AI 了吧。

现在生产上的定制大模型，都是用通用接口加海量 prompt ，通用模型只是做个语意检索用的，返回答案都是通过检索到的模版回答的。比如让 agent 给写个工作汇报，公司模版库里有汇报模版，模版会细到指导通用模型写 hmtl ，然后再调通用模型，出来的工作汇报是整篇有图表的文档。现在的 gpt 也，提问个复杂问题，看回答过程，有好几部推理。这里边编写 prompt ，做工作流的工作，都不应该算 LLM 的能力了。

所以，一个堆砌了量工作流的提示词的系统，有智力？它能不能自己写提示词呢？

貌似都是 4 颗 128 位的颗粒，就是容量不一样，那功耗应该没什么区别。
就是想问下 OP 买 64 的需求？
我也挺在乎续航的。平时白天都不插电用。就偶尔重活，中午吃饭充下电。貌似大多情况 m4pro 就够用，续航还长。所以在纠结要不要那个 64G 买来看画，反正现在炼丹已经租显卡了。