@neoblackcap 那就看住过一段时间后房价上涨不上涨了贝。拆迁确实能得钱，但是拆迁的钱很能难在原址购买相同条件的房屋

@neoblackcap 前提是这 70 年你的房屋仍然质量不错，或者你要搬迁的时候房价没有上涨。

我觉得你可以先一周不上 y2b,fb,tw,g+,google,
只上 weibo,看 youku ， renren,百度
比较一下

windows 自带 dns 缓存，不必太关心延迟问题。要是 linux ， dnscrypt 或者 chinadns 都不是缓存的，需要一个前置缓存。 如果追求国内 CDN 同时国外无污染，可以尝试 dnsmasq-china-list 列表内走国内 dns ，其余走 dnscrypt 。或者 gfwlist 走无污染，其余走国内 dns

开机时候狂按 c 即可进入 grub 命令行
启动参数加上 systemd.unit=resume.target
启动即可进入最基本的 shell ，然后直接修改重启即可

@datou 我确实没有实际的设备测试，只是根据 PAE 计算

@imxieke 类似的遇到过，进不去桌面系统只要逐步检查出错的软件是哪个就可以了。不论哪个发行版都有可能。

ctrl+alt+Fn (F2 ， F3 什么的随便试)，
命令行登录，然后重新安装出错的桌面环境即可（也许是 gnome3 ）。
如果你不知道你用的是什么桌面环境那就装一个临时的桌面环境比如 lxqt 什么的临时登录一下，然后再慢慢找你出错的桌面环境是什么。

上面写错了...应该是 64G

根据 intel ark 这个 U 支持 36bit PAE ，因此支持的最大内存应该是 16G ，

https://rog.asus.com/forum/showthread.php?3039-G53JW-XN1-Conflicting-info-on-*actual*-maximum-RAM

Alot of ark.intel's stuff shows only what is supported (guaranteed to work), but not what actually works. Case in point: my core i7 2630QM chip was reported to support max 8GB RAM on ark.intel until a few weeks after I got my G74 (October 2011)...then in November 2011 that site changed to report the chip supports 16GB. But I stuffed 32GB into my G74 anyways, and it worked. The 2nd Gen Sandybridge i7 chips have IMCs that actually can do 32GB ( http://rog.asus.com/forum/showthread...ghlight=2630QM) even though ark.intel reports them as actually only capable of 16GB max...

What I'm saying is that while 8GB *may* be the maximum reported by ark.intel, most of the previous gen i5s and i7s have IMCs that can address up to 16GB no problem (e.g. my desktop i7 860 can). So it wouldn't surprise me if the i5-460M could deal with 2x8GB=16GB of RAM. I haven't looked for 8GB sticks with 800/1066MHz speeds but if you find them and the retailer will allow a refund if they don't work, it might be worth a gamble...

你以为你是日本人吗，丢东西还有人负责找？

fuse ftp 挂载到本地

@xiaoxiaoyang 等待被其他线程的 pthread_cond_broadcast/pthread_cond_signal 唤醒。从你描述的情况来看，应该是条件变量等待导致的死锁，你需要的是回溯这些 pthread_cond_wait 的调用栈，找到调用点前的判定的条件都是什么。应该是这些判定条件彼此有循环依赖关系

valgrind http://valgrind.org/docs/manual/hg-manual.html
或者 liblockdep http://www.vctlabs.com/posts/2014/Jul/09/liblockdep/

仅提供一个思路...在无线路由里监测一下 dns 查询记录，打开 apple music 访问一下就知道访问的是哪些地址了（仅限于基于 http 的请求）。假如不是通过 http 请求传输的，那就看 ip_conntrack 中的 ip ，再通过 dns 反查来确认

jetty

可以尝试把 64bit efi shell 拷贝到 u 盘 efi/boot/bootx64.efi ，用 u 盘启动，执行 bcfg 命令或可直接修改 efi 启动顺序

在考虑性能的情况下，需要考虑你的使用模式是否是缓存友好的。
指针占用空间小，拷贝代价小，但是访问数据需要一次间接跳转，并不是缓存友好的。
struct 存在拷贝代价，但是使用时是缓存友好的。
在拥有多级缓存的现代 cpu 上，栈上的变量有很大可能完全位于缓存中，以至于小尺寸 struct 拷贝速度非常快。但指针所使用的内存可能并没有被预读到缓存中，这将导致使用指针变量反而更慢。
在这篇文章中有一段
https://talks.golang.org/2012/splash.article

The key point is that Go gives the programmer tools to limit allocation by controlling the layout of data structures. Consider this simple type definition of a data structure containing a buffer (array) of bytes:

type X struct {
a, b, c int
buf [256]byte
}

In Java, the buf field would require a second allocation and accesses to it a second level of indirection. In Go, however, the buffer is allocated in a single block of memory along with the containing struct and no indirection is required. For systems programming, this design can have a better performance as well as reducing the number of items known to the collector. At scale it can make a significant difference.

可以间接说明这个问题，通过指针间接访问变量是有代价的。

至于你的测试可能还不足以说明问题，因为 string 需要支持不同长度，肯定在内部实现上需要动态内存的，因此也就是一定存在间接访问。你需要做的测试需要对比 struct 成员全部是固定大小。一个紧凑的，连续累加 int 的测试或许可以有非常大的差异。至于指针更快还是 struct 更快取决于你的内存访问模式。如果是大数据（比如超过 cpu 二级缓存大小）拷贝为主，那就选指针。如果是连续访问元素，那么就应该选 struct

1.确认 iso 的 bootloader 是什么。我估计是 grub
2.如果是 grub,可以在此启动界面的项目上按下 e 进入编辑界面
应该类似于
linux (xxx)/vmlinuz xxx
initrd (xxx)/initrad
将 (xxx)/后面删除，尝试用 tab 补全路径
3.看看补全内容是否会出现你的 cdrom 。如果出现，就将 vmlinuz 和 initrd 改成能够正确补全的路径
4.如果补全内容不会出现 cdrom ，那可能是 UEFI 启动和 BIOS 启动不兼容引起
5.切换成 BIOS 启动安装，或者制作一张 UEFI grub 启动 u 盘进入 grub 命令行来加载 cdrom 中的 vmlinuz 和 initram
6.如果对 grub 和加载内核命令行不太熟悉，建议先在虚拟机中尝试，或者换用更易上手的 linux ，等到熟悉之后再尝试

等到你对这些命令比较熟悉的时候，只要直接解压缩 rootfs 到目标分区后再逐个配置文件后即可完成安装...