@lijianying10

你在宿主 CoreOS 中查看 blog 和 blogcp 的权限分别是什么？

/mnt 挂载的时候是否有 uid/gid 的参数设置？

回复排版可能会崩，将就着看吧。

"mounts": [
{
"type": "bind",
"source": "/mnt/blogWork/blog",
"destination": "/hexo",
"options": "rbind,rw"
},

这一节，相当于在宿主机（即你的 CoreOS）执行
mount -rbind /mnt/blogWork/blog /path/to/container/rootfs/hexo
容器中的 /hexo 将继承宿主机 /mnt/blogWork/blog 的权限设置。

本质是容器访问内部 /hexo 时访问了容器外的内容，是数据持久化的一种方法。无论是容器内 /hexo 还是宿主的 /mnt/blogWork/blog，都是访问的同一目标，对任何一方的改动都会即时反映在另一方中。

具体到你所说的“好使”和“不好使”的情况，区别在于，/mnt/blogWork/blog 的权限不同

好使的时候，所有者是 root:root
不好使的时候，所有者是 502:dialout

鉴于 /mnt 是用来持久化 docker 的，我猜 /mnt/blogWork/blog 也是某种形式的挂载？宿主中的 /mnt/blogWork/blog 的权限可能




一点补充

"process": {
"terminal": true,
"user": {
"uid": 0,
"gid": 0,
"additionalGids": null
},
"args": [
"bash"
],
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"TERM=xterm"
],
"cwd": "/hexo"
},

这一节，指定容器启动时以容器内的 uid:0 gid:0 即 root:root 运行 bash

由于没有启用 user 类型的 namespace，容器中的 root:root 会直接映射为宿主的 root:root，理论上不存在无法访问的问题。






关于“表达”的问题：

“好使”“不好使”的标准是什么？

“原地复制”的具体命令是什么，在宿主还是容器中复制？

@lijianying10 你贴个 config.json 链接看看吧

如果让我说 runC 目前的现状，我的评价是可以用于生产环境了。runC 本身已经足够稳定了。

因为 runC 只是个运行时，比起在生产环境中部署 docker，部署 runC 的依赖成本小太多了。从某种意义上来说，runC 从出生就是为生产环境准备的。比较合理的使用模式是开发环境用 docker，测试和生产环境只需要 runC。


不过对于真正意义上的“生产”应用来说，runC 还没有实际意义。容器应用的最大问题是 orchestrating，目前除了 docker machine/swarm 那一套，和依赖网络服务发现的方案之外，基本没有选择。很有可能的情况是，在生产机器上用 runC 替换了 docker 之后，又重新造了一个 docker ……

权限的问题，你的 blog 描述不是很清晰，不过我大概有个推断，你可以参考一下。

因为你在用 mac 系统，文章里也提到了挂载文件系统的事情，那么很大可能你的容器镜像只包含可执行文件，而资源文件是通过挂载卷的方式映射到容器当中的。

假设某资源在 mac 的所有者是 user:staff，那么所对应的 uid:gid 是 502:20。（mac 系统中 uid 从 501 开始，502 一般是第二个帐号，staff 组的 id 就是 20）

你把它映射到 docker 宿主系统时，仅仅能传递 502:20 这个信息，宿主系统去寻找宿主系统中映射的 uid:gid，而 linux 的习惯是 uid 从 1000 开始，那么就无法对应到具体的所有者，所以 ls 直接显示 502，至于 dialout 组，它的习惯 gid 也是 20。

runC 是 docker 的纯运行时，所以和 docker 的工作机制是完全一样的。

至于“原地复制一份”，其实我不太理解这句话的意思，但我猜你在容器环境进行的复制操作。容器内部默认 root:root 的（具体机制是映射到宿主系统的 root:root），那么新的副本自然是由 root:root 所有。

运动的，我是配 L+R 的时候搭送的，就是普通无光学处理的 Hoya 片，便宜的塑料架。这个就是替代作用，太好的弄坏了还心疼。戴上不掉舒服就行。

配重那个，并不是多个东西，就是镜脚处向下弯至接近 90 度，略微变粗，长度明显，原理像耳挂式耳机差不多。基本上看下官网的图就明白了。

因为是钛的，用手不好调。我是镜片到了装配好了先让店员调了 15 分钟镜脚，适应一天后又做了次微调就再也没操心过。调好的状态镜脚几乎贴合后耳廓和皮肤，非常稳定，相当于耳朵和鼻梁共同分担重量。

Rodenstock 自己店挺少，不过大点的店可能都能做，只是厂家在欧洲，国内订时间会久。测量服务是店家做的，数据报给厂家。

记得大概测了瞳距，眼球到镜片距离，额头宽什么的。成品镜片是按度数打磨后的两大片圆镜片上切下来的，跟据你要的外形来切割和打固定孔。这个对于后期佩戴舒适度影响不小我感觉。

上面基本说到了，运动眼镜可以夹头固定，非运动靠减重，无框，钛架，硅胶鼻托，耳挂支撑。

我推荐两个品牌，Lindberg 镜架和 Rodenstock 镜片。

Lindberg 有设计非常巧妙的铰链机构，轻量化的同时稳定性和耐用性都非常好。硅胶鼻托非常舒服，理论上全球保……镜脚利用耳挂做配重，减轻鼻梁压力，调整合适后无论鼻梁还是耳挂都异常稳固。Lindberg 眼镜盒是带磁性夹片，不用时可展平，收纳时是个三角柱，非常方便。

Rodenstock 相当于合成材料的 zeiss，它有一项服务，针对客户佩戴姿势拍正侧面照片，确定最终镜片切割角度。

两者结合，只要不是剧烈运动导致眼镜位置滑动，你一天除了戴上摘下就完全不用管了。要说缺点就是贵……

遇到 thread name 异常的情况可以先看是不是 root 权限，如果是就有很大可能是它主动调用了 prctl 或者修改了 argv[0] 的信息。

prctl 对应的是 /proc/$pid/status
argv[0] 对应的是 /proc/$pid/cmdline

如果是 rootkit 的话，它根本不会在 ps/top 中显示出来。

参考

http://photo.stackexchange.com/questions/25891/is-it-possible-to-create-an-inside-out-panorama

我也想过这个问题，大概可以叫做 inverse panorama？



以下部分为脑洞：

如果能够用 3d 来表现的话，它是个地球仪的样子，需要全息投影才能观察；如果限定 2d 来表现的话，那么它是地球仪沿轴向的展开图，中心点就是观察点，四个角有非常大的形变。观察点变化的话，整个投影也跟着变化。


再进一步脑洞：

二维的 panorama 就是从一个点去观察一条直线，旋转一周后形成一个圆，观察点是圆心。

二维的 inverse panorama 就是从这个圆上去观察圆心，结果是一个点。

三维的 panorama 严格来说应该是从一个点去观察一个面，旋转之后是个球。 （同时应具有全部角度 panorama 的信息）

三维的 inverse panorama 观察球心还应该是一个点，如果有体积的话应该是个球。



广义上三维的 panorama 平面展开后，只是一个观察方向上的，如果把所有观察方向的结果叠加起来……我的脑子不够用了。

@bottleimp

我表达得不够清楚，本地 tmux 进程，连接到远程主机，断开重连的确是无法避免的。

这种情况本地 tmux 进程开 pane 连接远程主机，需要每开一个新的就 ssh 一次，iTerm2 针对这个情况可以方便一些。



你需要的集成功能：

本地连接远程，本地只需要 attach 即可，参考 tmux -CC attach 命令。断开直接用 detach，相当于远程的 tmux 一直保留，只是和本地断开连接。

针对断开重连的问题，用 mosh 代替 ssh。
https://mosh.mit.edu/

要做的就是在 iTerm2 中执行 mosh <remote host> -- tmux attach，iTerm2 会把 tmux 的功能接管过来，不需要你执行命令了。同时 mosh 会接管 ssh 的功能，提供无缝断开重连。

如果仅仅为了消除浏览器的警告提示，这种做法完全没有意义，骗自己骗用户。

第三方内容应完全视作不安全，无论是否通过 http over tls 加载。




对于浏览器来说，同一个页面引入的所有动态指令具有相同的执行权限，同时对 DOM 具有完全的访问权限。

举例说明：

你的网站 https://yoursite.com/index.html 引入了某第三方视频网站内容，如https://videosite.com/video.js （或者是 flash 等等任何形式），那么 video.js 的代码可以访问到 DOM 中所有元素，获取 document.cookie，甚至冒充用户执行 yoursite.com 上的 ajax 指令。




这里有个真实的案例，某托管有 js 代码的网站被攻陷，代码被替换成为恶意指令，引用了原始代码的网站都成了受害者。
https://blog.sucuri.net/2014/11/the-dangers-of-hosted-scripts-hacked-jquery-timers.html

同样的问题也会发生在众多托管 js 的 cdn 服务身上，比如你使用了 google 托管的 js 库，尽管它是 https 引入的，但仅仅只能保证代码从 google cdn 到用户不会被篡改，但你不能保证 google 不做恶，或者 google 因为某漏洞被攻陷。




为了避免这种盲目信任引入的安全风险，w3c 新增了名为 Subresource Integrity 的草案，让主动嵌入第三方代码的网站可以验证嵌入代码的完整性和可信性。不过目前仅仅是草案，浏览器支持几乎没有。

@lululau 最近刚刚修复了，以前一直不行

@rming 多谢指点


@thinker3

tmux.conf 找 default-shell，没有的话 set-option -g default-shell $SHELL

有可能 zsh 导致环境变量 $SHELL 出错，也顺便看下

我建议在 mac 环境中用 iTerm2 集成的方式使用 Tmux。（用 tmux -CC 调用）



iTerm2 解决了单独使用 Tmux 的几个不便：

Tmux 窗口调整只能用鼠标完成，iTerm2 支持快捷键；

Tmux 远程 session 需要多次 ssh 来增加窗口，iTerm2 将其自动化了；

Tmux 之内某些快捷键不便使用，如 bash 历史，emacs-keybind 等等，iTerm2 自身快捷键是 gui 的 cmd 修饰，而不是 terminal 的 ctrl 修饰。





PS

如果你想用 Tmux 的方式使用 gui 程序，可以考虑 Amethyst - A tiling window manager for OS X
http://ianyh.com/amethyst/

这个点叫做 trailing dot，根据 DNS 协议标准，包含末尾 . 的域名是绝对域名（fully qulified domain name），不包含末尾 . 的域名是相对域名（partially qualified domain name），绝对域名的意义是避免二义性。

比如 DNS 服务器包含以下两个域名记录：

v2ex.com.
v2ex.com.example.com.

如果用 v2ex.com 去查询，那么以上两个记录都是有效的。而用 v2ex.com. 去查询，那么只有第一个记录是有效的。




浏览器对于不包含 trailing dot 的网址，一般会默认查询绝对域名记录。（因为带 trailing dot 的域名记录是正确的，所以能够正常访问。）

对于 web 服务器应用，包含与不包含 trailing dot 的主机通常会被处理成不同的 virtual hosts 来对待。（所以会带来域不同造成的如 cookies 不通用问题。）

定做的，连工带料花了 3000 左右，如果桌面用压缩板上漆 2000 就够了。

@iiduce

你这设计很漂亮啊，而且看上去就很实用，自己做灵活性没得比。

我当初的打算是双层，显示器靠支架壁挂，上层放路由和存储设备等等。后来师傅说太长就要下面加支撑，像你边上的抽屉柜一样，不然一个两米多的纯木板自重就撑不住。

后来改进的结果就是桌面做宽，只做一层，靠墙一面加支撑板。更大的原因是准备后面上投影，这样就不能用壁挂了。桌面做宽的好处是脚下空间足，不过之前设计的走线架不是很好用，又打了几个孔。

桌子后半截我安装好就不用动了，前面显示器一挡还很美观。整个桌子两侧是两个主工作位，中间是纸笔工作区。需要投影的话显示器 90 度转向就可以了。房间不够大，投影暂时在椅子后面的单体沙发之间，正在考虑上幕布和顶挂。

现在不太满意的地方，一是桌面木头太厚了，贵还不说，实在太重，后期想改作它用都难，应该用压缩板然后上漆。二是走线格设计不好，应该顺着长边靠墙一侧做一个比较长的，而不是两侧各做一个短的。

@DearTanker
我这渣画质能认出 E5 也是厉害啊

@kingwrcy :D

@yetone ASUS pb298q 29" 21:9