@hausen 应该需要抓包之类的才能获取吧。

@byte10 你举得这个例子就是终期红利回撤吧。

@quan01994 我也有爆雷这个顾虑，但是大公司（全球的保险公司）都白纸黑字的合同写好的，破产也有保护，应该不至于太担心这一条。

$ ollama run phi4
pulling manifest
pulling fd7b6731c33c... 54% ▕███████████████████████████████████ ▏ 4.9 GB/9.1 GB 104 MB/s 44s



@tozp 我试试这个 phi4

@gneko 我理解了。

@xiaoming1992 这个方法确实方便。直接把桶的策略改成所有人都可以 read

Access permission for `minio/bucket` is `download`

@realpg 我现在就是在家躺平呢，没事干。写一下代码打发时间。

@Chalice 只是证明一下是防火墙 NAT 的规则导致它不能完全表现为 Endpoint-Independent Filtering ，是一个假的 Fullcone NAT ，经过测试，我的 NAT 是 Port-Restricted Cone NAT 。

电脑上连接着服务器 A, 然后服务器 A 再用不同端口访问电脑的 PublicIP:Port 也是被 denied. 所以是 Port-Restricted Cone NAT 。

@Kinnikuman 补充一下这个测试。

~ ./socket_program 8081 45.xx.xx.13 8081
Server listening on port 8081
Received from server B: Your IP: 123.xx.xx.138, Your Port: 61288

Received connection from 45.xx.xx.13:51662
Received connection from 103.xx.xx.120:39458


只有当我在 OpenWrt 防火墙指定端口转发才可以正常收到任意 ip 发到 61288 端口的请求

uci add firewall redirect # =cfg133837
uci set firewall.@redirect[-1].dest='lan'
uci set firewall.@redirect[-1].target='DNAT'
uci set firewall.@redirect[-1].name='test'
uci set firewall.@redirect[-1].src='wan'
uci set firewall.@redirect[-1].src_dport='61288'
uci set firewall.@redirect[-1].dest_ip='192.168.11.112'
uci set firewall.@redirect[-1].dest_port='8081'

@swananan 我做了一下试验，我的电脑处于 Fullcone NAT 后面 (STUN client version 0.97 Primary: Independent Mapping, Independent Filter, preserves ports, no hairpin)，运行了下面代码中的脚本，然后用两个服务器做测试，服务器 A 监听 8081 端口，然后电脑执行这个这个程序向服务器 A 发送一条请求，拿到了电脑的 IP 和端口: Received from: Your IP: 123.xx.xx.138, Your Port: 57851 ，然后用服务器 C 向电脑的公共 ip 123.xx.xx.138:57851 尝试连接，但是 connection refused 了。这也许能证明，我的 stun 检测的结果 (Independent Mapping, Independent Filter)是错误的。


试验代码：

https://gist.github.com/FaiChou/7291580826d83d9340f9fe6c8cd8a79b



我的问题应该没有了。

@swananan 我做了个图比较形象，感觉你说的例子有一点问题。我一会写一个 example 来测试下。

https://i.imgur.com/4m9rqYz.png

@swananan 我在附言中 append 了一条我的疑惑，原来写的可能表达不是很清楚。请再帮看下。

不知道为啥不能 edit 了，那就用回复做一下 append 吧。

当你体验过 AI commit message 后，真就回不去了。它能准确给你做一下统计，比自己写的 commit message 清楚多了。

@cowcomic 应该是实时的，签到时候合约会给地址打过去 20Power ，使用 100Power 生成邀请码会给 `0xf496**D355` 这个合约地址转账。D355 这个地址也在不停的 mint, 可以用自己的地址看下：

https://i.imgur.com/6jc4z9a.png

@iOCZS "CPU 闲着也是闲着"，不这么认为，能让 cpu 少工作，也算是性能优化的一部分吧。当然这个话题中是舍弃掉内存来换取 cpu 的部分工作。而且这个讨论不考虑分页获取数据，就是一个几万几十万条的数据一次性加载到 list 中。

@LuckyLauncher

@RightHand

绘制是另一个问题了，有专门的硬件处理。

所以，我的问题有问题是吗？相对于绘制来讲，那些 cpu 计算复杂的列表如何更换数据，都是很 easy 的计算？

@MrDream @PTLin @expy @kuanat 大佬们请看我的附言，有了比较详细的描述，帮我指正下。

@ysc3839
@MrDream
就像 infuse 观看一个 100 多 G 的视频，我看进度条也能缓存很多，这内存吃不消吧。

缓存肯定是 Packet 而不是 Frame ，解码后的 Frame 太大了。