@luoshengdu @byte10 哦不是很熟悉笔记本上的 M1 。
一般而言就算是 M1 也还是台式机更好一些，笔记本长时间处理恐有散热问题。
（当然如果 macbook 发热量不大那当我没说。）

关于硬盘供电的问题，老哥提醒了以后我才知道有之前的帖子。
刚刚去看了一下。
首先硬盘的状态一般是跟着供电走的，你插着电，硬盘会一直转下去。
企业级的方案可能会有背板支持（更大的概率是只支持分时启动而不是分时断电）。
然后硬盘对电源的要求非常高，就算是价格不便宜的正品电源，如果电源输出波纹比较大的话也会快速损坏硬盘。
一个电压不恒定的电压源对硬盘造成的一次损害，可能比好几年多次掉电造成的损害都要大得多。
运气不好一次电压大幅波动硬盘就上天了。

硬盘突然断电对硬盘伤害很小的，几乎可以忽略不计，你每天拔一次电源，连着拔两三年硬盘都不见得会坏。
你说的断电以后硬盘坏的情况，这个一般和断电没关系，是因为马达启动出了问题，马达停下来了就起不来了，这和你是正常关机还是直接拉电源没关系。
硬盘突然断电导致的问题主要是磁头需要停靠到停靠区。断电的时候硬盘会自己执行这个动作，用剩余的能量把磁头拉出去。

这么多东西你如果只是想弄着玩，当然是可以的。但是如果要真正拿来做存储还是算了。不知道哪天硬盘就被劣质电源烧了。一个小容量 UPS 能解决的问题何必用电容解决。我也喜欢折腾各种东西，但是折腾久了就会发现还是用成品最便宜。垃圾方案上了以后还是会觉得有各种不足，到最后还是滚回到买成品，那还不如一开始就买成品完事。我存储用的硬盘架是用亚克力板钻孔搭的，用了几个月以后还是买了超微的盘柜，这可比亚克力架子好用多了。

@byte10 笔记本剪视频也挺反面案例的……

劣质电源烧硬盘，高温烤硬盘，保命用的 UPS 靠 DIY ，然后走无线做大容量传输，简直是教科书级的反面案例了，不知道该从哪点开始吐槽。

可以考虑找个没什么用的电脑（或者虚拟机）装上试一下，看看有没有什么痛点。
我是装上十分钟就决定滚回 10 了。

@ksc010 12VO 标准。如果普及了，你会发现给电脑多加几块硬盘都会变成奢望，因为供电跟不上了。

电流不够。你猜猜为什么大 D 口会有两根 GND ？

现在的电脑芯片在不工作的时候耗电少，工作的时候耗电多。
挖矿可以有计算挖矿，存储挖矿，存钱挖矿等多种做法。
其中计算挖矿需要随时计算，所以耗电高。
存储挖矿是计算一次，然后存在硬盘上，所以耗电偏低，但是需要买硬盘。
存钱挖矿是只要钱包里有钱就能挖，但是你得先有钱（比如通过购买）才能挖钱。

@xtinput 那是混合休眠，不是单纯的睡眠转休眠。

@rus4db 谢谢你大哥，治好了我能看懂中文的毛病（狗头

内存 640KB 就够了（

开了个 arm 的机子拿来跑开源软件编译，还顺手重装成了 Debian ，感觉良好。

电视机早就具有计算能力了。

@lichao 概念是类似的，不是添加字符串而是添加成 ast 然后从 ast 构建语句。我相信就算 Java 应该也能实现出来的。

@pandago1 嗷，我以为字段已经加完了。
对 undo 不太熟，如果只加字段不加默认值呢？
然后建一个视图，对于旧数据返回 n ，新数据返回真实值，然后再在背后批量更新。

在用。双向选择，如果我觉得内容不重要，我就关掉页面就行了。如果内容优秀，我会允许广告。

我 i7-8665U 的 ThinkPad 插 32G 条子没问题。建议你直接插上去试试再说。

开个视图返回正确的数据，然后背后再慢慢更新旧数据？

StringBuffer 意味着你只能以真正 SQL 的方式去写查询。
如果用 AST 或者类似的技术，则不需要遵循 SQL 的顺序，也不需要逼着用户去加生硬的「 and 」。

举个简单的例子：

bob = User.where(email: "[email protected]").where(active: true)
# => SELECT "users".* FROM "users" WHERE "users"."email" = '[email protected]' AND "users"."active" = 't'

details = User.select(:id, :email, :first_name).order(id: :desc)
# => SELECT "users"."id", "users"."email", "users"."first_name" FROM "users" ORDER BY "users"."id" DESC

bob.merge(details).first
# => SELECT "users"."id", "users"."email", "users"."first_name" FROM "users"
# WHERE "users"."email" = '[email protected]' AND "users"."active" = 't'
# ORDER BY "users"."id" DESC LIMIT 1

这里的这种 bob.merge(details).first 的用法可以让代码变得非常干净且易于维护。
你可以提前列出所有可能的查询条件，然后在最后一步根据输入参数或者具体需求进行拼装。

该用 CentOS 8 的地方肯定不会考虑改用其他系统，无非是在 RHEL/OL 和 Alma/Rocky 之间选而已。