@hljjhb https://help.github.com/articles/distributing-large-binaries/

当然, "in addition to distributing source code" 只是个提示, 就有人不愿意往 repo 里放代码就只能靠道德约束.

@hljjhb 但是用私有库外人就下载不到了啊. 再加上 github 组织现在超贵的, 按所属组织所有的, 任意私有 repo 有访问权的总人数算钱, 只能访问一个 repo 的就算.

按 growth hack 的精神来讲迭代太慢了.

@hljjhb 把大型二进制文件放 git 里面本来就不对. 而 release 功能虽然可以上传文件, 但上传的文件应当是 repo 代码的衍生品. 有合理理由上传 blob 的情况并不多, 比如 linux-firmware 等和硬件驱动相关的项目, 但 linux-firmware 的主场在 kernel.org, 是 kernel 的附属部分.

不开源的产品应当自己负担 hosting 相关费用, 如果 repo 只是放个说明或者链接可以当 pages 看待.

1 应该和 launchpad 一个性质, 感觉上可能比 launchpad 更差, 楼主去问问有没有编译服务器.
2 估计没有
3 假定 glibc? 往上堆的部分靠 snap 自身解决依赖? 可能会装重复了.

@sunchen 抱歉漏了 DESC. 但是没有可补充的了. 楼主如果继续这样理解问题的话就无解了.

@sunchen 楼主再仔细瞪大眼睛! dist >= 3000 的时候退化成 ORDER BY priority - 30.

1 楼 +1. 不开源也往上放, 胆子不小. 老老实实的找其他地方托管!

geo 索引

@helixzz ZFS 的 RAID-z 比民用级的一切都好. 硬 RAID 是自讨没趣.

@helixzz 另外你不用开发版内核你就没有机会上 LKML 反馈问题. 文件系统已经坏了就没法报告, 不是开发者想去查问题也根本没有头绪.

@helixzz 所以这种配置的系统应该把内存加到 64G 上 Solaris 跑 ZFS RAID-z2. 现在除了内存少了一点以外正是 ZFS 的推荐配置.

难道是 user-agent 检测?

目测文件系统应该已经坏了, 换新内核再有问题应该往内核 bug 方向考虑了.

死海效应嘛. 有能力的人不愿意忍受坏环境, 而且到哪里都是强人. 这样不太好的人就剩下来, 按年数当主管了.

@xingzhi 论资历的话 richard 的话来不来就无所谓了.

其实需要注意和小心的是赢者通吃现象啊, 因为传统行业至少地域门槛还是不低的. 某朝有个墙还能挡一挡外来的巨头, 万一没有了也会发现在裸泳.

同一个领域只需要几家公司就可以满足 90~95%+ 的需求了. 每个人都想搞自己一套的重复工作, 到头来缺乏竞争力就根本不可能成为 top 3. 这些事情等退潮了就会看的很清楚.

A1+B1+C1+D1=1 (互斥)
A2+B2+C2+D2=1 (互斥)
? + ? = ? (答题一次)
? + ? = ? (略)
? + ? = ?
? + ? = ?
...
所以问题一是个八元方程组. 问题二维数太高无解.

php 版 iv 的 '0' 其实是 0x30 吧. 不会写字符串吗?