1. 恕我直言,杭州就没有人均一百五以下的好吃的餐厅
如果你们能说出来,我就在评论里找个女孩子一起去吃
17 篇热帖
最近终于把文档的本地化做好了,立刻加上了中文文档,欢迎大家阅读和使用。
最近很郁闷,给同事一台主机增加一块硬盘扩充下容量,然后就再也点亮不了了,电脑昨天还是正常的。
然后就一个个排查,打开机箱,发现显卡风扇不转。
1.我初步觉得肯定卡在开机自检哪个不对,一顿插拔内存操作还是不行
2.接着就拿了个好的显卡插上,不行。
3.换其他电源上去也不行
4.想到 cpu 自带核显,拔掉独立显卡,接到主板接口,也不行。
5.此时 cpu 风扇是一直在转的,但是进不去 bios,显示器没任何反应。再次觉得大概率主板问题,身边没有这个平台主板,只能京东下单一块
6.今天主板到了,装上去后还是不行,郁闷至极。为了不影响同事工作,先把系统盘,硬盘装到其他备用机器了,从 intel 换到 amd 居然没有问题,系统可以开起来。嗯,先不要耽误别人工作。
7.然后回想下,难道 cpu 坏了,按网上方法,散热器不压在 cpu 上面,开机几秒后,摸一下温度,确实没有温度。我不清楚这样是否就可以判断 cpu 坏了,但是其他都排查了一遍没有问题。
到现在耿耿于怀,为啥加个硬盘会把 cpu 挂了。目前 cpu 基本买不到了,只能搞板 u 套装了,真的是折腾。
今天想着试用下 WSL2,然后按照 docker 官方文档下载安装 desktop 版本之后,再 WSL 中 build 一个 image,无法成功,后来 docker desktop 直接 crash 了。
算了,不折腾了,还是用虚拟机吧
主要是 zoom.us 和一些中国人比较多的国外 edu 网站,比如澳洲的学校。

链接: https://www.macrumors.com/2021/08/13/federighi-confusion-around-child-safety-details/
看了一下,大意理解是 iCloud 的匹配阈值是 30 。即如果你的 iCloud 图片库有 30 张以上与 csam 的数据库符合,就会将你的账户标记交由人工处理。
如果是 iMessage 发来的图片则会在本地算法进行匹配,有问题的图片会做模糊处理,并在儿童查看真实图片的时候发送通知给家人。
如果理解有谬误之处,欢迎指正。
偶尔有需要访问内网 windows 的需求,虽然能直接开放 3389,但前几天也看到 V 友有 RDP 被攻击的帖子。
目前我的解决方案是即用即开,用完就关。但还是过于麻烦。
试过用 SSH 隧道,但发现 RDP 没办法配置代理。
还试过 OpenVPN,但不知道是不是被检测到干扰的原因,配置完之后的一段时间整个网络非常差。关掉之后一段时间网络又恢复正常了。
想问一下大家用的哪种隧道技术比较好?

在外国用过 swiffer 的这种一次性拖把,十分方便,国内也有代购,就是太贵了。所以想找个国内品牌的替代品,不过看品牌太杂,不知道哪个好用点。
要求主要是替换的湿巾要足够湿,然后拖把杆质量好点(当然如果湿巾能和 swiffer 的杆子通用也可以),不然反而更麻烦了。
不知道在 v2 的各位有人了解嘛?当然有比一次性拖把更好的方案也欢迎推荐
比如访问的网址是 https://www.google.com/search?q=小姐姐
那么网管都能看见啥?
定制设备,用户反馈用时自动关机 机器拿回,无论如何无法复现问题,换了好几台新机器还不行(电源键真的没有卡住,电池有电 让用户找了朋友测试,不关机(用户离机器 10 米距离 真的会有这种灵异事件吗? 大佬们怎么解,怎么排查
现在挺缺钱用的,但是找不到什么正经工作,外面也没什么人了,找不到什么方法赚钱。
不想去送外卖,想呆在家里混日子。有什么靠谱点的方法吗?
上网经常看到一大堆的软文。那些东西有什么渠道接单吗?
收到一个安全监控警告:

高亮部分就是一串命令,用 gitlab-rails runner 执行了一个创建管理员的命令!
gitlab 版本是 CE 的 13.10.2
里面的项目,没有用过 hook,也没有用流水线,因为团队的都不会用。
目前对于这个安全事故排查毫无头绪,完全不知道怎样注入,怎样执行的,有无大佬指导一下(哭
只有我觉得我们项目经理整天不着调吗?项目项目不抓,很多时候改了需求同步给我们都是滞后性的。项目经理感觉更像一个小组组长,而我们的产品经理却一直在跟进我们的项目……
看不到任何希望
不讨论针对用户行为的埋点日志,仅讨论业务日志。
待过两家公司,完全不同的日志策略:前者是内容平台(也是创业公司),基本上能不打日志就不打,只打一些异常日志;后者是交易平台,基本上所有用户请求都要 trace,每个请求参数,返回值的关键信息,除了集合类型的数据,其他数据都是尽量落日志了。
我总结了下,前者因为是内容平台,内容多寡、精不精确,对用户其实没有承诺(当然用户会用脚投票),真有问题就让用户重新操作下就可以了;而后者因为涉及到交易,需要对交易链条上的每个环节负责到底,无论是因为用户操作不当还是系统问题都需要给出合理的解释。前者没有一个客服,后者一大帮客服。前者平台跟用户是互利的(流量换内容),后者用户是平台爸爸。
思考:用户对产品的认知有差异,产品越简单,这种差异越小,就越不需要客服,也就越不需要日志。减少日志的办法可能还是简化产品逻辑,使之符合更多人的预期。
正常业务流程 info,业务异常 warn (可能是参数不对或者不能满足一些业务条件之类的),这两种都属于正常情况,ret=0,表示结果是可用的,前端可以直接展示给用户。业务异常不能打 error,否则会有大量报警。
只有系统异常(如超时)才打 error,ret 不等于 0,表示结果不可用,前端可以根据 errorcode 判断是要重试还是怎么处理。这种异常会报警,可以标识服务的状态。
errorcode 也是一个值得讨论的话题,不过这贴先不讨论了。
不知道 XDM 在项目中是如何实践的,欢迎分享讨论