@cnfczn 我的这个用了 8 年拆过大概 5,6 次键帽, 清洗键帽, 放洗衣粉水里用鞋刷子刷刷.
只有一次用刷子刷了键盘, 进水了,短路,按键失灵, 整个把静电容的板拆下来吹干再拼装上, 这个算是意外了.
另外换主控, 拆键盘不用拆键帽.
拆装键帽应该也不会松动吧? 每次都挺紧. 大可不必担心

@cnfczn 没明白你说的什么用久了键帽松动

@geekc3t 这些客制化太高级了. 我不是要求客制化, 各种轴, 各种灯, 看我前面那个帖子也明确了我的需求. 基本键位以及 layout 是 hhkb 就好. 我同事有用左右手分开的那种键盘, 但我没有去试.

@grey0207 你是说也是把 ctrl 改成了我那样吗? 你说的问题我还没遇到, 毕竟最近 2 周假期, 等上班了重度使用一下试试. 至于 bt 模式连按停不下来, 我也还没有遇到.


@drinke9 很多吗? 我搜索淘宝就那么一家啊, 你到 ydkb.io, 这个网站是键位布局的, 也有个淘宝在售的连接, 肯定是 yang 自己的.


@seanxx 是的, hhkb 的方向键默认也是组合键. 毕竟不常用的键
@Smash 我没拆过 bt, 你要看是不是跟后面的接口都能对应. 最好去问问 yang, 他应该了解. 这个主控可以让没有 bt 的有 bt, 理论上是没问题的.
@imkerberos 目前没 macos, 有了这个主控, 应该有了 macos 也不想这个软件了, 硬件层面解决了, 各系统都一样了. 而且最关键的, 无线了呀.

这个话题其实没任何意义. 但是, 有个问题忽然好奇. 中国大概有多少软件开发技术从业者? 肯定不止 700 万吧.

关于"喜欢用 root 用户吗"那个帖, 我上来就回复了, 这个听别人怎么劝都没用, 吃一堑才能长一智.

我做过比 rm /这个更蠢的事, 因为写脚本拷贝,粘贴, 结果粘贴的历史记录没弄好, 把无关命令贴进脚本, 把整个硬盘擦了, ssd 很快... 但是机器还正常运行了大概几十秒..我还排错呢..:D 所以在很多方面有教训并不是坏事. 当然要是没备份就另说了.

@MadHouse
当你在做一个工作, 发现截然不同路径的 n 个文件 /目录需要处理(比如说 rm), 你怎么做, cd n 次吗?
实际操作中, 可能 3 次就是极限了

"因为操作昂贵，所以只要在必须 resize 的情况下才 resize，其余需要 resize 的情况，就交给 putVal 再去触发 resize。"
@amiwrong123
我觉得你说的这条不是太合适, 我们可以讨论.
resize 昂贵, 但如果 table 里面东西越少, 这个"昂贵"的操作越"廉价". 所以我们就要找一个情况, 看 table 需要这个昂贵操作的概率有多大, 如果很大, 我们就尽量早做, 如果没那么肯定, 那就等到该做的时候做. 这是我对那个 if 语句的想法.

再回来说你的例子, 好像你觉得本来 12, 变成了 24, 好像空间占用一下多了一倍. 其实你仔细想想, 你这个是特例, 不能推广到所有该 x 空间的都变成 2x, 因为你的那个 size 增长是线性的, 但是 resize 的结果是指数的, 你说的这个情况只有在那个 t 是整数, 而且刚好等于 threshold 的情况才会发生. 你再想想, 当不是初始化缺省值的 case 下, 这种情况发生会很小, 而且这种害处只体现在 table 本身很大的时候. 可是, 当 size 越大,这种情况出现的概率就越低.

@CEBBCAT ... please read my comment twice

@CEBBCAT 为什么要删除.git 　你是需要 git archive 吧?

"一名系统洁癖程序员...." 既然是程序员, 先问自己, 自己做的东西, 过了自己洁癖这关了吗?　是不是做到极致了．

很容易啊, 启动多少次机器就买多少块硬盘, 装一次系统, 把所有硬盘都写了.
每次都启动新硬盘.
有洁癖的人甚至不能接受穿过的衣服, 所以都用新的, 要绝对的惯自己就要在别处投入.

至于真伪随机数, 以及分布问题这个网上大把文章. 我想说的是, 你们公司干嘛用程序来做啊?! 年会是集会对吧, 我们也有, 开会, 讲话, 聚餐等. 你们每人有个卡, 每个号码有个副券对应, 放箱子里, 抓阄多好!

而且可以让普通员工上台露面抽奖, 比如 财务之星, 销售大王... 如果都是技术人员, "年度代码提交量最多", "注释最多", "后端王子", "前端皇后"..... 多有意思, 上场抽奖时候还能后面大屏幕播放一些他 /她的有关背景...

@MeteorCat 推荐你 borg 备份恢复

@honjow 还真是有这个可能, 你一说我想起来了, 我有同事就是 ls 后面跟的选项 5,6 个如背口诀一般咔咔就写上了, 我还问他, 这些都什么意思?　他说他也不知道, 反正每次 ls 都这么写, 不管目录有什么.

@amiwrong123
关于+1. loadfactor 缺省有个值, 75%, 尽管 resize 都是按照 2 的幂, 这样计算, 这个商不会出现小数(默认起始 capacity 也是 16). 但是不要忘记, capacity and loadfactory 是可以用户给定的. 可是, resize 的算法是固定的, 所以会出现小数的情况. 如果要出现不整除的情况很容易, 你设计一个 2 的幂无法整除的除数的倒数就好了.

resize 需要 re-hash, 这是 hash-table data structure 里最 expensive 的操作. 但是又必须做. 所以才有了 loadfactor, threshold 那些零碎. 这些都没有必定有效的策略, 都是按照概率来的. 后面的子集情况是特殊情况, 但是有一部分 key 重叠是常见情况.

试了 deepin 播放器, 界面不错, 歌词那块不好用.
还是装了 osdlyrics 跟 deadbeef 配合使用.

1. 你删个连接(file), 为什么要 -r?
2. 为什么要-f
3. 你手再抖下, /前加个空格可咋整?

@cowlogli mbp16 正在 it 部门评估中, 明年上架了就去领一个. 手里的 HP 也不用交上去.
没有 gnu 是肯定不行的, 我还看了在 mbp 上装 linux, 好像新的 mac 很多功能不行, 比如声音等, 想想也就是用浏览器, 脚本, docker, ide, 可能 mac 也凑合了. 毕竟家里还是 linux.

@dyrone 还人工群发广告的公司.... 技术能好到哪去

为什么 /factor +1 比较好理解, 因为后面比较 threshold 等都是 int 比较, 刚刚 /factor 是个 float, 你后面的例子正好整除, 但是大多数不会是整数结果, 如果是 3.1, 比如, 那我们应该取 4 不能是 3, 也就是(int)(3.1+1)

另一个为什么不把自身的 size 加上. 我理解是当 s 就比 threshold 大了, resize 的 requirement 的概率就很大(并不是 100%), 而且 the more empty the table is, the cheaper the resize() costs. 所以提前 resize(), 因为 resize 是按照 2 的幂来的, 后面 put 是否需要不一定. 如果加上自身的, 即使> threshold, 虽然可能也会需要 resize, 可概率不如不加大, 所以就等到需要的时候再进行. (这是我的理解)

至于你 concern 的那个 "可能在最后的循环里的某个 putVal 里，又会再次 resize 啊" 这个对于加不加自身 size 几乎没影响. 如果需要后面再次 resize 的情况, 你＋了自身 size 判断, 一样会需要再 resize.