首先，这篇文章是一篇WHY-TO，面向所有Linux操作系统（或者说偏向gentoo、arch之类习惯自己折腾的系统），而不是HOW-TO。小白或者懒人想要快速解决问题的，请看cc98 Linux天地置顶贴：【HOWTO】ubuntu下如何上网（需要浙大内网访问）。
紫金港宿舍区上网主要有两种方式：一、连接内网后使用学校VPN访问外网（通过设置路由表可以实现内外网同时访问），而连接内网的方式又分为闪讯和201卡两种；二、使用闪讯或201卡直接连接外网（可以使用RVPN来实现内外网同时访问）。
闪讯这东西短期内在Linux下是没有能够正常使用的可能了。而201卡连接外网的资费又是一小时一元，实在承受不起。所以唯一可行的方案只剩下使用201连接内网后用VPN连接外网。其实VPN上外网性价比也是很高的，如果不追求网速的话，10元一月的教育网出口就够用了；就算有网速需求，50元一月的电信出口也并不算贵（闪讯4M包月也是48元）。
接下来我们就按照201卡、VPN、路由的顺序来详细介绍上网设置。
很多人都认为系统时间是个无关紧要的东西，大概准确就行了，就算差个半小时只要自己不误会也没问题。但是，这在当今与网络联系密切的现代操作系统上也许并不是那么一回事——尤其是Linux。
Linux最大的用途就是服务器了。作为一台服务器，时间准确是十分重要的，以防出现一些奇怪的情况——例如一台邮件服务器时间快了，别人收到的邮件也许就会是来自“未来”的了。相信运维们都很了解时间的重要性，我也不再赘述了。
不过也许很多人不知道的是，桌面系统时间不准确也会引发问题。我这几天在GNOME 3中就遇到了一个由时间引起的诡异问题：GNOME 3.2中引入了“在线账户”(GNOME Online Account），可以与在线账户同步文档、聊天、联系人等等，目前暂时仅支持Google。但几天前，我的在线账户突然间授权失效了，重新登陆也不行，总是获取token失败。查看Debug输出、日志等等，都没有发现什么有价值的线索。后来无意间我发现系统时间慢了半小时，调整之后再尝试登陆在线账户，竟然成功了。原来是由于系统时间偏差过大引起的。
其实类似的问题在很多“time-based”的token验证系统（简单说来就是根据当前时间产生token的系统）上都会发生，如果系统时间偏差过大将会导致验证失败。
这两天我把系统换成了Archlinux，在用livecd引导启动准备安装时就遇到了问题——启动过程极其漫长；而在安装软件包、高强度读写硬盘时，也出现了假死问题。
类似的问题在进行了系统升级后仍然存在，具体表现为：启动、编译软件、使用hdparm等高强度I/O时，系统假死，在/var/log/errors.log中可以看到以下记录：
Jan 20 15:41:01 localhost kernel: [ 34.400019] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
Jan 20 15:41:01 localhost kernel: [ 34.400044] ata1.00: failed command: READ FPDMA QUEUED
Jan 20 15:41:01 localhost kernel: [ 34.400064] ata1.00: cmd 60/08:00:a0:5e:38/00:00:3a:00:00/40 tag 0 ncq 4096 in
Jan 20 15:41:01 localhost kernel: [ 34.400066] res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 20 15:41:01 localhost kernel: [ 34.400103] ata1.00: status: { DRDY }
（另外几次假死有的是WRITE FPDMA QUEUED。）
可以看到在假死的时候出现了ata frozen，ncq错误，无法完成读/写队列。上网查询，发现论坛、bug tracker、Q&A上有大量相关的信息，错误日志与此类似，可是大都没法彻底解决——归根究底是以上的日志信息太少，只说明了是ata错误，读取超时。通过其他多方面测试、尝试最终可以知道，这些大都是硬件软件配合问题造成的——对于某些控制器、驱动器，内核ata模块的acpi、ncq等功能无法正常工作，导致I/O错误。解决方法有的需要更换硬件，有的需要更新固件，还有的需要使用内核参数，禁用某些功能或是限制SATA速度。
其中数量比较多的一种就是libata的acpi节能功能有问题，导致硬盘供电不足。根据网络上的说法，在大容量硬盘上这个bug也更容易出现。我的这个硬盘就是新买的500GB 7200转，功率比较大，经过尝试，确实是这个bug导致的。
截止发文之时，没有找到相关补丁，只有一个简单直接的workaround：禁用libata的acpi功能。方法很简单，也没有太多副作用，只要添加内核参数（写入GRUB的启动参数即可）：
libata.noacpi=1
PS1:不建议直接禁用全部的acpi功能（即使用 noacpi 参数），此将禁用所有的高级电源管理功能，可能导致休眠、挂起以及笔记本亮度调节失效等等副作用。
PS2:ACPI是Advanced Configuration and Power Interface（高级配置与电源接口）的缩写。而与之相似的APIC是Advanced Programmable Interrupt Controller（高级可编程中断控制器）的缩写，与扩充硬件中断有关，与引起Linux诸多问题的ACPI基本毫无关系，请不要混为一谈，随意禁用APIC。
Update: 这个问题只在部分声卡上会出现。以下的解决方案都是为了解决爆音这个“问题”，如果你没有遇到这个问题，也就自然不必解决，或者说，采取了这些措施后也不能提高音质。
很早就发现Ubuntu下的音量调节范围比Windows要大得多，刚开始还以为是Linux的音频驱动更NB而窃喜，然而后来发现这并非是什么好事——音量条左端10%和右端20%几乎是废的，前者声音小得根本听不见，而后者则大得出现了爆音。有意义的音量条长度变短直接导致了音量调节非常困难，而且，就算是中间音量也经常出现爆音。
作为一个GEEK，遇到问题怎么能这样被难倒？必须得认真研究解决之！
本文中提到的Ubuntu均指10.04及以后版本。UPDATE：该方法在较新的主流发行版中均可用。
LINUX下查找文件的方式很多：如果你想知道某个程序的二进制文件 、源码以及它的manpage是在什么地方，可以用whereis，它会在一些常见目录（具体可man whereis）搜索该文件名，由于这几个路径是硬编码在程序里的，查询速度快，灵活性差；如果你想通过文件名查找一般文件，那么Ubuntuer一般会选择locate，它通过维护一个覆盖全文件系统的文件名数据库来实现快速查找，不过数据库的更新有一定的迟滞性，且它在其他发行版中不一定默认安装。
然而，最强大的*nix通用搜索利器莫过于find。它支持按照文件名、文件内容、文件属性、类型、权限、大小、创建/修改时间等等来查找文件，并且可以灵活地组合各种条件，熟练地运用它会给你带来不少便利。