为什么要用国外的空间，因为他稳定，只要不被墙，一般是永久的，如以前介绍的fileden，在被墙之前我用了两年感觉很好，在fileden被墙后，我尝试了国内的空间如2yam，没想到一个月后就换了域名，两个月后居然变成图片分享网站。不禁感叹免费国内不会长久。最近我发现Screencast，他简直是fileden的缩小版，不由得喜欢上了他。

Screencast.com 是来自美国的一家网络硬盘网站，主要提供收费网络硬盘服务，也提供2G容量的免费网络硬盘供大家申请，提供图片、音乐、视频的直接地址供你外链到你的博客 或网站上，很方便，只是流量比较小，每月只有2G。Screencast免费网盘支持在线上传，单个文件限制100M以内，如果你要上传100M以上的文 件需要下载安装Screencast的桌面上传工具。Screencast不支持中文文件名，中文文件名的文件不能上传。

网址：http://www.screencast.com

演示 http://content.screencast.com/users/zyxf/folders/Default/media/7278f920-e39d-4509-b26f-7b75814bb279/tiankongzhicheng.mp3

打开 /etc/modprobe.d/alsa-base.conf运行 sudo gedit /etc/modprobe.d/alsa-base.conf找到options snd-hda-intel power_save=10这一行 在前面加个##options snd-hda-intel power_save=10搞定。

所下载的软件包(*.deb格式，除了partial和lock外)一般放在/var/cache/apt/archives/目录下，一次更新后，往往需要下载几百MB的文件，网速慢可是大问题。如图：但是，一旦因为某种原因，需要重装系统的时候，难道那么多的文件又要重新下载吗？要是在碰上蜗牛似的网速。刚才已经说过，/var/cache/apt/archives/ 目录存放的是Ubuntu更新下载的软件包，可以将此目录下所有的deb文件备份下，以后重新安装系统时就不需要重新下载了。那么大家在Ubuntu重 装系统之前，将/var/cache/apt/archives/目录复制到另一个非系统分区（win fat分区也可以），例如/home/hp/backup（自己决定，最好文件夹都是英文名字），重装后，再将其复制到/var/cache/apt/archives/下即可。

在QQ网站下载linux的安装包后（linuxqq_v1.0.2-beta1_i386.deb），安装使用，发现QQ经常崩溃。
解决方法如下：
sudo gedit /usr/bin/qq
在第二行加入： export GDK_NATIVE_WINDOWS=true
即全文修改为：
#！ /bin/sh
export GDK_NATIVE_WINDOWS=true
cd /usr/share/tencent/qq/
./qq
保存后退出，重启QQ

    GDK has been rewritten to use 'client-side windows'. This means that GDK maintains its own window hierarchy and only uses X windows where it is necessary or explicitly requested. Some of the benefits of this change are

        * Reduced flicker
        * The ability to do transformed and animated rendering of widgets
        * Easier embedding of GTK+ widgets, e.g. into Clutter scene graphs


Launching an app with GDK_NATIVE_WINDOWS=1 application turns off this feature. This is needed if the application manipulates the windows it creates using direct X API calls or a mixture of X API and GDK instead of just going through GDK. When using "client-side windows" all window manipulation by an application must go through GDK. Adobe needs to update Acroread to be compatible with this feature.

GTK是一个API库，以前应该是基于X api的，现在GTK重写了，更好用，结构没有变，只保留了一部分必要的X函数。很多应用程序用到了X的api，直接的或者间接的，但是由于GTK不再完全依赖于X api，而这些应用又都是基于GTK的，所以当应用程序使用X的函数时会出现问题。
一切问题都是由于GTK的重写引起的。所以老的版本不会有这样的问题。GTK为了解决兼容的问题，增加了一个选项GDK_NATIVE_WINDOWS=1，这样就可以使用原始的GTK环境了。

首先介绍mp3的标签和编码的概念，然后再教大家解决乱码问题。
mp3的标签类型和编码，现在主要存在这几种标准，ID3v1、ID3v2 2.3、ID3v2 2.4、APEv2。
它们分别支持的编码为
D3v1：只支持ISO--8859-1
ID3v2 2.3：ISO--8859-1、UTF-16
ID3v2 2.4：ISO--8859-1、UTF-16、UTF-8
APEv2：UTF-8
我们可以从上面的列表看出，mp3的标签类型和编码是多种多样，没有任何的规范可言的。ID3v1只支持ISO-8859-1这一种编码，它是不支持中文的，所以一般来说只有ID3v1标签的mp3在Linux上基本上也都是乱码的命，而ID3v2 2.3支持的格式增加了UTF-16，直到ID3v2 2.4版才开始支持UTF-8，但是 ID3v2的两个版本标准并没有统一标签内容的编码。这里值得一提的是APEv2，它拥有最好的扩展性，它把编码格式统一为UTF-8，这样一来只要支持APEv2读取的播放器播放带有APEv2标签的mp3就不会存在乱码问题。可惜的是现在在国内的网站上下载的mp3基本上都没有APEv2标签，而且Linux下也没有几个播放器支持APEv2标签的读取。(目前Gnome里的Rhythmbox是支持APEv2标签读取的，包括QuodLibet都不可以。
一首mp3的标签是可以包含多种类型的，当一首mp3同时含有ID3v1、ID3v2 2.3、ID3v2 2.4、APEv2这4种类型中两种以上的时候，播放器对mp3标签的读取顺序一般是由上往下的，APEv2(前提是播放器支持此编码的读取)--- ID3v2---ID3v1。所以有时候会出现同一文件Rhythmbox显示标签正常(读取APEv2标签)，其他播放器不正常的情况(读取了ID3的标签)。
接着我们说说在Linux系统里，为什么所有的mp3播放器都会有乱码的问题，这是因为这些mp3播放器都是依赖系统内的libid3tag库完全按照ID3的标准来读取标签内容的。它不论mp3是采取何种的标准的标签(ID3v1、ID3v2、APEv2)，只要mp3的标签的内容是Unicode编码存储的，那么显示肯定是正常的(ID3v1的ISO-8859-1严格说是不支持中文，但是并不是代表它不能存储中文)。如果遇到是以gbk、gb18030、big5等编码的中文内容时，它还是会把它当成ISO-8859-1来读取，乱码就成了必然。
说了这么多，现在问题就变得简单了，似乎我们只需要把mp3标签里面用gbk、gb18030、big5等编码存储的中文内容修改为Unicode编码，那么基本上所有Linux下的播放器都能正常识别mp3标签了。
关于mp3编码的转换，这里介绍一个工具----Mutagen，假如你安装了Quod Libet，那么这个包已经安装上去了。如果没有，执行下列命令就可以了。
yum install python-mutagen
工具的使用方法
mid3iconv -e gbk *.mp3 #转换当前目录的mp3文件
find . -iname "*.mp3" -execdir mid3iconv -e gbk {} \; #转换当前目录下所有mp3文件(包括子目录)
因为现在在网上下载的mp3绝大多数采用的都是gbk/gb18030编码，-e gbk
参数是代表把gbk编码的标签转换为Unicode编码，假如mp3标签本身是Unicode编码的就不转换。如果需要转换其他编码的文件可以自行修改
gbk参数，比如改为gb18030、big5。转换后为的mp3标签类型为ID3v2 2.4，编码格式为UTF-16。
到了这一步之后，在Linux下使用所有播放器估计都没有什么问题了。下面我们回过头来看看，追溯一下根源，为什么这些mp3原来在Windows下用MediaPlayer怎么都是显示正常的呢？难道是Linux不如Windows吗？其实这个道理很简单，Firefox同样也打不开很多IE轻松就能打开的页面，能说明Firefox不如IE吗？知情的人一看就明白了。Windows为了它所谓的兼容性，完全无视规范，自定规则，貌似它的软件兼容性很好，其实到头来，毁的还是用户，从众多的不符合W3C规范的网页和现在铺天盖地的mp3标签为gbk/gb18030编码就可见一斑(反正我现在从网上下载的mp3在Linux下就没有看到几个能正常显示的)。
可以告诉大家的是，利用上面的方法转换编码之后，这些mp3在Windows的文件属性菜单和MediaPlayer里都无法正常显示标签，将会全部变为"?"。因为mid3iconv命令在转换编码时默认它会用Unicode编码填满D3v1,ID3v2, APEv2标签(前提是文件本来就含有这些类型的标签)，但是 ID3v1 又不支持中文的 Unicode 编码。而Media Player似乎只支持ID3v1的读取，当然你使用其他的支持ID3v2、APEv2类型读取的软件是没有问题的。
给出一个最终解决方案。
系统环境完全就是Linux。
直接使用下面的这条命令，转换所有mp3文件，完全无视Windows下的使用体验。
mid3iconv -e gbk *.mp3
当然了，如果你为了避免自己的mp3文件共享给Windows或者mp3的用户时，出现煞风景的"?"，你可以添加一个--remove-v1这样一个参数来直接删除ID3v1标签，避免了文件属性和Media Player里出现"?"。
mid3iconv -e gbk *.mp3 --remove-v1