我上周把一台 11 系统的老机器升级了，系统里找到的升级只能升到 14
所以先升到了 14 ，然后从 14 升到了 15

看 7000 是个什么条件的房子。我之前 2 年时间每天通勤两个半小时，人都快抑郁了。后面跳槽搬家，现在骑车到公司 10 分钟，每个月房租 6400

感觉没有变卡，也没有明显的发热，也没遇到明显的 bug ， 不过相册是真不习惯

主界面左上角配置名-外部资源-全部更新

中厂跳进大厂的来答一下。

我们应该算是公司里的中流水平部门，主要用 C++，没有什么很崎岖的要求。我们不怎么要求学历，不怎么要求年龄，也不要求手撕算法题，有一定时间的 gap 也可以接受。学历和年龄都是能过 HR 那关就行，本科就给面，不要求 985 、211 和必须 cs 专业。年龄方面和职级不能差太多，否则就算我们业务部门通过了 HR 也不给过。最近我面过的候选人一个是 34 岁一个是 36 岁，年龄更大的我就没遇到过了。

但是我们需要背景和经历比较匹配的人，同时基础方面需要扎实一些。我面了几十号人了，校招社招都有，社招候选人基本都是小厂出来的人，背景和经历上能非常匹配的人很少，这种情况如果基础够扎实也是可以考虑的，但是基础方面能称得上扎实的一只手数都绰绰有余。。。

这里的 “基础扎实”，并不是要求八股文样样精通，但是线程和进程的区别这个题都能难住我一多半的候选人，这是比较让我吃惊的，其中甚至包括工作了快 10 年的人。。。

@longgediyi999 我是手持 wh xm5 等 airpods max 2 的，现在一整个尬住了。。。因为生态问题想换 airpods max ，现在是换也不是不换也不是

被苹果生态绑架的用户在此
反正没有完美的设备和系统，苹果的东西经常能遇到一些细节让人很抓狂
只是相较起来安卓更让我不能适应

本来准备发布 Airpods Max 2 就入手的，现在有点儿纠结了

首先去北上深，你的目标就完成了三分之一。其次进大厂，基本又完成了五六成

等 Apple Watch （之前戴的丢了，等半年了）和 Airpods Max （现在用 WH1000XM5 ，但是在各种果子设备里切换太不方便了）。另外也期待一下 Airpods Pro ，虽然我觉得今年不会出

我是渣二本毕业，比楼主早来上海一年，今年已经是第九年了。基本从毕业时就一直 996 到现在。

工作后的前四年是又穷又累，看着房价的上涨速度和收入的上涨速度发愁，曾经一度觉得自己不适合干程序员这个行当，在考虑要不要回老家混吃等死。不过好在第四年开始也算时来运转，基本每年都有可观幅度的薪资上涨。目前在某大厂当大头兵，将将达成楼主第一句话提到的装逼存款数额，前两年也人才引进落了户。

不过虽然落了户，首付也有了，但是我现在依然在犹豫要不要留上海。。。我现在对未来最大的预估，就是再干几年被裁失业，同时也没什么进取的野心了，带着存款回老家省会随便混混得了。。。

我今天才在项目里看了一段代码，写代码的人想从一个 uint8 的 TArray 里取出二进制的数据传给 lua decode 接口，他遍历了一遍这个 TArray ，每次取出一个字节并用 .. 拼接到 lua 字符串上。。。

@vk42 轻便摩托车也不允许带人

对我来说，esim 唯一一次派上用场的时候，是我出门丢垃圾忘记带手机和钥匙，用 apple watch 给我妈打电话让她送钥匙过来。。。还有我一个朋友，一起出门旅行，分头行动时，他手机摔坏了，用手表联系我打车过去救他

@hushiwei 是啊，我面过几个沟通起来很顺畅的候选人，但是基础不是太扎实。。。我感觉态度挺端正的，对我们部门的意愿也很大，想着还是放进二面得了，但是和领导反馈沟通后，还是觉得基础不扎实，可以等更好的，把人选给放弃了

@darksword21 我刚开始当面试官的时候也差不多，不知道该问啥，自己找了一堆八股题挨个顺序问。。。面的多了就有点儿经验了，一般就先和对方聊一聊项目经历，就算自己不懂对方的项目也没关系，让他先给自己介绍一下，然后问他项目的主要流程、架构设计，再挑出自己觉得可能是关键的地方详细问问是如何思考的。然后再问问一些经典题目，高可用、容灾、负载相关的东西是怎么考虑的，最后还是要问一些基础八股文的题目探探对方的基础

看价格了，我以前在小城市，自习室一个人半年 500 块，去的人很多，主要是学生。上海的自习室我也去过，一天好像就得六十，长期用下来还是太贵了，周末偶尔去的人又撑不起运营成本吧。后来开了半年多就倒闭了

@DOLLOR 这是苹果的 APFS 文件系统的功能，但是它并不是“完全相同的文件，只会存储一份”，而是“同一个文件的拷贝只会存储一份”。也就是说你从网上下载 N 份相同的文件，因为它们之间并不是“拷贝”的关系，所以依然会存储 N 份

你组长说的挺对的，你要是自己私下去学习，那尝试性地修改、边写边了解虽然效率不高，但是也没啥大问题。但是正儿八经工作、写业务用这个方式，风险很大，一个是代码质量上的风险，一个是延期上的风险。你就想想，如果有代码 review ，被问到你为何要做某个修改，你是解释说 “之前的流程和逻辑上是 xxx ，所以这里要达到需求要做一些修改”，还是 “这里好像和需求有关，我想试一下在这里改改能不能行”？