在 2014 年 7 月 12 日参加 TIFF 访谈时，押井守曾被问到“《攻壳机动队》是否会成为现实”的问题，对此他答道：

“ 我觉得这已经是现实了。在座的所有人都有手机……我也有，现在只不过是把手机放进大脑里的问题。
不管是在衣兜里还是大脑里，反正你离了它就活不了了，这也是我为什么说人类必须去适应科技……
它也许只是在你的衣兜里，但那实际上已经是你身体的一部分了。”

我是用 gimp 裁的。gimp 可以前后景抠图。裁剪本身只有像素的概念。打印的时候有 dpi 也就是打印机分辨率的概念。但是不同打印机的 dpi 不一样，所以打印店大概率还是要调整。

显示器也有一样的问题，所以操作系统里有 dpi 设置。同样像素的图片在 4k 显示器上就只有 1080p 一半长度

@Monad 一般是根据纸张大小拼接和留白
比如我要 2x2 的照片，相纸是 4x6 ，那 2x3 张张照片拼起来，让打印机打整张相纸就可以了。
@boshok

@Mitt 苹果砸钱归砸钱，砸钱不代表你就能用得上
苹果经常是比别人多 10%的性能，多 20%的成本，高 100%的售价

谢谢楼主，支持一下

ebs 这类 block storage 服务是至少三度冗余
如果是 local cache disk 的话就没冗余，但是服务商会讲清楚让你不要存数据

@csh010101 smart 属性是百分制的，打分标准由厂家决定
这里临界值是 50 ，现值和最差都是 100 ，意思是厂家认为这盘还能用。掉到 50 分以下就是不及格。
但是，原始值大于 0 ，这是不打分的原始数据。结合事情经过，有理由推断，这个数字会迅速增加，打分很可能迅速低于临界值。所以建议更换。
如果是不重要的数据可以不换，加强监测。

@unclejock #38 汽车当然会发生事故，但是开车的人未必凉啊。我自己在高速上追尾过前车一次，前车定损定了报废，无人伤亡，连挫伤都没有。撞的速度不算快，气囊都没弹。但是无论哪一方是摩托或者电瓶车的话，这个速度绝对是够重伤了。
如果你最近有看北美的新闻，西雅图女程序员酒驾超速，失控翻车。副驾当场死亡，主驾重伤，但一周后出院潜逃回国。一周后居然能出院是最离谱的，连警方都没想到。据警方估算，当时的速度是 90 迈，相当于 150 公里。我不是说开车应该超速哈，但是摩托车车开 150 发生事故还有没有半点可能有命在？

道理很简单：一个铁包肉，一个肉包铁，你说哪个更安全？
你说泥头车 200 公里对撞都一样的话那就没什么好说的了

“但一方面退回去的肯定二手还是销售了”,
你可以现在下一单，同时申请退货。等到新买的送到就把新买的退回去。
只要是不查序列号的东西都可以这样。

@coderxy 因为遇到危险的人是没机会上网发帖了
一个铁包肉，一个肉包铁，你说哪个更安全？

https://u2.dmhy.org/mybar.php?userid=43651.png
https://byr.pt/mybar.php?userid=188227.png

买个盒子刷不就好了……

这就是很典型的瘦客户端啊。Chromebook
或者 手机+USB hub+便携屏幕

@dslwind 你这是散热器扣具设计不合理，压力不均匀，导致 CPU 插槽变形，接触不良

“每个月工资上缴老婆”
“前几天才知道我老婆接触网 du ，目前各种网贷欠下总额 20w”

唉……

p100 你搜搜实际使用体验。显存大是大，算力不行有什么用？ reddit 上就有人用 p100 出过图，效果并不好

二手卡默认是矿。只要价钱合适，矿就矿吧。到手先跑一遍各种测试，小烤一下温度正常，那就用吧。别手贱换硅脂，散热不正常就退。

40 卡不游戏也可以考虑，不炼丹的时候挖个矿回收一点成本也行。之后还可以出二手回血。

你这不是自购电脑用于工作，而是把自己的私人电脑用于工作。区别在于，工作电脑和私人电脑有没有分开。
如果能保证工作电脑上只有工作内容，那就算自购的电脑，要装深信服就装，要看数据就看。反正只有工作内容。离职直接抹盘重装，或者管理系统替你抹盘。

@byte10 “cherry-pick 问题多多，容易出现漏掉” backport 的时候我就是不想要某些 commit
另外，你用法可能错了，cherry-pick 是可以一次性指定一段范围的 commit ，会一个一个 pick 过去。和 rebase 效果类似但是方向相反。

@byte10 你看一下 git log 的可视化就知道了。merge 的优点是可以保存 feature branch 上的支线 commit 。

merge 产生的是一个“merge commit”，有多个父节点。这样的 commit 在 rebase 的时候非常蛋疼。也就是说，如果一个 branch 有过 merge ，那就基本告别 rebase 了。

rebase-and-squash 对人多的项目比较合适。因为开发人员水平不一，很多人的 feature branch 的历史都乱七八糟。squash 以后主分支上，一个 PR 对应一个 commit ，就非常干净。之后某个 release branch 需要 backport 的话也很方便，直接 cherry-pick 特定 commit 就行。

如果是 merge ，那就要保留对应的 feature branch 。backport 的时候直接从 feature branch 上 merge 。

通过 rebase 解决冲突，最终产物是树狀的历史。通过 merge 解决冲突，最终产物是网状的历史。

我个人是非常反对用 merge 。只用 rebase 和 cherty-pick 。因为有些 commit 可能是不想要的。所以 merge 不可取。release 分支上 cherry-pick 相应的 commit 。

merge 派和 rebase 派，选了一边就不能换。

原因你自己说了啊
反正最后你还是会买，那为什么要多给 2G ？