这篇讲的是，如何通过压缩管道来突破服务器间大文件传输的速度瓶颈。作者在之前优化SCP速度的基础上，进一步测试了结合不同压缩算法与SSH的方案。 核心对比了lz4与pigz这两种高速压缩工具。在“打包-压缩-传输-解压-拆包”这一完整流程中，解压速度是最大的性能短板。lz4虽然在压缩率上略逊于pigz，但其解压速度达到了惊人的264MB/s，是gunzip的三倍，这使它在需要即时解压的传输场景中成为关键。 实测结果显示，使用 `tar | lz4 -B4 | ssh` 的组合，传输速度从原始SCP的约40MB/s提升到了249MB/s。这意味着原本需要3小时的400GB数据迁移，现在仅需27分钟。文章不仅给出了最终可用的命令行方案，还分析了磁盘IO、网络带宽及管道开销等各环节的实际表现，并发现了调整lz4块大小（-B4）能对性能产生显著影响。对于运维和开发人员来说，这是一个非常实用且经过验证的加速技巧。
这篇文章谈的是职场中一个微妙却普遍的现象：朋友间打听薪水。作者从财年季引发的讨论热潮切入，指出这种做法往往带来沮丧情绪，且弊大于利。 文章的核心观点很明确：了解行业薪资的大致趋势是必要的，这有助于判断个人价值与市场需求的匹配度。但打听具体个人的薪水，尤其是朋友间的薪水，则很容易引发心态失衡。作者生动地描绘了得知薪水差异后的两种典型负面情绪——“凭什么比我高”的郁闷，或“对方也就值这些”的轻视。这种情绪若演变为消极怠工，便可能形成一个从“郁闷”到“工作效率下降”，最终影响个人收入的恶性循环。 作者进一步分析，在满足短暂好奇心之外，打听薪水几乎毫无收益，反而可能给朋友关系贴上不必要的标签，徒增隔阂。因此，他提出了一个简单而有力的个人解决方案：为自己定下规矩，不再打听朋友的薪水，也不再回答此类问题。真正的友谊，其基础在于共同的兴趣与灵魂，而非工资条上的数字。文章最后那句“可以谈谈别的，比如其他人的薪水”，以一种幽默的方式，巧妙地重申了这一观点。
这篇讲的是如何突破scp文件传输的速度瓶颈。作者在实际场景中发现，默认配置下传输400GB文件耗时太长，于是系统性地测试了加密算法、压缩选项和完整性校验算法对速度的影响。 测试数据表明，选择更轻量的加密算法（如arcfour128、aes192-cbc）能显著提速，通常“越弱”的算法速度越快。有趣的是，启用ssh内置压缩反而常常拖慢速度，因为压缩本身消耗了时间，除非传输的是可压缩率极高的数据。此外，使用umac-64这类校验算法也比默认的hmac-md5带来约10%-20%的性能提升。 基于这些发现，作者建议直接尝试类似 `scp -c arcfour128 -o "MACs umac-64@openssh.com"` 的命令组合，往往能让传输速度翻倍。文章提醒，最终效果高度依赖数据类型和网络环境，关键在于根据实际情况做针对性调优。
想在脚本里“非阻塞”地获取Linux进程CPU利用率，却遇到top需要等1秒、ps只显示平均值的问题？这篇文章就从这个实际需求出发，直接深入到/proc文件系统，带你看清背后的原理。 文章的核心是对比两种思路：使用现成工具vs手动计算。作者明确指出，像top和ps这样的工具，虽然方便，但本质上提供了不同的“快照”——ps给出的是进程生命周期的平均利用率，而top需要至少1秒的采样间隔。关键差异在于，它们都无法满足对“当前时刻”瞬时利用率的精确、非阻塞获取。 真正的解决方案隐藏在/proc/stat和/proc/[pid]/stat这两个文件中。文章详细拆解了其中各列的含义，并给出了具体的计算公式：在两个时间点分别读取系统总CPU时间片和进程CPU时间片，通过差值比来计算这段时间内的利用率。这就像用两张“照片”的位移差来算速度，揭示了CPU利用率本质是一个时间段内的统计量，而非一个瞬时值。 最后，文章还解释了ps命令中%CPU指标的准确含义，即它是进程自启动以来的累计平均利用率。如果你需要在监控脚本中实现高精度的进程CPU统计，或者对系统工具背后的实现原理感到好奇，这篇文章提供的思路和细节会很有参考价值。
一位在北京学习工作七年后转战杭州的程序员，结合自己四年的亲身经历，分享了对这座城市的感受。文章从工作、生活、消费等几个维度展开，并与北京做了直观对比。 工作层面，作者坦言杭州的互联网机会相对集中，主要就在阿里和网易，选择面不如北京广，但电子商务氛围浓厚。生活则是杭州的强项，城区紧凑，周末去龙井、梅家坞聚会爬山都很方便，运动环境极佳。作者用“分分钟秒杀北京”来形容生活便利性上的优势。消费水平被认为与北京接近，但夏天的闷热被指出是明显的缺点。 最后，作者给出了“超出期望”的总体评价。这篇文章没有宏大的叙事，却通过通勤时间、聚会开销、爬山路线等真实细节，为考虑来杭发展的技术人提供了一份接地气的参考。
