unsigned = unsigned int

:1 = bitfield

陈茂蓬

打洞 http://samy.pl/pwnat/

who cares???

“无类型纯文本有缺点，有类型数据有优点，所以要有类型”，那你需要类型的时候就去用类型好了，这没说明为什么需要不该纯文本。

纯文本是给肉眼看的，加上了类型，肉眼就看不了了。

@dnser 干。打广告有点节制

铁道部会不会把自己的密钥开放给工信部使用？

优化png基本上是这几个方面：

1. 减少颜色数量。比如24位色深RGBA每个像素压缩前要4字节，通过颜色量化算法提取出256种常见颜色作为调色板，那么1个像素就1字节。这个的颜色量化，必然是有损的，只是说通过图像质量的较少损失换取较多的空间节省。这里有pngquant用中位切分算法，pngnq用神经网络算法。颜色量化另一个复杂之处是对于怎样用较少的颜色dither出较好的渐变效果。
2. 去除png文件格式中非必要的数据块。optipng做这个事情。
3. 图像预处理过滤调优，通过类似相邻像素查分的方法，让图像数据更适合压缩。optipng。
4. Deflate优化。zlib的deflate算法通用压缩器都可以加入使用。advdef/advpng使用了7zip的优化deflate，PNGOUT用了一种私有的Kflate。3月份Google发表的Zopfli原则上也可以整合进来。encoder.ru上还有一些私有的号称更好。

后台使用开源组合 pngquant + optipng + advdef/advpng

有一些私有程序号称更好 一个评测：http://css-ig.net/png-tools-overview

对了，调试实验的时候打开ccache可以大幅提高重新编译速度。

内核panic只打印一串函数调用栈，内核开发者光看这一串调用就能看出问题所在。为什么？因为他们非常理解在问题发生路径上这些函数应该做什么，不应该做什么。debug最终是要理解代码的目的，发现程序体现出什么与此目的不一致的状态，才能真正解决问题。用debugger补东补西只是治标，不能增加对程序的理解。

我采取的一般做法是：发现症状以后
1. 找到发生症状的代码位置（看日志、core）。
2. 理解上下文代码。
3. 根据症状对问题发生的位置、原因提出几个快速猜想。
4. 实验重现，在相应的地方查看程序状态是否符合设计，猜想是否成立：
5a. （对于小程序）如果没有猜想成立，在代码调用流程上加printf做二（多）分查找，缩小范围，直到找到某一处程序状态不符合设计，转3。
5b. （对于大程序）如果没有猜想成立，按照代码提交历史作二分查找（git bisect），直到找到两个相邻版本不一致，查看差异代码，转5a或3。
6. 猜想成立，修复，再重现一次验证修复。结束。

其实这就是分治法+科学方法
https://en.wikipedia.org/wiki/Scientific_method

调试工具主要适用于难以通过修改程序来实验测试猜想的环境（比如生产环境，特殊架构，特殊设备，自动化）。

对完美主义者来说，应该这样想：先花一个小时做出一个屎一样的原型（好听点叫Minimum Viable Product），做出来了再说别的

6ae5fced33a9ef1e
d9557e713244f65b
861097c6dbbb6bb0

@rrfeng pxe属于机房技术一种，因为需要配置局域网的dhcp和tftp服务器。

就把pxe下载的启动镜像直接往sda一dd，跟pxe效果是一样的。

安装和kickstart配置可以在虚拟机里面测试无误之后再部署，还不至于没有尝试的余地。

虚拟机里装是不行的，因为硬件不一致，最关键的，虚拟机里网卡与物理机网卡是不一样的，这样装了之后机器起来由于网络配置不当可能没有网。

理论上，要安装必须要让BIOS把Linux安装环境引导起来，这样看你BIOS支持哪些启动选项。假如不知道，就先假设是从MBR引导，那就需要把MBR修改成引导grub，然后grub把内核引导起来，然后再起自动安装环境，自动配置网络，从网络下载完整文件，无人安装完毕重启。

这个MBR+grub+安装环境合起来叫安装镜像，原理上直接dd到/dev/sda下就可以（要虚拟机先测试无误）。只是windows下怎么直接写硬盘不太清楚。

风险大。因为步骤很多，有任何问题导致最终系统没上线，就变砖了。部署前需要谨慎或者仿真测试。