qyb的博客

https://lists.linuxcontainers.org/pipermail/lxc-users/2014-April/006554.html
里面提到，RHEL7 因为安全原因，禁用了user namespace，但有望在以后的更新里（7.1？）里启用它。

https://bugzilla.redhat.com/show_bug.cgi?id=917708 展示了从去年3月，Fedora的开发者对于user namespace的考虑

1. Comment 1说的是当前的代码除非disable XFS，否则是不能打开USER_NS的。
2. Comment 4说的是3.9的合并窗口期已经过去，XFS对USER_NS的支持已经加不进去，只能寄望于3.10了
3. Comment 5说的是USER_NS相关的实现还有很多安全问题，比如clown-newuser.c就展示了本地提权的漏洞
4. Comment 7说的是终于XFS不是障碍了（这个时候已经是3.12），但为了更安全，可能得修改代码，只让non-privileged用户使用相关功能

结论：缺乏商业能力的使用3.12之前内核的发行版（包括使用3.11内核的Ubuntu 13.10：http://blog.tutum.co/2013/12/14/enabling-the-user-namespace-in-ubuntu-13...），都不会直接支持 user namespace 的。但可以相信未来 RHEL7 会把内核最新的变更backport回它的 3.10 tree，为此特意在当前的代码里启用了 USER_NS以保证和未来的内核版本ABI兼容（只不过在 create_user_ns 的内部，第一行直接粗暴得返回 -EINVAL 了）

一方面是谷歌的研发，另一方面传统汽车行业也开始引入线控技术，比如Q50

五年后，无人驾驶汽车开始商业化

十年后，加州政府举办算法大赛，利用大数据调度红绿灯系统，以减少整体交通拥堵时间

十五年后，北京推出无人驾驶出租车，享受公交车道待遇

二十年后，阿里承接了杭州市的CCAV项目，包括把城市交通流量系统 API 开放；高德导航第一个支持

二十五年后，大部分司机仅仅只是在进出停车场、地库的时候才控制汽车

晚上找了一下 .NET 的资料，发现 3.6.0 版本的 mono 刚刚发布没几天，在 HN 上有这样的讨论：
A: Here it is a good business for the "new" "21 century" Microsoft. To put their language into Mobile, OSX and Linux.
B: If they do succeed I seriously think it could be the end of Java.
C: Yes, Java is basically new COBOL...

很好奇居然有人这样形容 Java，因为中午刚刚有人给我断言 .NET 是一个要退出历史舞台的技术。于是去研究了一下 mono/.NET，有以下印象

1. mono 项目背后的公司，Xamarin，和微软走得很近，包括刚刚接受了一家微软背景VC的投资；也许 mono 是一个靠谱的项目
2. Xamarin 的商业模式是移动设备，用 C# 同时为 Android、iOS 开发应用。对于现有的大量的 C# 程序员来说，是一个好事情
3. 以我目前有限的认识，ASP.NET 大概是类似 Java Servlet 的东东；ASP.NET MVC 则可以类比 Struts 这样的 MVC 框架；Entity Framework 类比 Hibernate；Web API 貌似是一个写 Service 的框架；Web Forms、Web Pages、aspx、razor 什么的还没有弄明白
4. NuGet/MyGet 类似 npm、pypi，感觉现在 .NET 的生态也在不断的发展
5. 国内颇有一批人（大本营是博客园？）在研究在 Linux 上跑 ASP.NET，http://www.jexus.org/、http://www.linuxdot.net/
6. ASP.NET 的下一个版本，VNEXT，旗帜鲜明得指出了：
   1. 要为服务器优化、为云优化
   2. 要和 mono 紧密合作，确保能运行在 Linux/Mac 上
   3. 每个app部署的CLR的隔离，这个功能对在单一 Windows Server 中运行多个 app 还是很有用的。另外演示中的工具被起名叫 kvm

隔行如隔山，不明觉厉

这两天，连续听了包括唱吧、新浪、UCloud、一号店等等大佬的分享，收获颇大

以前只能从内部看搜狐的业务，看各个事业部、频道起起落落。一个是眼界狭隘，另一个是方法固化。现在对别的公司有了更深了解之后，再回过头来想搜狐做的事情，也是觉得越来越能摸清楚各个领导、参与者的想法。对参与的种种项目，此时琢磨又有了新的认识。
感觉不能再从传统媒体招人进来了， 没有互联网产品意识的人，无法再造搜狐。

能来北大CIO班的，此时多数应该都是处于职业的天花板状态，能相互启发学习，非常有必要。以后也想办法安排其它同学的交流机会

参考一下人家是怎么评估组织的能力的

Ability to Execute：

1. Product/Service, 产品/服务的能力、特性、质量等等等等
2. Overall Viability, 财务健康程度，融资能力，生存能力
3. Sales Execution/Pricing, 渠道/销售/售前的能力、定价权
4. Market Responsiveness/Record, 捕捉市场机会、竞争求胜的能力
5. Marketing Execution, 市场营销能力
6. Customer Experience, 客户体验，尤其是客服、技术支持的能力
7. Operations, 运营能力，为完成目标而优化的组织结构、流程、系统

Completeness of Vision：

1. Market Understanding, 理解(深化)客户需求并提供产品/服务
2. Marketing Strategy, 能够清晰、差异化地定位，并有效传达客户
3. Sales Strategy, 卖货的战略
4. Offering(Product) Strategy,
5. Business Model, 商业模型的靠谱程度
6. Vertical/Industry Strategy,
7. Innovation,
8. Geographic Strategy, 面向不同地域的战略

类似的问题在 Linux 身上肯定是出现过，而且今天看，Linux 显然是搞定了这件事情。假如我们认定大中型企业会走向私有云，而且开源系统必占有一席之地，那就好好回忆一下 Linux 是怎么踩着这些坑一路走过来的。

红帽现在6000名员工，收入是十几亿美元，净利润是10%；Facebook 也是6000名员工，收入是红帽的十倍。做IT服务的创业企业，首先要想明白自己要成为一家什么样的公司。UOS 原来的路径，可能需要5年的努力，才能见到曙光。

还有一个VC预期的问题，类似的业务，在没有明确的正向现金流、客户群体起来之前，找VC可能不是好时机。

关于 IaaS/PaaS

1. 近1-2年，中国可能不存在足以让真正的私有云产品生存的市场（IaaS/PaaS）。
2. 可用的私有云产品或服务市场都没有，大中型企业会真心拥抱公有云吗？从我目前得到的信息看，公有云都是在卖网络，而不是在卖计算和存储。
3. 从互联网的本质——“建立连接”——这一点来说，很可能卖网络是最大增值的地方。
4. 都在说存储未来会是免费的，计算会不会也是免费的呢？

搜狐的企业网盘，目前看，基于网络的服务包装，确实也打中了用户的痛点，是它的私有云很难搞定的

1. 最近少有的在微博上和人争论，而且对方的论点我都同意，所以要记录下来。http://weibo.com/1402551940/BdI3kjPmM
2. QingCloud 的黄允松在朋友圈吐槽UI、术语被抄袭，说的应该是本周发布的 UOS 2.0，从私有云走向公有云和托管服务。
3. OneAPM上线，中国版的 New Relic，基础收费是每节点每月99。找了一下当初 PaaS 计划的标准，是每个core每月5元，收费差不多

整理一下他的观点和透露的信息：

1. PaaS是中间件的云化平台
2. 所有公有PaaS到目前为止都是失败的
3. PaaS作为平台性的项目，落地很难，周期很长
4. 中国的OpenShift案例
   • 香港城市大学
   • 在跟进若干大陆制造业的客户
   • 在和若干金融业的客户研讨
   • 有一个快递业的客户，300多个应用，600多台服务器
5. 洗脑：如果OpenShift还解决不了运行环境标准化的问题，那说明这个问题就不应该试图解决
6. 国外的OpenShift案例
   • Paypal, 2013年5月，上线14台服务器，支持了400多个开发人员
   • Cisco
   • Dell
   • 注意上述三家都是RedHat的关系户
7. 1.5个运维人员可支持200个开发人员...为什么是1.5?
8. 16core/96G服务器，RedHat会跑大概100个实例。（他说公有云会跑400个）
9. PaaS公有云的两个弱点：container技术不能把TCP端口变多；很难解决ARP欺骗问题？？？
10. 最开始OpenShift Online使用了AWS的约80台EC2，现在是200个

适合不想纠结内核编译，直接 rpm/yum 升级的糙快猛解决方案

新产品是基于某个开源框架开发的，有一个至关重要的特性，需要框架底层有支持才能完成。相关的函数，就在文档里写着，但是开发同学愣是没有发现，其主管甚至做好了重新创造轮子的计划。。。幸好我特别关注这个特性和进度，也一直在关注这个框架相关的技术，当知道难处以后去把文档浏览一遍，立刻就发现了这个函数，早上来通知开发同学一测试，大功告成。

今天和人说起来，我现在就是典型的"信息工作者"，每天处理大量信息，然后产生出对工作有用的新信息出来，推动进步。只动眼睛和大脑，不写代码不动手，最后动动嘴写写邮件就是我看得见的物理产出。

文档放在那里不会用，不去读。我认为就是学习能力的问题。或者英语不好？总之不善用知识的人，肯定很难适应IT行业。

得不断评估每个下属的学习能力。。。。每次PM就不要提创新了，连学习都不行，还搞个屁的创新！
====
但这个主管肯定是有能力的，可能是太相信手下的程序员？我觉得这又是一个态度的问题：你完全信任手下能构建好相关的知识体系吗？是否轻易得把这个性命攸关的因素交托在他人手上？

作为技术主管，除了完成绩效、确认手下都在正确出力之外——这也是包工头的工作模式——还需要为个人怎么去学习和发展头脑、团队如何做好知识管理而努力