你明白个屁。

OneDriver 、坚果云：云上个人存储，数据上名义、实际、设计目标都完全属于个人，在后台数据用户级别隔离，空间大小就是实际存储大小，数据读写速度主要依赖于本地网络环境，次要依赖服务器的带宽成本。
百度云、阿里云、还有各种几把网盘：共享存储，仅名义数据归个人，实际数据归服务商，后台数据无隔离，空间大小只是使用配额，数据读写速度完全依赖服务器的带宽成本。

共享存储照样能做同步，只不过它不愿意做而已。

省流翻译下一楼主的需求：善人，你那健康青菜稀米粥，你乞丐爷爷不需要健康只在乎稀，请换成白面大馒头，另外你小爷我腿脚不好，请端过来。

@FreddyLiu #23 不要低估人心的险恶，别说三个月，他离职前都转不了正。

细追究的话，一大堆违法的事，捅出来能让你公司弄到破产。故，懒得细追究了，其他人也说得差不多了，根据个人经验，说点法律之外的社会事。楼主这种情况，基本就这俩场景了。

第一，HR 本身就在参与骗人，这就是典型的「高薪招聘但实际发低薪」套路。这个套路具体来说，就是招聘的时候仅口头承诺高薪（相对被招聘人的期望来说，一般相对好的公司的时候并不高），然后一边各种理由不签劳动合同或者劳动合同上不写口头承诺的薪资，一边各种理由大比例——至少 20%，50%是常规情况，80%都有可能——扣工资。延后试用期还是相对不那么抽象的扣工资理由，还有更多只有你想不到没有他办不到的理由，比如：迟到超过半小时即算当天矿工；迟到累积三次算矿工一天；矿工一天（即迟到三次）扣三天工资；矿工两天（即迟到 6 次）扣半月工资；卫生检查不合格（是否合格全凭检查人的嘴）两次即扣全月绩效。

第二，更严重的，HR 也是被坑的，老板是个傻逼。要么老板是故意对 HR 模糊招聘标准，等人进来俩月该发真正工资的时候对 HR 让 HR 去背锅。要么老板自己就对招聘成本没概念，等到发工资审批的时候才发现拿不出/不想拿那么多钱，于是推出 HR 来背锅。能跟这种老板混的 HR ，当然也不会是啥好人，自然不会资源背锅，自然就会招各种理由扣钱。

不要以为以上两种场景，是瞎编的。那都是个人经历，和面试别人的时候别人的过往经历。基本上，当对面公司是 20 人一下规模的小作坊的时候，大概率会碰到场景二。而如果你是刚工作没几年的人，或者虽是老油条但急需工作的人，就很容易中招。场景一在公司规模上没啥规律，100 人甚至上千人规模的公司都可能这么搞。如果存在不发 Offer 、入职前几个月不签合同而是签其他协议、入职冷静期超过一周、入职两周了还不签合同、合同上不写最初口头承诺的工资等骚套路，那这种公司，不是已经是场景一，就是在往场景一的路上。

好吧，我有给找了下资料，结合回忆，发现很简单：
双圆圈（◎）非常适合/强烈肯定，
圆圈（○）适合/确定，
叉（×）不适合/否定，
三角（△）介于圈叉之间

复杂变态的是 PS 手柄上的标识。原本 XX OO 还能对得上，现在改的是疯牛乱马。

不过这个标识啥意思我还是不知道。

日本人特有的符号表示，通常代表确认程度，并不是简单的对错，而是涉及到对和错之间的程度，非常复杂和变态。PS 手柄上的都已经是简化过的。

具体啥意思我就不清楚了，需要一个日本人，或者对日外包开发老手来解答。

项目经理就是盯进度和调配资源的，并且拿大头的，但同时也是负责背锅的。

如果只有前两个没有第三个，那么趁早跑，这种沙雕要么自己就走不远，要么你跟着他汤都喝不上。

如果只有一、三，没有二，那更得趁早跑，这就是个无能之人，跟着只会倒霉。

但如果项目经理同时是领导，这个就不用看对方是啥了，要看你自己，你要是准备当跳板往上爬就跟，准备只是混口饭吃就躺平，准备个人自我发展就赶紧跑。

楼主第一爆：正常的过保不做售后，因为没被当天龙人对待而发脾气。
楼主第二爆：打个电话就想让 4S 店给出维修保价。
楼主第三爆：一毛钱还没给，人也没进店，一句能接受付费的空口，就想让 4S 店给出为他量身定制的全套配件/服务价格表。

这种人，无法对话，建议眼不见心不烦。

@ReZer0 #14 这么明显的漏洞、这么容易用行政手段封堵的漏洞，不堵上，你真把广电的人当傻子呀。还是说你以为工信部都爬的广电，腾讯这类「民营」能不怕。

屠你妹的龙。

微软为了 Windows Live - Microsoft Account 这一条线收购的 Homtmail ，而 Gmail 就是为了 Google Account 才诞生的。如果你把 Gmail 当传统 E-mail 看，那这是初代互联网的非中心架构，没有龙。如果你把 Gmail 当作 Web Mail 看待，那它诞生的时候本身就是龙。

@myimee #19 你那几个，貌似都有内墙。换 Firefox 试试。

Windows 你的手机 + Android your phone ，仅限三星等少量品牌手机。

不过，如果你是上班需要上交手机的公司，建议遵守规定，或者更换单位。

@standchan #3 首先来说，现在族谱都没了，关心是堂还是表，其实也就乐和乐和，没啥实际意义。

如果要分析堂跟表的关系的话，首先得区分不同的家族。只有仅经父系血亲关联的，和他们的直接亲属，才能算做本家或主家（直系和三代以内为主家，三代以外为本家，另外，一般五代以外直接除血亲啥都不算），这其中，女性也只有出嫁前才算，出嫁后转到其他家族了。举例：你跟你爷爷是主家，跟你叔伯是主家，你奶奶和婶娘因为爷爷叔伯的的关系也是主家。当你的姐妹（亲姐妹）、你叔伯的女儿（堂姐妹）、你爷爷的女儿（姑姑），未出嫁时，算一家，出嫁了就不再是一家，而是别家的了。通过你母亲关联的姥爷、姥娘、舅舅舅母、姨母姨夫、姨姥爷姥娘、舅姥爷姥娘一脉，不是本家。通过你姑姑关联的姑夫、姑丈一脉，不是本家。通过你奶奶关联的姨爷姨奶、舅爷舅奶一脉，不是本家。

当你区分好家族之后，再区分堂表就好区分了。同辈中，主/本家的是堂，主/本家以外的是表。

在线离线的变更，你要用连接打开、关闭事件，以及心跳事件来触发，不要依赖业务数据上报。

要是追求强一致性，那就让 IOT 服务器先自行管理在线设备集合（一般你要有下行数据需求的话，这个是必须的功能），每次查询时，基于 IOT 服务器汇报的在线设备集合，来计算待查询设备集合的在线状态。

要是不需要强一致性，那就是你的方式 2 。

至于性能开销，实际上没法直接评估，这个是随环境变更的。比如上面俩方案，第一个性能耗费在数据读方向上面，第二个性能耗费在数据写方向上面。如果平均每设备每天上下线 1000 次，则第一个方案性能好。如果设备一两年才上下线一次，则第二个方案性能好。

给你个示例：十几年前用迈克菲的时候，个人版（也是付费的）不允许你设置例外目录，会亲切的提示你「迈克菲已自动处理威胁，无需你的参与」；但是企业版是允许的。

他们不让你强行高清晰度，实际上就是不想让你强行高清晰度。强行高清晰度应该是对服务器有负作用的，具体如何要等技术大佬来解释。

如果你发现，稀土掘金已经是相对来说最好的那一波，你会更气的。整个中文环境都是内容农场了，还是趁早学会读英文文档吧。