是的，可以选整机，个人推荐装机猿或者硬件茶谈。

@AoEiuV020JP @qinyui
Windows 和传统桌面 Linux 没有严格的沙盒机制，一个程序如果不依赖外部密码就能读取某些数据的话，另一个程序也能做到。
macOS 对此的解决方案是，系统的钥匙串可以分应用限制读取，比如说是 A 应用创建的，那就只有 A 应用能读取，其他应用要读取的话需要管理员权限。而 A 应用的识别则是通过包名和签名。需要注意的是，macOS 非商店应用没有文件沙盒，A 应用是能读取 B 应用的各种数据的，只能通过数据加密来保证安全。
Android 和 iOS 的解决方案是，不同应用数据隔离，应用只能读取自己的数据。

一般有 fullcone NAT 的吧，用 natmap 开端口吧

@laihan4396a 那建议优先选 32G 的吧。
另外个人觉得 CPU 性能差一点也不是什么问题的，内存不够会很卡甚至跑不起来，但 CPU 性能差点顶多是延长一些计算时间，问题不是那么大。

Mac mini 那个，如果不是一定要 24G 内存的话，可以考虑 16+256 ，拼多多只要不到 4500 ，1TB 硬盘和硬盘盒怎么也不要 1000 元吧。

如果是我我会选择不要中文键盘以减少等待时间

@gzlock rss 好像是不能获取是否免费的

不建议这么干，PT 站一般都限制爬虫的，一般是要你把工具拿去审核通过后才能使用，建议找现成的工具用。

截图软件的话可以试试 Snipaste

进入这个页面估计是系统启动时出现问题，自动重启到 Recovery 了，可以尝试重启，然后在出错前用 adb 恢复回去，如果系统启动中 adb 一直连不上，估计就没办法了。

@julyclyde
我确认了一下，Unix socket 确实是不能直接作为普通文件 open 啊
```
~/testsocket $ python ../s.py &
[1] 23401
~/testsocket $ ls -alh
total 7.0K
drwx------ 2 root root 3.5K Oct 29 14:17 .
drwx------ 9 root root 3.5K Oct 29 14:16 ..
srwx------ 1 root root 0 Oct 29 14:17 socket
~/testsocket $ echo 123 > socket
bash: socket: No such device or address
~/testsocket $ echo 123 > ./socket
bash: ./socket: No such device or address
~/testsocket $ echo 123 | tee socket
tee: socket: No such device or address
123
~/testsocket $ cat socket
cat: socket: No such device or address
```

socket 文件？可以设置长度？我印象中不可以吧？你指的是什么？
首先没记错的话 Unix socket 不能当作普通文件 open write ，必须要用 socket 系列函数。
其次就算可以，TCP 是有流控制的，写入数据塞满缓冲区，但又没被读取的话，就不能继续写入了，所以不能满足需求。

另外，你的需求“可以查看进程输出的日志”指的是随时查看吗？还是说要日志文件达到一定大小后改为输出到另一个文件？
如果只是要随时查看，查看时不想看到新的内容，那用 more 或者 less 之类的工具应该能支持？
如果是要日志文件达到一定大小后改为输出到另一个文件，个人觉得较好的方案是日志输出到一个程序，然后程序计算大小并保存到文件里。这个方案也许某些 syslog 服务端程序是支持的，自己写一个也不麻烦。

嫌官方源里面的太旧的话，要不然找第三方编译的新版本，要不然自己编译，要不然升级系统。如果系统已经是最新的了，还是嫌包旧，那可以试试把系统换成 Arch Linux 。

@miaomiao888 不一定，可以是延迟删除。

@erfesq 不会先丢一遍，TCP 会通过 MSS Clamping 来确定链路中最小 MTU ，确定后就不会改了，丢了就丢了。一般来说运营商的设备要不然 MTU 是 1500 或更大，如果 MTU 较小的话，是会支持 MSS Clamping 的，因为如果不支持的话会对经过的流量造成影响。个人认为如果没实际遇到问题，没必要调低 MTU 。

有什么问题？说出来看看？

有很多种情况的，不过按软件注册码的原理，大致可以分为几类：
1.注册码不和机器码等其他信息绑定，这种多数是有人买了之后分享注册码，软件开发者没什么好的防范方法，一般是通过联网验证防范，那解决方案就是禁止联网或者伪造验证服务器。
2.有机器码，用的是一些简单的“对称型”算法验证，即软件本身是有完整的机器码->注册码的算法，用户输入注册码后会用这个算法算一遍，然后和用户输入的进行比较。这种情况很容易破解，只需要把其中的算法提取出来即可。
3.有机器码，用的是非对称加密算法，非对称加密算法有公钥和私钥，用公钥可以检验某数据是否是由私钥签名的。这种情况下验证码是由不公开的私钥生成的，即使有算法和公钥也很难破解，一般的破解方案是替换程序内的公钥，然后用自己的私钥签名。另外因为非对称加密算法需要较长的数据长度才能保证安全，因此如果注册码很短，那是有可能破解出私钥的。一个案例是 Windows XP 电话激活的私钥最近被破解出来了，早在 2000 几年，就已经有人分析出 Windows XP 电话激活的算法和公钥了，但因为算力限制，当时很难破解私钥。

RDP 是基于 TLS/DTLS 的，所以理论上可以用 sniproxy 实现。