Arch 中抢先体验 Compiz++
LDCN 曾经介绍过 Compiz 将用 C++ 重写，不过之后 GNOME-Shell 的大热几乎让我们忘记了 Compiz++ 这么回事，再加上 Compiz 开发者匮乏，开发进度缓慢的一贯印象，除了少数如我一般的 Compiz 死忠，似乎很少有人关心 Compiz 怎么样了。
无论如何，Compiz 的开发者们还是在默默地为了理想中的窗口管理器努力着，如今 Compiz++ 已经接近可用状态， Arch 论坛上也有人放出了 Compiz++ 系列的 PKGBUILD，如果你也是 Compiz 的粉丝之一的话，不妨抢先体验一下吧。
这几个包的名称和地址是：
compiz-core++
compiz-plugins-main++
compiz-plugins-extra++
compiz-plugins-unsupported++
libcompizconfig++
compizconfig-python++
ccsm++
emerald++ (可选)
emerald-themes++ (可选)
安装 Compiz++ 完全不会影响现有的 Compiz，因为它是安装在 /opt 下面的，配置文件的名字也会不同。安装完成上面的包，可以运行如下命令来配置 Compiz++：
/opt/compiz++/bin/ccsm++
开启 Compiz++（建议预先开启 fusion-icon，这样遇到什么问题，可以方便切换为原来的 metacity 或者 compiz）：
/opt/compiz++/bin/compiz --replace ccp
如果遇到问题，试试：
/opt/compiz++/bin/compiz --replace move decor composite resize place opengl
还不行的话，把 opengl 去掉试试。
当然这只是一次 C++ 语言的重写，不要期望有大的功能上或者性能上的变化，也不要指望开发版的稳定性有多么好就是了。不过相信通过 C++ 的重写和重新架构，以后的 Compiz 开发会更加容易、更加顺畅，给我们带来更好的体验。
Arch 论坛上的讨论帖：http://bbs.archlinux.org/viewtopic.php?id=93786
两个新的 pacman 外壳：clyde 和 packer
Arch Linux 独特的 pacman 包管理器是其备受亲睐的原因之一，作为一款命令行包管理器，它深谙 K.I.S.S. 原则，在使用上甚至比很多图形界面的包管理器还要强大，还要方便、直观。
然而，Arch 的用户总是挑剔的，总是希望日常使用的包管理器更加的 Simple and Stupid，于是有了 pacman-color、yaourt 等等，种种扩展、外壳更是把 pacman 武装成了神兵利器，再加上如我一般的用户更是用 alias 将各种命令简化，简简单单的 ysyu 命令就更新了整个系统，实在是把 Linux 下的包管理简化到了一个极点。
不过，总是有更加挑剔的用户，Linux 世界才有这么多的优秀软件，据我所知，今年又有两个 Arch 用户不满 yaourt 的缓慢、低效、丑陋（虽然我没感觉），开发出了两个新的 pacman 的外壳（wrapper）：clyde 和 packer。
Clyde
Clyde 由 DigitalKiwi 和 Ghost1227 开发，主要是不满基于 Bash 的 yaourt 太过缓慢，和对 AUR 支持的低能。他们希望使用小巧快速的 Lua 语言重写一个 wrapper（底层用 C 编写），能够提供多线程下载的支持，并且容易在此基础上构建图形界面包管理器。
Clyde 保留了 pacman 和 yaourt 的选项用法，界面也很类似，使后两者的用户更加容易迁移，开发者表示，Clyde 已经足够稳定来应付日常使用，“不过如果它破坏了你的系统，烧坏你的主板，吃了你的孩子，可不要找开发者算帐，警告过你了哦！”
Clyde 可以通过 AUR 安装，软件包名 clyde-git。
packer
packer 的开发者是 bruenig，他开发 packer 的主要目的是整合 pacman和 AUR，看来也是对 yaourt 对两者分别处理，还在不必要的时候对 pacman 来回调用、拖慢速度十分不满。
作者认为 packer 主要实现四个 pacman 和 AUR 的整合功能就可以了：搜索(-Ss)、查看信息(-Si)、安装(-S)、升级(-Su)，在这四个功能上做到 pacman 和 AUR 一视同仁。
64 位系统安装 GMLive 网络电视和 Google Gears
GMlive 想来关注 Linux 软件的同学应该很熟悉了，lerosua 兄的大作，至少在中国，是 Linux 上最好的网络电视图形端了。它支持 sopcast、nslive 等后端，还支持 mms 流媒体，资源很是丰富。
然而由于 sopcast 是闭源软件，并且只提供了 32 位二进制程序，GMLive 也因此被很多发行版认为只支持 32 位系统。
其实，对于 64 位系统，只需要安装 lib32-libstdc++5 这个 32 位库即可完美运行 sopcast。
在 Arch Linux 下，可以通过安装 bin32-sopcast 这个软件包直接安装 32 位版 sopcast，不过，由于软件包维护者的疏忽，你需要在 PKGBUILD 中 depends=(lib32-libstdc++5) 这一行的下面加入一行：provides=('sopcast')，来表示它已经提供并可以取代 sopcast 这个软件包。
然后安装 gmlive 这个软件包，这里也需要将 arch=('i686') 改为 arch=('i686' 'x86_64') 来填加 64 位支持。
初次运行会提示没有 nslive，无视即可，因为 nslive 已经挂了。打开视频的样子如图所示（我调用了外部播放器），可以看到，GMLive 频道齐全，还具有频道书签，录制视频等功能，一点也不比 Windows 下同类软件差。
如果你常看体育新闻，或者是电视剧集的发烧友，这个软件绝对不容错过。
PS：本来还想写 64 位下的 Google Gears 呢，结果 svn 好不容易弄下来 400M 的东西，第一步打补丁的时候就不过去……郁闷了……
Update:
解决 Catalyst 最大、最小化窗口缓慢的问题
使用 Catalyst 的用户都知道，开启 Compiz 的时候，无论最大化、最小化窗口都会有半秒左右的延时，即使不开相关的动画特效也是如此，这使得原本流畅的窗口操作变得让人郁闷无比，有些网友甚至因此不得不改用开源驱动……不过，这样的黑暗时代已经过去啦！
来自 Arch AUR 的消息，Arch Linux 可以通过安装打了 Fedora patch 的 xorg-server 解决此问题，原来这是 Catalyst 与 xorg-server 的一个冲突。
假设你已经安装了 yaourt 和 catalyst 这两个包，你可以运行如下命令安装此版 xorg-server：
yaourt -Rd catalyst catalyst-utils yaourt -S xorg-server-catalyst-maximize-fix yaourt -Rd libgl yaourt -S catalyst-utils catalyst
接下来重启就可以看到效果啦！
通过安装这个包，不但最大、最小化窗口缓慢的问题解决了，而且感觉打开窗口也流畅了不少，特效有种脱胎换骨的感觉～而且安全无风险，很值得一试！
PS：Catalyst 9.7 for windows 已经出了，相信 for linux 也会很快出来，希望到时候能有更大的提升！
新一代的快速启动脚本——quick-init
好吧，这又是一篇 Arch Linux 专用的文章，使用其他发行版的 TX 们请瞪眼看着吧……
还记得上次说的 Finit-ARC 么？quick-init 系列脚本就是 Finit-ARC 的延续，其实这不是什么新的东西，自从我发了那两篇文章，Finit-ARC 就停止了，据说是出于安全性考虑，不再开发使用 C 语言的 Finit-ARC，而是使用像 Arch Linux 原生的 init-scripts 一样的 Shell 脚本。
那么 quick-init 的原理是什么呢？
The reimplementation of init-scripts consists in the modification of the inittab runlevels and the start of system and Xorg without udev.
The first system level contains the creation of static devices necessary to boot system until fscheck. Then Xorg is started and in runlevel 3 it starts udev, swapon, all services etc...
大意说就是加载必要的设备和配置，然后在 udev 没有启动的情况下马上启动 Xorg，然后再启动 udev，swapon 和其他服务等等。
我们通常所说的启动时间都是进入 Xorg 的时间，这样启动速度就快了很多了～
quick-init 的安装很简单，直接 yaourt -S quick-init 即可，重启就可以看到效果，如果你对 init-scripts 比较熟悉，还可以自行修改，去掉一些用不到的设置，比如 lvm、raid、其他显卡的配置，你还可以通过参考《启动后自动进入X》这篇文章来绕过 GDM、KDM 等显示管理器，更加快速的启动电脑。
来看看我优化的效果吧～（这是启用了自动加载模块的效果，如果手动加载的话，可能会更快）
AUR 中的 Catalyst 变成无主状态了！
自从 Arch 决定将 Catalyst 移出官方源，已经一周过去了，期间 AUR 中惊现了 Catalyst 9.4，让我们这些 A 卡用户看到了一线曙光。
然而，今天去逛逛 AUR，想看看 Catalyst 对 2.6.29 内核支持有何进展的时候，突然发现，这个包被维护者抛弃了……
Comment by: draje on 2009 03 29 [04:52:36]
Due to a lack of need for anything the open source drivers do not have, I have decided to orphan the catalyst packages.
就是说，维护者认为用户对 Catalyst 提供的开源驱动没有的特性期待度不高，所以决定不再维护了……
这真是一个噩耗……对于 A 卡用户来说，尤其是稍新的一点显卡，开源驱动实在是不敢恭维……Catalyst 虽然有很多地方不尽如人意，但是性能上还是比开源驱动强太多了……
如果以后 Arch 用户都用不上 Catalyst 的新版，那可怎么办啊……唉，受苦的总是用户……
Arch Linux – 自定义 CFlags 榨干计算机的油水
提到榨干计算机的油水，人们想到的往往是 Gentoo。
会这样想，一个重要的原因就是，Gentoo 完全由源码编译，在编译的过程中，可以自定义每个包的 CFlags。我们知道，很多 CFlags 可以对本机的 CPU 进行专门的优化，去除程序的一些调试信息等等，使程序在速度、体积等方面大幅度的提升（相对于没有优化来说，事实上，大多数发行版已经设定了 CFlags ，达到一定程度的性能提升），还可以设置 MAKEFLAGS 。
那么，我们的 Arch Linux 是否也可以像 Gentoo 一样自定义 CFlags 呢？当然可以。
呃，方法当然不是 export ……
用你喜欢的编辑器打开 /etc/makepkg.conf，其他不懂的不要改，看这一段：
#-- Exclusive: will only run on -march=x86-64 # -march (or -mcpu) builds exclusively for an architecture # -mtune optimizes for an architecture, but builds for whole processor family CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" #-- Make Flags: change this for DistCC/SMP systems MAKEFLAGS="-j3"
这是我修改过的，其中 MAKEFLAGS 原来是被注释掉的，你可以根据自己的需要修改。
当然，这些 FLAGS 只对 AUR 中需要编译的软件包或者用 makepkg 编译的软件包（其实是一个意思）才有用，如果想要全部使用这些 FLAGS 编译，你可以使用 ABS 哦，要知道源里的软件包也都是 makepkg 起来的，呵呵，编译狂人动起来吧～
我的特效终于回来了！
自从升级为 Xorg 1.6 之后，我的 Catalyst 就与我告别了……打开电脑就花屏，只好换成开源驱动 ati，算起来也有好几周了……
无奈 ati 和 radeon 都不支持 HD 3600 的特效，于是只能用 metacity 的 compositing manager 凑合……真是惨痛的经历啊……
不过现在一切都好了，我“抱着试试看的心理”，从 AUR 里安装了 Catalyst 9.4，注销，花屏……再注销，重启了……
本来以为不行了……结果一重启，成功了！果然显卡驱动还是要重启生效的啊……
要是你和我有一样的困扰，又等不及月底就要发布的 9.3 版的话，可以试试 9.4 Beta 版，或许有意想不到的收获哦～
第一次管理AUR里的包
ArchLinux真是神奇，自从安装后连连给我惊喜，在这次的惊喜过后，我终于忍不住发一篇文章。
感觉在用Ubuntu的时候根本不是在用Linux，虽然有很多新鲜的东西，但都是别人定好的，说白了安个软件跟Windows没有什么区别，只不过一个是从下载站下载，一个是从源里下载而已。
不过在Archlinux里，这完全不一样了。
起因是我想安装kiba-dock，这本来是好久以前就瞻仰的东西，不过先前网卡不行，只能望而生叹。而且Ubuntu 64bit根本安不上，源码编译都不行。
想一想，ArchLinux里，其他人应该有解决办法吧，去AUR里看看，果然支持x86_64，那基本上就意味着有人安装成功了。于是乎赶紧yaourt -S，然后发现，它所依赖的包akamaru-svn不支持64位，汗～
本来这种事改个arch就好了，可是改了之后又有问题，忙了半天发现是源码包需要改一下……
我就想，这谁管的包啊，这么不负责，一看，没人……再汗～
于是我很疑惑，上面有个按钮是干什么的，点了，发现我成了那个包的主人了，瀑布汗……
以前根本没有经验，只好照着别的包抄了一下PKGBUILD的写法，总算把那个BUG修复了，传上去，嘿，我这已经安装上的包也更新了……爽啊～
虽然这是个可能永远不能更新的软件（SVN才到3），但是管理还是很有成就感，以后要一定要学学SVN～
最后，发现安了这个包根本没有起到应有的作用，可爱的物理特效根本没有开，也就是说，这是个名存实亡，根本没用的包……成吉思汗……
关于
标签云
友情链接
- A Bit? No!!!
- bones7456
- Cooking Linux
- HomeZZ
- I'm M.B.Samnew
- I'm TualatriX
- L'ven's Blog
- ShelleX is Not ShelleXtend
- Var的小宇宙
- 七星庐
- 小汐的露青轩
- 歪歪灰主流
- 若有所思&&若有所想
- 运维进行时
- 阳光烂灿的日子
- 麦麦的不老阁
