pc 上各种破解片 /精简版 /汉化版等,到处都是.
有些还专门注明了, 杀毒软件可能提示是病毒, 大家要忽略.....

android 也差不多, 在某些论坛下载 apk 的都很多, 然后各种市场, 某些市场还支持用户上传破解版...

我以前去的时候, 基本上没有问啥技术问题.....
问的都是些类这样的: "如果你带的徒弟在技术上超过你了, 你怎么看?"

一直在用 cifs 。系统自带。

差不多. 可能还低了.

我的标准: 有独立的办公室..

现在很多公司都号称开放的办公环境, 其实就是弄成格子成本低..

早点走人吧, 发工资这么基本的事情都能拖...

林子大了总是有那么一些公司...

我说个遇到的奇葩面试者的:
面试我们都是从基础开始的, 有一个从某著名 it 公司出来的求职者, 面试我们的高级开发工程师, 我问了一些基础问题, java 的, 比如 static 关键字能修饰什么, 有什么用之类的, 他一个都答不上, 然后来了句,你们能不能不要老整这些简单的..... 然后就没有然后了.

说实话, 我遇到的比较牛的技术人员, 基本都是基础很扎实的. (除了几个数学专业过来搞算法的..)

楼主遇到的这种, 我觉得这个公司的面试流程有问题.
我们公司是, hr 筛选简历->开发筛选简历->hr 联系电话技术面试->电话技术面试->hr 联系来公司面试->发 offer.
基本上来公司面试的人数非常少, 大部分都被前面几步排除了. 比如我前一阵电话面试了几百个, face to face 的大概有不到 20, 给了 offer 的大概有 5 个左右.

年纪大了, 感觉已经折腾不动了

以前住在福田口岸附近, 那个时候我租的房子的小区房价是 3w 不到, 现在估计涨了很多...

ps: 当时寨都很多同事都在存钱准备买房, 有不少应该悲剧了...

先在 windows event log 中看看..

我们在用 jive

Why does Go not have exceptions?

We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.

Go takes a different approach. For plain error handling, Go's multi-value returns make it easy to report an error without overloading the return value. A canonical error type, coupled with Go's other features, makes error handling pleasant but quite different from that in other languages.

Go also has a couple of built-in functions to signal and recover from truly exceptional conditions. The recovery mechanism is executed only as part of a function's state being torn down after an error, which is sufficient to handle catastrophe but requires no extra control structures and, when used well, can result in clean error-handling code.

See the Defer, Panic, and Recover article for details.

VDI 方案中的 vmware view, citrix xendesktop 还有国内某家的基于 xen 和 citrix ica 的方案我都用过, 还参与过部分的开发.
自己也吧 vdi 当作主要工作环境用了有 2 年多.
主要的问题:
1. GPU 虚拟化加速还不是特别成熟, 对图形要求高的基本上 vdi 满足不了
2. 动态画面和语音的传输, 我当时用的 24 寸的显示器, 基本上普通办公写代码什么的没啥问题, 感觉不到慢, 某公司有专门的团队做视频 /音频优化, 最终效果是特定的应用解决了卡的问题, 比如视频播放, im 软件的网络电话会议.
3. 存储, 我们当时主要的成本还是在存储上, 为了存储的安全, 某个方案用的是 server 本机的 raid5+nbd 协议. 存储的成本还是很高(每个 vm 分 200G 的数据盘情况下....). 如果用 san 之类的估计会更高.
存储性能也是个问题, 总体来说比本地硬盘慢一点.
4. 成本, 根据某公司内部计算, 接近 10000 个用户的环境, 平均每年每台机器的成本 1w 左右. 算下来还是挺高的. 虚拟机的配置: 4vcpu, 4G memory, 200G 硬盘(数据盘, 操作系统在另一个盘上, 用 linked clone 方式 /或者 gold image, 内容放在几台专门的机器的内存中), server 的配置: 双 cpu, 192G 内存, 12 块硬盘, 硬件是公司定制的, 操作系统安装在个 flash 卡上.
5. 故障问题, 我们当时的环境中, 遇到过几次故障, 比如交换机挂了, backup 出问题, 几百人几小时无法办公, 技术支持被骂惨了.
6. 技术上还有各种限制, 特别是规模比较大的环境(2000 以上的用户).

好处:
使用比较方便, vdi 客户端用的是自己开发的 arm 盒子.小巧不占位置. 打开就能, 不用关机什么的.
管理方便, 比如软硬件升级扩展, 新员工入职之类的.

总的来说这是未来的趋势.

以前看到过汽车的.... 大概是一直交月供, 每过几年可以换新车(某个价位以内的)

如果想比较准确的估计.
1. 平时把任务细分(每个任务可以在 1-3 天内完成)
2. 每个任务做 estimation, 并且估计大致实际完成时间, 慢慢就能比较准确的估计了

当然最好用 JIRA 之类的 project tracking 平台

windows event log 中查.

还是要看具体的应用. 比如有人需要 redis 高速处理请求, 然后 sync 到 mysql 做一些 sql 查询.
Redis 的持久化有 rdb 和 append only file
RDB 定时(一般比较长..)刷到磁盘, 丢数据的风险比较大. 当然有些应用是可以忍受这种级别的丢数据的. RDB 加载很快.
Append only file 貌似每秒 fsync 一次, 没看过具体的代码, 不知道开启了对请求处理速度有没有影响. 这个也会丢数据, recover 速度比较慢. 不过大部分情况下开启 aof 就够用了. 除非有 sql 查询的需求.

以前我设计开发过一个 key-value DB, 丢数据 /性能权衡的问题非常麻烦...

上面的都是根据比较老的版本的, 新版本可能有更多的功能.