perl- up to date
#!/usr/bin/perl -w
use strict;
use LWP::Simple;
my $dir = "/home/stesen/music";
my $url = $ARGV[0];
my $act = $ARGV[1];
unless ($url =~ m#^http://#) {
print "Wrong URL!\n";
}
unless ($act =~ /^(d|l)$/) {
print "Download OR Listen?\n";
}
my $page = get ($url);
my $name_begin = "border=\"0\" alt=\"";
my $name_end = "\"> Listen Now";
my $link_begin = "javascript:playmedia1\(";
my $link_end = "\);ListenLog";
$page =~ m/$link_begin(.*)$link_end/is;
my $unclean_link = $1;
$unclean_link =~ s/ //g;
$unclean_link =~ s/\(//g;
$unclean_link =~ s/\)//g;
$unclean_link =~ s/\'//g;
my @misc = split /\,/, $unclean_link;
my $link = $misc[6].$misc[2].".mp3";
print $link;
if ($act eq 'd') {
$page =~ m/$name_begin(.*)$name_end/is;
my $name = $1;
$name =~ s/ //g;
$name =~ s/\(//g;
$name =~ s/\)//g;
$name =~ s/\［//g;
$name =~ s/\《//g;
$name =~ s/\&//g;
$name =~ s/\@//g;
$name =~ s/\”//g;
$name =~ s/\"//g;
$name =~ s/\“//g;
$name =~ s/\`//g;
$name =~ s/\'//g;
$name =~ s/\\//g;
$name =~ s/\///g;
$name =~ s/\#//g;
$name =~ s/\!//g;
$name =~ s/\*//g;
$name =~ s/\、//g;
$name =~ s/\[//g;
$name =~ s/\]//g;
$name =~ s/\{//g;
$name =~ s/\}//g;
$name =~ s/\;//g;
$name =~ s/\://g;
$name =~ s/\$//g;
exec "wget -c $link -O ${dir}/${name}.mp3";
}
elsif ($act eq 'l') {
exec "mplayer $link";
}
bash- probably won't work
下载songtaste的音乐比较麻烦,以前用mozilla-mplayer听歌,可以直接用右键获取音乐地址
现在debian sid的源里没有mozilla-mplayer,只有一个gmplayer的插件,质量很差,听到一半常常断掉
换xine的插件稍微好些,但没法获取下载地址了,所以只好写个脚本专门来下载收听
我水平太次,脚本丑陋不堪,而且不是100%的歌都能正常收听下载,辉耀出品必属废品,谅解..
先要装:
links,也可以用其他的lynx,w3m之类,感觉links稍微快些(也许是错觉)
wget,rayfile只能单线程下载,自然首选wget,好在速度不慢
iconv,转换编码,我用xterm编码UTF-8,系统的locale也是en_US.UTF-8,而 songtaste的页面源代码是gb2312
mplayer，听音乐用
########################################################
#!/bin/bash
#get music from
www.songtaste.com
if [ $# != 2 ] then echo "Usage: stmusic.sh URL l" echo " stmusic.sh URL d" exit else URL=$1fiTOP=/home/stesen/musicNUM=`echo ${URL}|sed -e "s/http:\/\/songtaste.com\/song\///g" -e "s/\///g"`links -source "
http://60.10.96.74/play.php?song_id=${NUM
}" |grep "preview" > ${TOP}/.stmusic.tmp
#ip 60.10.96.74 即songtaste.com,用ip可以减少dns解析时间#但是今天它换ip了,估计是服务器出问题,变成115.100.249.248#所 以,换回http://songtaste.com/play.php?song_id=XXX还是直接用ip自己斟酌吧
if [ $2 = d ]
then
NAME=`iconv -f gb2312 -t utf-8 ${TOP}/.stmusic.tmp|cut -d"\"" -f4|sed -e 's/\ /-/g' -e 's/\./-/g' -e 's/(//g' -e 's/)//g' -e 's/…//g' -e 's/\ //g' `
TP=`iconv -f gb2312 -t utf-8 ${TOP}/.stmusic.tmp|cut -d"\"" -f12 |cut -d"." -f5`
FULLNAME=`echo ${NAME}.${TP}|sed -e "s/-././g"`
wget -c `iconv -f gb2312 -t utf-8 ${TOP}/.stmusic.tmp|cut -d"\"" -f12` -O ${TOP}/${FULLNAME}
elif [ $2 = l ]
then
mplayer `iconv -f gb2312 -t utf-8 ${TOP}/.stmusic.tmp|cut -d"\"" -f12`
fi
rm ${TOP}/.stmusic.tmp
exit
#######################################################
用法：
./stmusic.sh url l #listen
./stmusic.sh url d #download
url即类似
http://songtaste.com/song/1625284/
这样的页面
Tuesday, June 22, 2010
EveInstaller, Ubuntu 下超强软件安装器
刚刚发现这款名为 EveInstaller 的 Ubuntu 下的超强软件安装工具，用它可以方便的开启 Ubuntu 下很多常用软件源，也可以安装 Ubuntu 下 N 多常用软件跟游戏，鼠标轻松点击几下即可完成，适合懒人。
今天 Wordpress 和网络跟我过不去，更多截图请挂代理后访问这里。
这个软件是非英语国家的人开发的，没有中文版，但是有英文版本，最新版本是 0.9 ，请点击这里下载。
哦，貌似这个地址在墙外，我传了一份在我的主机上，点击这里下载 eve-installer_i386-EN.deb 。
更新：
两位朋友留言说安装英文版本之后不能正常启动，Linuxtoy 那边有网友说装西班牙语版却可以正常的开，嗯，虽然大部分人都懂英语但是不懂西班牙语，软件图标还是能分清楚的吧，不会翻墙的朋友直接点击下面的链接下载西班牙语版的 EveInstaller .
http://pengjiayou.com/resources/eve-installer_i386-ES.deb
此外：
似乎是 EveInstaller 的作者通过这篇文章找到我这里来了，希望有人帮忙翻译成中文，有时间跟精力的朋友直接跟作者 邮件 联系吧。他的信箱是：(apticons@gmail.com)
转自：pengjiayou.com
Thursday, June 17, 2010
chakra update
Chakra 项目于今日发布了一个 64 位版本（Phoix），该版本包含
Kernel-2.6.33.5-1、aufs2-20100514-2、aufs2-util-20100514-2、KDE SC
4.4.4、Xorg-Server 1.7.6、Catalyst-10.5、NVidia-195 及 NVidia legancy
系列等。
有兴趣的朋友可至 Chakra 论坛下载其 ISO
映像进行测试。
分类: Distros |
永久链接 |
收藏到 del.icio.us |
Email 给好友 |
9 评论 |
捐助本站
online OCR, great tools on web
OCR 是Optical Character Recognition（光学字符识别）的简称。 这项技术最早起源于1920年，那时全球第一项OCR专利技术是在德国发行的。现在这项技术主要应用于将文档扫描成文字。如果你把图片里的文字扫描出来，或者把文档里面的文字扫描出来使用并编辑的话，那么这项技术就少不了。 在这篇文章里，我将向大家推荐3款免费的在线OCR服务，它们提供的功能极为广泛并且质量也不错。
OnlineOCR
这项服务可以从PDF文件和图片文件中识别出文字或者字符，并把它们转换成其他的 文件格式，比如PDF和word文件格式。源文件的格式，像表格，分栏，项目符号，图表等都会保留。最后一项功能就是基于web的OCR服务。你可以无需 注册便可以使用这项在线的OCR服务，然而会有一点点的限制：你所上传的单个文件大小不得大于1MB，识别语言也只能按默认的设置-英语，并且不能修改， 输出格式也只有纯文本格式。
如果你注册的话，你可以选择多种识别语言，且可以一次上传多个总大小不大于 30MB的文件。如果你又5个积分的话，那么一个积分可以上传一张图片文件（单张或者多张）还可以识别多张图片。
如果你一个积分都没有的话，你可以把 Demonstration mode 打上勾，看一下扫描后的文档预览即可。当然你也可以购买积分，起步价是6美分/页。
我用了一封信测试了一下这个服务。把信拍摄成照片，并且有很明显的折痕。然而，格 式和文字识别的都非常棒。不行的是，这项服务不支持手写体文字。
NewOCR
Free Online OCR这项服务使用简单，上传没有数量无限制，图片文件大小不超过5MB，PDF文件大小不超过20MB。当上传一个文件进行字符识别的时候，为了优化识 别结果你需要先选择一种语言与旋转文档。对了，这项服务也不须注册。
不幸的是，识别之后的文档所有的格式都会丢失，并且它还不能识别手写体。更差劲的 是，在我的测试文档中，有一部分的头部都跑到地步了。因此，这项服务比较适用于纯文本，比如当你需要把一个旧文档打印到新纸上时，这项服务就比较适用了。
Free OCR
Free OCR 接受2MB的图片和PDF文件。并且它只识别PDF文件的第一页。你可以选择识别文档的语言，优化识别的结果。此外你每小时只可以上传10张图片。虽然支 持多栏文字，然而识别的结果仍然是纯文本，也就是说所有的格式都将丢失。这项服务也不需要注册。
虽然这项服务比较流行，但在我的测试中表现都不怎么好。许多字符适用其他的在线OCR 服务可以完美识别，但是它却一点都不能识别。显然，之前提到的页面折痕对Free OCR来说是个很大的问题。此外，一些文字都是随机显示的，可能他们扫描带格式文本的技术不怎么好吧。
Karl写过一篇有关Free OCR的更加详细的文章。可以参考一下这篇文章，学习如何获取质量比较好的扫描结果吧。《 C使用Free OCR在线将图片转换成文本》。
如果你正在寻找更多有关基于web的OCR服务，可以看看这里。 WeOCR.
正如你所理解的那样，使用在线的OCR服务对快速将比较脏的文档识别来说比较管 用。如果你需要扫描多个文档，并且需要带格式的扫描，我推荐你下载安装OCR软件。这里有两篇文章你可以参考一下：
- 如何从图片中提取出文字 (OCR) – 仅Windows系统 作者：Varun（本文为英文，如有需要联系博主翻译）
- 推荐5大免费将图片转换成文字的OCR软件 作者：Saikat（本文为英文，如有需要联系博主翻译）
你对免费在线的OCR服务有什么感触？
转载自北极星博客
编者按：很好的东西，尤其又是在线的，对像我这种和pdf打很多交道的很有用处
chrome OS更新
已经很久没有写过关于Chrome OS（或Chromium OS，以下只称作Chrome OS）的文章了，上次写Chrome OS的文章，已经是二月份的《谈Chrome OS从Ubuntu转向Gentoo》了。
这四个月来，Chrome OS的开发进展到底如何了呢？为了知道这个答案，今天我抽空编译了一个出来，按照惯例在EPC上进行体验，发现还是有大量令人激动的新变化！
有图有真相：
因为Chrome OS的截图功能只在登录以后才能工作，因此有些登录界面无法以截图说明，仅以文字叙述之。
当前Chrome OS已经完善了整个登录和设置过程，当用户首次使用该操作系统时，Chrome OS将有一个简洁的窗口用以设置语言与网络，这个步骤之后，便会进入用户帐户设置或创建的界面。
值得一提的是，如果Chrome OS检测到您的设备有摄像头，那么会有一步是设置帐户的头像，一个非常简单的“Set your profile image”窗口，直接从摄像头拍摄头像，如下图：
当登录进去以后，Chrome OS就是这个样子，基本上与之前的无异，不过细节已经打磨的更加精致。GTK的主题已经得到更新，窗口、Tooltip都已经具备阴影，同时右上角“网站报告”、“网络连接”和“电池电量”都采用了新的图标。
此外，Chrome OS还引入了一种新的视图模式，即在左侧显示工具栏。感觉有点怪，不过算是一种新的体验吧。
按F8后会有显示一个虚拟键盘，再按下Control或Alt或Shift你就会看到Chrome OS中一大堆可用的快捷键。一些快捷键来自于Chrome浏览器，而一些是Chrome OS特有的用于快速切换Tab和窗口，比如：Alt＋Tab。
OK，下面这个算是最终定形的Chrome OS的Tab和窗口切换了。
今天把玩了一会，感觉还不错，至少看上去与之前的设计图是一模一样的。
虽说这就是最初见于Apple产品里的CoverFlow效果，不过用在浏览网页上还是不错的。默认情况下，Chrome OS会把所有的网页以整页展示出来，在这个切换过程中，你就可以一览无余。
切换的效果也是比较动态和平滑的，很遗憾用图片是表现不出来的。
总体而言，Chrome OS在这几个月还是开发比较迅猛的。我这里并没有介绍其“文件系统”、“自动更新”方面的更新，要知道，这才是Chrome OS的核心所在：作为一个目标设计为高度安全、平滑升级的操作系统，Chrome OS拥有一个可以自动resize分区、无需用户过度交互即可方便升级、恢复的操作系统。
未来如果有时间，我可能会写文章来介绍一下这方面的设计。
总之，看完这些截图，你是不是对Chrome OS又多了一点期待呢？
瑞芯微新平台支持Android 2.1
你如果仔细搜索下瑞芯微这个关键词，就会发现，国内很多产商的播放器，MID，平板（包括爱可视，爱国者），电子书（OPPO），用的都是这家的平台，但现在这些产品停留在1.5，1.6的固件上，不过最新的瑞芯微芯片已经可以支持Android 2.1了，这是我们收到的最新照片，不过应该是属于工程样机，希望不久我们会拿到最终产品给大家做动手玩实拍。另外，虽然我们很在意2.1和1.6，但是现在有80-90%的Android应用跑在1.6上面，一些新的游戏则需要2.1固件，你手上的Android设备，产商给你升级了固件没有？
支持一下中国制造还有android
"Vacuum Places Improved" Speeds Up Firefox with a Click of Your Mouse
Vacuum Places Improved handles it for you with a mouse click.
This experimental extension adds a small icon to the Firefox status bar that, when clicked automatically "vacuums" your Places database—the one that slows down Firefox when it gets fragmented. You can also automate the task by ticking the Automatically clean places checkbox in the Vacuum Places Improved extension Preferences and entering your desired number of Firefox startups since last cleaning.
It still doesn't solve one of the biggest items on our Firefox wishlist (i.e., better memory management), but at least its an easy way to execute one of the workarounds.
Vacuum Places Improved is an experimental extension (so install with caution), works wherever Firefox does.
KMS, history and current state
There was a talk last week at LinuxTag in Berlin by Egbert Eich about kernel mode-setting and the DRM (Direct Rendering Manager) graphics stack on Linux. Egbert is, of course, a long-time X developer and openSUSE developer at Novell who was one of the masterminds behind the RadeonHD graphics driver and has worked on various pieces of X over the years. In Egbert's brief KMS talk he briefly covered the history of the Linux
graphics stack, the user and kernel-space APIs for DRM mode-setting, and related topics. For those that missed out on his talk, below are his slides.
FFmpeg 0.6 Released With H.264, VP8 Love ... ongoing competition
今天，FFmpeg 的开发者发布了 FFmpeg 0.6 版本。FFmpeg 提供一套完整的音频/视频录制、转换解决方案，作为一个主要更新版本，FFmpeg 0.6 添加了许多新的编/解码器支持，例如 PCX、CorePNG、8088flex TMV、V210、AMR-NB/AMR-WB、XSUB、AAC、TwinVQ、PGS、WMA Pro、ALS、CDG、SIPR、Bink、Indeo 5、WMA Voice、HE-AAC v1、KGV1、VP8 等等。
此外，FFmpeg 0.6 还包含许多其他方面的改进，如能够更快的解码 H.264、Matroska de/muxer 支持 WebM、添加了更多的容器格式等。详情可查阅其 Changelog。
你可以从 FFmpeg 官方网站的下载页面获取该版本。
The release of FFmpeg 0.5 last March was significant as it was the first official release in quite a while for this popular and widely used free software media program. Fifteen months later, FFmpeg 0.6 has been released with plenty of changes including support for Google's VP8 codec / WebM and improvements for HTML5/H.264 video playback.
Google's VP8 is properly supported in FFmpeg 0.6 via the libvpx library and the Matroska was extended to support the WebM container format.
According to the announcement found at FFmpeg.org, "The H.264 and Theora decoders are now significantly faster and the Vorbis decoder has seen important updates."
There is also a new ffprobe tool, VorbisComment writing for FLAC and Ogg FLAC / Ogg Speex files, RTP packetization/de-packetization support for a number of new codecs, ARM optimizations, and much more.
此外，FFmpeg 0.6 还包含许多其他方面的改进，如能够更快的解码 H.264、Matroska de/muxer 支持 WebM、添加了更多的容器格式等。详情可查阅其 Changelog。
你可以从 FFmpeg 官方网站的下载页面获取该版本。
The release of FFmpeg 0.5 last March was significant as it was the first official release in quite a while for this popular and widely used free software media program. Fifteen months later, FFmpeg 0.6 has been released with plenty of changes including support for Google's VP8 codec / WebM and improvements for HTML5/H.264 video playback.
Google's VP8 is properly supported in FFmpeg 0.6 via the libvpx library and the Matroska was extended to support the WebM container format.
According to the announcement found at FFmpeg.org, "The H.264 and Theora decoders are now significantly faster and the Vorbis decoder has seen important updates."
There is also a new ffprobe tool, VorbisComment writing for FLAC and Ogg FLAC / Ogg Speex files, RTP packetization/de-packetization support for a number of new codecs, ARM optimizations, and much more.
Monday, June 14, 2010
这个还是蛮有意思的咧 dvorak键盘
| Dvorak keyboard | |||
 A keyboard designed for speed typing. The Dvorak keyboard was designed in the 1930s by August Dvorak, a professor of education, and his brother-in-law, William Dealy. Unlike the traditional QWERTY keyboard, the Dvorak keyboard is designed so that the middle row of keys includes the most common letters. In addition, common letter combinations are positioned in such a way that they can be typed quickly. It has been estimated that in an average eight-hour day, a typist's hands travel 16 miles on a QWERTY keyboard, but only 1 mile on a Dvorak keyboard. In addition to the standard Dvorak keyboard, there are two additional Dvorak keyboards, a left-handed and right-handed keyboard. These keyboards are designed for people who have only one hand for typing. | |||
Friday, June 11, 2010
技术文章：设计思路比Upstart更加超前的init系统--systemd
简而言之，systemd是一个init程序。根据之前 Upstart的一些介绍大家应该简要了解了传统Sysvinit系统的不足之处。不过，这次的systemd的设计思想更为超前，也可以说是借鉴了OSX上launchd的思路。感谢 comicfans44 投稿
作者在其项目的 blog页面 有一篇对于init系统很好的介绍。不过内容超长，在此摘录一些重要部分翻译如下，如有错误还请指正。
init进程由内核启动，是所有其他进程的父进程（也许应该译为母进程？:-）因此比其他进程能够做更多事情，比如在启动过程中加载服务进程。
传统的 sysinit 系统不符合一个有效的、快速的init系统标准： 1. 尽可能启动更少进程 2. 尽可能将更多进程并行启动
条款1意味着除非必须否则不启动。不像syslog和DBus，蓝牙服务仅在蓝牙适配器被插入时才被需要；打印服务仅在打印机连接或程序要打印时才需要；甚至sshd也 不是必须的，管理员常常因几个月才连接一次的ssh而一直运行 sshd 进行监听。 条款2意味着不应该像 sysvinit 一样串行执行启动进程，以最大化CPU和IO带宽的效率。
软硬件的动态改变
现代的操作系统应具备高度的动态特性：不同的程序启动、停止，不同的硬件被添加、移除，因此需要服务在被需要时动态的启动。 大多数当前的系统在尽可能并行化启动过程时仍对一些守护进程的调用保持同步：比如 Avahi 需要DBus，故仅在DBus启动、且 DBus 信号准备完成后 Avahi 才被启动。与之相同的是 libvirtd 和 X11 需要HAL（虽然之后HAL会被移除），在 HAL 启动前，libvirtd 和 X11 不会启动。
并行化Socket服务
以上的同步过程导致了启动过程的串行化。能否摆脱同步与串行化的缺点呢？答案是能够! 首先我们要理解 daemon 对彼此的真正依赖是什么，为什么它们在启动时被延迟了。 对于传统的 Unix daemon，答案是：它们在所需要的服务所提供的 socket 准备好连接之前一直处于等待状态。 常见的是 AFUNIX，但也可能是 AFINET。比如，需要DBus服务的客户程序将在 /var/run/dbus/systembussocket 可以被连接之前等待，syslog 服务的客户程序将在 /dev/log 上等待...而这是它们唯一需求的内容！（意指只要这一条件满足，客户程序即无需等待，不论实际的服务是否已经启动。下文详细介绍）
以上就是等待的真正含义。如果能尽早建立客户程序所必须的 socket 而令客户程序处于等待状态而不是在服务程序完全启动后再启动客户程序，我们就能加快启动进程，进一步并行化进程启动。如何做到这一点？在 Unix 族系统上非常简单：在真正需要启动服务之前先监听其 socket，然后将 socket 传递给 exec() (此处直译，含义不懂)，如此，在 init 系统中第一步就可建立所有 daemon 所需的所有 socket，在第二步中一次运行所有的 daemon。如果一个服务需要另一个，但被需者未完全启动号，也完全没有问题在被需者查询 socket，处理请求之前，客户进程将因这个请求而被阻塞，但仅有被这个请求阻塞的客户进程被阻塞。并且服务之间的依赖关系将不再需要（手动）配置：如果一次建立所有服务所必须的所有 socket（及启动所有相关服务），则所有服务的所有需求一定在最后会被满足。
下列所说将是重点：如果同时启动了 syslog 和多个其客户进程（意指syslog尚未启动准备好处理请求），而客户进程开始发送请求，则请求会被写入 /dev/log 的Socket 缓存中。除非缓存填满，否则客户进程无需任何等待即可继续完成其启动过程。当 syslog 启动完全后，处理器所有的消息。另一个例子：DBus与其客户进程一起启动，当同步请求发出但没有接受到预想的回应，客户进程将阻塞。当 DBus 启动完成后处理请求，客户进程继续。
内核的socket 缓存将辅助达成最大的并行化。因为内核完成了同步，不再需要用户空间的任何的额外管理！如果在 daemon 启动前所有必须的 socket 都已经可用，依赖关系就变得多余（至少是次要了）。daemon A 需要另一个 daemon B，简单的连接到B。若B已经启动，A的请求成功。若B未完成启动，假如A发出的不是一个同步请求，甚至无需理会（B没有完全启动）。甚至即使B完全没有执行（比如crash了）时再重启B也为时不晚对于A而言二者没有任何分别。借此可达成最佳的并行化和随意的需求时（on-demand）加载。而且在此基础上能够更加鲁棒。因为 socket 即使在相应服务是暂时不可用（如crash）时也可用，所以客户进程不会丢失任何的请求（request入buffer，待重启服务后处理）
更多有趣之事
首先，这不是一种全新的逻辑，这正像是Apple的launchd系统所做的：OSX 中所有 daemon 所需的 socket 都由 launchd 建立，然后服务本身并行启动，无需手动指定相关的依赖性。这一设计创意独具，也正是OSX急速启动的原因。但这一思想在Apple之外未有任何系统有所体现。
在 launchd 之前,这一思想有更早的体现者：古老的 inetd 就如此工作：socket 被 daemon 建立而实际的服务在daemon通过exec()启动相关进程时传递socket的文件描述符。然而 inetd 所关注的当然不是本地服务，而是网络上的服务。他也不是并行化启动或者隐藏依赖的正确工具。
对于 TCP 的 socket inetd 对于每个进入的连接都建立一个新的 daemon 实例，这意味着每个连接将导致一次进程初始化，这无助于高性能服务器。然而此后inetd支持另一种模式单：当第一个连接到来时，第一个实例（单例）被启动，并将继续接受后续的请求。
并行化Bus服务
Linux上现代的daemon都通过DBus而非socket来交互，现在的问题是，对于这些服务，能否施加与启动传统的、基于socket的服务逻辑相同的并行化？答案是可以，DBus已经提供了所有必要的hook：使用DBus将会在第一次访问时加载服务，并且给予最小的、每请求一个的、消费者与生产者同时启动的同步机制。例如Avahi与CUPS（CUPS需要Avahi进行 mDNS/DNS-SD上打印机扫描）同时启动，仅仅是简单的同时启动二者，若CUPS比Avahi启动快，则DBus将把请求缓存入队列，直到 Avahi服务进行了处理。
所以，总结如下：基于Socket和基于DBus的服务可一次并行启动所有进程，无需任何额外的同步。基于激活的策略还能令我们进行延迟加载服务。如果服务很少被用到，我们可以在第一次被访问时启动，而不是在启动过程中启动。
这太Great了~
并行化文件系统任务
对于当前发行版的启动序列图可以看出，文件系统任务所发生的同步点大于 daemon 启动时的同步点：mount fsck等。现在，启动时很多时间都花费在空闲等待所有fstab 中列举的文件系统被加载、 fsck的过程中，仅在完全完成后启动进程才会继续。如何改进？答案是autofs系统。就如同connect() 调用表示一个服务对另一个服务感兴趣，open() 调用（或相似的调用）表示服务对特定的文件或文件系统有需求。所以，我们应该仅令那些访问暂时还不可用（暂未完成 mount、fsck）文件系统的服务阻塞，这样就改进了并行性。首先加载autofs，然后继续正常的mount过程，当被访问的文件系统未准备好，内核将会缓存请求调用，访问进程将被阻塞，一个未成功的访问仅可能阻塞一个进程。当真正的文件系统加载完成后，启动进程如同正常般完成，没有任何缺失的文件，如此我们能够在所有文件系统都准备好之前就加载服务。
假如有人提出将autofs内置于 init 是不妥当的我并不感觉奇怪，也许这会导致更多 crash。然而经过实验，我可以说这并不正确。使用autofs意味着无需马上提供后台 的真实文件系统，这只会导致访问被延迟。如果进程尝试访问autofs但真实的文件系统很长时间都没能加载，进程将被一个sleep中断上被挂起，意味着你可以安全的cancel 它。如果最后这个文件系统都没能加载，那么令 autofs 返回一个error Code（例如 ENOENT）。所以我认为内置 autofs 到init中是正确的。实验代码显示这一想法在实践中工作的很好。
保持第一个登录的用户的 PID 很小（意即启动进程中少启动进程）
我们可以从MacOS的启动逻辑中学到的另一个内容是：shell脚本是有害的。Shell很容易 hack，但是执行却太慢。传统sysvinit启动逻辑就是围绕shell脚本的一种模式不论是/bin/bash还是其他shell（被用来更快执行shell脚本），最后的结果注定很慢在我的系统中，/etc/init.d中的系统脚本至少调用grep 77次，awk92次，cut23次，sed74次。每次调用时这届进程都被产生一次，库被搜索一次，有些像i18n这样的还会加载更多。这些基于琐碎字串比较的进程导致最终难以置信的慢。只有shell脚本如此工作。除此外shell脚本也非常脆弱，环境变量之类能够彻底改变脚本的行为（behaviour），最终难于检查和控制。
所以在启动过程中摆脱shell脚本！在如此之前先要明确使用 shell脚本的实际用意何在：大体上来说，shell 脚本在完成的是些令人厌烦的工作，用于琐碎的设置和卸载服务。这些内容应该用C来完成，位于分离的可执行程序，或者移至daemon本身，或者交给init。看起来我们还无法马上在启动过程中摆脱脚本，用C重写需要时间，且在有些时候也不行 shell 脚本太过灵活以至于无法脱离，但我们当然能让它们不像现在这样突出（被大量使用）。
简单测量shell 脚本对于启动过程的危害可以从你在系统完全启动后加载的第一个进程的PID看出来：启动、登录、打开终端，输入echo $$，对比Linux和MacOS，如下：Linux PID:1823，MacOS PID:154。自己测去吧。
接下来作者分析了Upstart对于这些问题的一些解决方法以及不足之处，接下来介绍了作者的最终结论： putting it all together:systemd
其特性就是...上文中如此多的翻译已经说明了其核心思路，就不具体介绍其中的详细概念了。值得一提的是systemd解析传统的SysVinit 脚本，将其依赖关系转化为 其原生的依赖关系，因此兼容 Sysvinit 脚本的同时仍能提供并行性，而 Upstart 无法对传统脚本进行并行化。且可通过DBus界面控制。
目前状态：已经可作为Sysinit或 Upstart的替代来使用，有一个修改过的 Fedora13qemu 镜像可供下载使用。http://surfsite.org/f13- systemd-livecd.torrent，作者秒表计时 Fedora13用Upstart启动27s，systemd24s（从grub到 gdm ,相同系统,相同设置，两次连续的启动过程中取较少者）。
FAQ
作者是？
Lennart Poettering（RedHat，大部分代码基础） Kay Sievers（Novell ，与前者共同讨论设计了细节） Harald Hoyer （RedHat） Dhaval Giani（前IBM） 此外还有Intel Suse,Nokia等多个公司的雇员
这是Red Hat的项目吗？ 否，这只体现了作者自己的设计选择。
将会在Fedora上使用? 一旦实验显示工作良好，社区会给出答案。如果是yes，当然会尝试令其进入Fedora
将会在OpenSuse上使用？ Kay处理此事，与我在Fedora 上观点相同
下面还有FAQ和很多细节，就不一一翻译了
作者在其项目的 blog页面 有一篇对于init系统很好的介绍。不过内容超长，在此摘录一些重要部分翻译如下，如有错误还请指正。
init进程由内核启动，是所有其他进程的父进程（也许应该译为母进程？:-）因此比其他进程能够做更多事情，比如在启动过程中加载服务进程。
传统的 sysinit 系统不符合一个有效的、快速的init系统标准： 1. 尽可能启动更少进程 2. 尽可能将更多进程并行启动
条款1意味着除非必须否则不启动。不像syslog和DBus，蓝牙服务仅在蓝牙适配器被插入时才被需要；打印服务仅在打印机连接或程序要打印时才需要；甚至sshd也 不是必须的，管理员常常因几个月才连接一次的ssh而一直运行 sshd 进行监听。 条款2意味着不应该像 sysvinit 一样串行执行启动进程，以最大化CPU和IO带宽的效率。
软硬件的动态改变
现代的操作系统应具备高度的动态特性：不同的程序启动、停止，不同的硬件被添加、移除，因此需要服务在被需要时动态的启动。 大多数当前的系统在尽可能并行化启动过程时仍对一些守护进程的调用保持同步：比如 Avahi 需要DBus，故仅在DBus启动、且 DBus 信号准备完成后 Avahi 才被启动。与之相同的是 libvirtd 和 X11 需要HAL（虽然之后HAL会被移除），在 HAL 启动前，libvirtd 和 X11 不会启动。
并行化Socket服务
以上的同步过程导致了启动过程的串行化。能否摆脱同步与串行化的缺点呢？答案是能够! 首先我们要理解 daemon 对彼此的真正依赖是什么，为什么它们在启动时被延迟了。 对于传统的 Unix daemon，答案是：它们在所需要的服务所提供的 socket 准备好连接之前一直处于等待状态。 常见的是 AFUNIX，但也可能是 AFINET。比如，需要DBus服务的客户程序将在 /var/run/dbus/systembussocket 可以被连接之前等待，syslog 服务的客户程序将在 /dev/log 上等待...而这是它们唯一需求的内容！（意指只要这一条件满足，客户程序即无需等待，不论实际的服务是否已经启动。下文详细介绍）
以上就是等待的真正含义。如果能尽早建立客户程序所必须的 socket 而令客户程序处于等待状态而不是在服务程序完全启动后再启动客户程序，我们就能加快启动进程，进一步并行化进程启动。如何做到这一点？在 Unix 族系统上非常简单：在真正需要启动服务之前先监听其 socket，然后将 socket 传递给 exec() (此处直译，含义不懂)，如此，在 init 系统中第一步就可建立所有 daemon 所需的所有 socket，在第二步中一次运行所有的 daemon。如果一个服务需要另一个，但被需者未完全启动号，也完全没有问题在被需者查询 socket，处理请求之前，客户进程将因这个请求而被阻塞，但仅有被这个请求阻塞的客户进程被阻塞。并且服务之间的依赖关系将不再需要（手动）配置：如果一次建立所有服务所必须的所有 socket（及启动所有相关服务），则所有服务的所有需求一定在最后会被满足。
下列所说将是重点：如果同时启动了 syslog 和多个其客户进程（意指syslog尚未启动准备好处理请求），而客户进程开始发送请求，则请求会被写入 /dev/log 的Socket 缓存中。除非缓存填满，否则客户进程无需任何等待即可继续完成其启动过程。当 syslog 启动完全后，处理器所有的消息。另一个例子：DBus与其客户进程一起启动，当同步请求发出但没有接受到预想的回应，客户进程将阻塞。当 DBus 启动完成后处理请求，客户进程继续。
内核的socket 缓存将辅助达成最大的并行化。因为内核完成了同步，不再需要用户空间的任何的额外管理！如果在 daemon 启动前所有必须的 socket 都已经可用，依赖关系就变得多余（至少是次要了）。daemon A 需要另一个 daemon B，简单的连接到B。若B已经启动，A的请求成功。若B未完成启动，假如A发出的不是一个同步请求，甚至无需理会（B没有完全启动）。甚至即使B完全没有执行（比如crash了）时再重启B也为时不晚对于A而言二者没有任何分别。借此可达成最佳的并行化和随意的需求时（on-demand）加载。而且在此基础上能够更加鲁棒。因为 socket 即使在相应服务是暂时不可用（如crash）时也可用，所以客户进程不会丢失任何的请求（request入buffer，待重启服务后处理）
更多有趣之事
首先，这不是一种全新的逻辑，这正像是Apple的launchd系统所做的：OSX 中所有 daemon 所需的 socket 都由 launchd 建立，然后服务本身并行启动，无需手动指定相关的依赖性。这一设计创意独具，也正是OSX急速启动的原因。但这一思想在Apple之外未有任何系统有所体现。
在 launchd 之前,这一思想有更早的体现者：古老的 inetd 就如此工作：socket 被 daemon 建立而实际的服务在daemon通过exec()启动相关进程时传递socket的文件描述符。然而 inetd 所关注的当然不是本地服务，而是网络上的服务。他也不是并行化启动或者隐藏依赖的正确工具。
对于 TCP 的 socket inetd 对于每个进入的连接都建立一个新的 daemon 实例，这意味着每个连接将导致一次进程初始化，这无助于高性能服务器。然而此后inetd支持另一种模式单：当第一个连接到来时，第一个实例（单例）被启动，并将继续接受后续的请求。
并行化Bus服务
Linux上现代的daemon都通过DBus而非socket来交互，现在的问题是，对于这些服务，能否施加与启动传统的、基于socket的服务逻辑相同的并行化？答案是可以，DBus已经提供了所有必要的hook：使用DBus将会在第一次访问时加载服务，并且给予最小的、每请求一个的、消费者与生产者同时启动的同步机制。例如Avahi与CUPS（CUPS需要Avahi进行 mDNS/DNS-SD上打印机扫描）同时启动，仅仅是简单的同时启动二者，若CUPS比Avahi启动快，则DBus将把请求缓存入队列，直到 Avahi服务进行了处理。
所以，总结如下：基于Socket和基于DBus的服务可一次并行启动所有进程，无需任何额外的同步。基于激活的策略还能令我们进行延迟加载服务。如果服务很少被用到，我们可以在第一次被访问时启动，而不是在启动过程中启动。
这太Great了~
并行化文件系统任务
对于当前发行版的启动序列图可以看出，文件系统任务所发生的同步点大于 daemon 启动时的同步点：mount fsck等。现在，启动时很多时间都花费在空闲等待所有fstab 中列举的文件系统被加载、 fsck的过程中，仅在完全完成后启动进程才会继续。如何改进？答案是autofs系统。就如同connect() 调用表示一个服务对另一个服务感兴趣，open() 调用（或相似的调用）表示服务对特定的文件或文件系统有需求。所以，我们应该仅令那些访问暂时还不可用（暂未完成 mount、fsck）文件系统的服务阻塞，这样就改进了并行性。首先加载autofs，然后继续正常的mount过程，当被访问的文件系统未准备好，内核将会缓存请求调用，访问进程将被阻塞，一个未成功的访问仅可能阻塞一个进程。当真正的文件系统加载完成后，启动进程如同正常般完成，没有任何缺失的文件，如此我们能够在所有文件系统都准备好之前就加载服务。
假如有人提出将autofs内置于 init 是不妥当的我并不感觉奇怪，也许这会导致更多 crash。然而经过实验，我可以说这并不正确。使用autofs意味着无需马上提供后台 的真实文件系统，这只会导致访问被延迟。如果进程尝试访问autofs但真实的文件系统很长时间都没能加载，进程将被一个sleep中断上被挂起，意味着你可以安全的cancel 它。如果最后这个文件系统都没能加载，那么令 autofs 返回一个error Code（例如 ENOENT）。所以我认为内置 autofs 到init中是正确的。实验代码显示这一想法在实践中工作的很好。
保持第一个登录的用户的 PID 很小（意即启动进程中少启动进程）
我们可以从MacOS的启动逻辑中学到的另一个内容是：shell脚本是有害的。Shell很容易 hack，但是执行却太慢。传统sysvinit启动逻辑就是围绕shell脚本的一种模式不论是/bin/bash还是其他shell（被用来更快执行shell脚本），最后的结果注定很慢在我的系统中，/etc/init.d中的系统脚本至少调用grep 77次，awk92次，cut23次，sed74次。每次调用时这届进程都被产生一次，库被搜索一次，有些像i18n这样的还会加载更多。这些基于琐碎字串比较的进程导致最终难以置信的慢。只有shell脚本如此工作。除此外shell脚本也非常脆弱，环境变量之类能够彻底改变脚本的行为（behaviour），最终难于检查和控制。
所以在启动过程中摆脱shell脚本！在如此之前先要明确使用 shell脚本的实际用意何在：大体上来说，shell 脚本在完成的是些令人厌烦的工作，用于琐碎的设置和卸载服务。这些内容应该用C来完成，位于分离的可执行程序，或者移至daemon本身，或者交给init。看起来我们还无法马上在启动过程中摆脱脚本，用C重写需要时间，且在有些时候也不行 shell 脚本太过灵活以至于无法脱离，但我们当然能让它们不像现在这样突出（被大量使用）。
简单测量shell 脚本对于启动过程的危害可以从你在系统完全启动后加载的第一个进程的PID看出来：启动、登录、打开终端，输入echo $$，对比Linux和MacOS，如下：Linux PID:1823，MacOS PID:154。自己测去吧。
接下来作者分析了Upstart对于这些问题的一些解决方法以及不足之处，接下来介绍了作者的最终结论： putting it all together:systemd
其特性就是...上文中如此多的翻译已经说明了其核心思路，就不具体介绍其中的详细概念了。值得一提的是systemd解析传统的SysVinit 脚本，将其依赖关系转化为 其原生的依赖关系，因此兼容 Sysvinit 脚本的同时仍能提供并行性，而 Upstart 无法对传统脚本进行并行化。且可通过DBus界面控制。
目前状态：已经可作为Sysinit或 Upstart的替代来使用，有一个修改过的 Fedora13qemu 镜像可供下载使用。http://surfsite.org/f13- systemd-livecd.torrent，作者秒表计时 Fedora13用Upstart启动27s，systemd24s（从grub到 gdm ,相同系统,相同设置，两次连续的启动过程中取较少者）。
FAQ
作者是？
Lennart Poettering（RedHat，大部分代码基础） Kay Sievers（Novell ，与前者共同讨论设计了细节） Harald Hoyer （RedHat） Dhaval Giani（前IBM） 此外还有Intel Suse,Nokia等多个公司的雇员
这是Red Hat的项目吗？ 否，这只体现了作者自己的设计选择。
将会在Fedora上使用? 一旦实验显示工作良好，社区会给出答案。如果是yes，当然会尝试令其进入Fedora
将会在OpenSuse上使用？ Kay处理此事，与我在Fedora 上观点相同
下面还有FAQ和很多细节，就不一一翻译了
Adobe Flash Player 10.1 just got finalized, you Mac and Linux folks have to wait a teensy bit longer
尽管受到苹果的批评和开放网站标准的支持者的批评，Flash平台的开发仍在继续。 Adobe今天发了最终版本的10.1版Flash浏览器插件。Adobe去年11月发布了Flash 10.1测试版，今年4月发布了一个候选发布版。Adobe今天发布的软件是第一个能够为台式电脑和Android 2.2设备上的移动Flash提供同样提供功能的最终发布版软件。
下载:Adobe Flash Player 10.1
Flash 10.1能够在支持的平台上实现硬件视频加速。但是，这个软件的预览版本在这方面包含一些瑕疵和不兼容的问题。目前还不清楚Adobe的最终版本是否修复 了这些问题。不过，考虑到在低功率设备上传送高清视频时Flash 10.1的主要目标，可以肯定地推测Adobe正在努力支持尽可能多的兼容性设备。
遗 憾的是Mac OS X用户将不得不等待一段时间才能得到硬件加速的视频功能。用于Mac OS X操作系统的具有硬件加速功能的“Gala”版Flash Player还没有到最终发布阶段，目前可以下载一个候选发布版。最终版本应该会很快推出。
用 户可以直接从Adobe网站为自己的Windows PC或者Mac机下载Flash 10.1版。Android 2.2手机用户可以从Android市场下载。
Adobe Flash Player 10.1 just got finalized so if you want silky smooth HD video, go download it now. Now everyone who's afraid of beta versions and release candidates can enjoy 10.1's full GPU acceleration of H.264 content. Well, almost everyone. Graphics acceleration is still limited to Windows PCs, you Mac and Linux folks have to wait a teensy bit longer. In any case, go and grab it. [Adobe]
编者按： this is why we support html5...
下载:Adobe Flash Player 10.1
Flash 10.1能够在支持的平台上实现硬件视频加速。但是，这个软件的预览版本在这方面包含一些瑕疵和不兼容的问题。目前还不清楚Adobe的最终版本是否修复 了这些问题。不过，考虑到在低功率设备上传送高清视频时Flash 10.1的主要目标，可以肯定地推测Adobe正在努力支持尽可能多的兼容性设备。
遗 憾的是Mac OS X用户将不得不等待一段时间才能得到硬件加速的视频功能。用于Mac OS X操作系统的具有硬件加速功能的“Gala”版Flash Player还没有到最终发布阶段，目前可以下载一个候选发布版。最终版本应该会很快推出。
用 户可以直接从Adobe网站为自己的Windows PC或者Mac机下载Flash 10.1版。Android 2.2手机用户可以从Android市场下载。
Adobe Flash Player 10.1 just got finalized so if you want silky smooth HD video, go download it now. Now everyone who's afraid of beta versions and release candidates can enjoy 10.1's full GPU acceleration of H.264 content. Well, almost everyone. Graphics acceleration is still limited to Windows PCs, you Mac and Linux folks have to wait a teensy bit longer. In any case, go and grab it. [Adobe]
编者按： this is why we support html5...
Thursday, June 10, 2010
BIOS已死，UEFI当立？微星说：今年有变，三年后UEFI普及。
根据THINQ网站的说法，微星提到BIOS将开始会有重大变革，今年我们会看到新的UEFI系统。最主要的原因是Intel Sndy Bridge芯片中有这样的产品项目。随着这芯片在今年底至明年初的到来，会逐渐普及。预计在三年后，BIOS差不多消失，几乎都是UEFI的天下了。
其实UEFI微星在2008年就曾推出过，有兴趣的朋友可参考微星官网2008年7月16日的新闻稿。简单来说，就是图像化的BIOS，类似于窗口接口的操作，有多国语言，可用鼠标，支持网络连结，能安装使用者自行撰写的安装程序等等特色。
会提到UEFI，应该是与微星将在今年晚些时候，推出 Sandy Bridge芯片主机板这件事有关。
此外，在程序设计俱乐部的网站上，有人提出UEFI BIOS code如何开始的问题，其中有提到UEFI提供者有好几间公司，价格也有差，也有人对不同的提供者有些评价（以回答来看的话，是有三家，看起来是Insyde的比较完善，但AMI的势力庞大呀），想要了解多一些些的朋友，可以参考这串讨论。
其实UEFI微星在2008年就曾推出过，有兴趣的朋友可参考微星官网2008年7月16日的新闻稿。简单来说，就是图像化的BIOS，类似于窗口接口的操作，有多国语言，可用鼠标，支持网络连结，能安装使用者自行撰写的安装程序等等特色。
会提到UEFI，应该是与微星将在今年晚些时候，推出 Sandy Bridge芯片主机板这件事有关。
此外，在程序设计俱乐部的网站上，有人提出UEFI BIOS code如何开始的问题，其中有提到UEFI提供者有好几间公司，价格也有差，也有人对不同的提供者有些评价（以回答来看的话，是有三家，看起来是Insyde的比较完善，但AMI的势力庞大呀），想要了解多一些些的朋友，可以参考这串讨论。
可吃Stardict的Nokia N900，也能当电子字典来用
相信大家都知道Nokia N900是Linux base的操作系统，所以要移植Linux原有的软件而言，相较于其它平台算是比较不难的。Stardict是颇具名气的字典程序，中文叫做星际译王，在PC平台上可是相当有名，Linux版使用的人更多，而且看来Stardict也有Maemo版本，名为MSStardict，所以N900也可以跑，而且同样可以吃Stardict的字典文件，而且具有发音的功能，等于有个电子字典在手机里。
感觉N900功能还不少，不知道上市以来销售的情况如何？另外，N900又有PR1.2新软件更新了，手上有的记得去更新一下，安装与设定步骤请看引用来源或下面连接。
感觉N900功能还不少，不知道上市以来销售的情况如何？另外，N900又有PR1.2新软件更新了，手上有的记得去更新一下，安装与设定步骤请看引用来源或下面连接。
N900整体来说其实相当的不错，其GNU/LINUX操作系统比ANDIORD的也好，WEBOS也好都纯正，CHROMIUM都能安上！
Tuesday, June 8, 2010
全球Linux用户市场占有率升至2.78%
XP用户全球市场占有率已经不足一半（>有人也许会问，Linux用户还会不会有可能跑再回到XP阵营呢？极少数Linux用户放弃Linux，又跑回XP阵营，完全有这种可能性。
6月7日下午1点左右，www.w3counter.com终 于发布了今年5月份的统计数字，看起来，该网站为此次发布大概做了不少审定工作，相比以往，拖延了几天才发布。公布的统计数字如下：
4月份 5月份
XP 51.86 49.95（下降最快）
Vista 18.19 17.60（下降明显）
Win 7 13.21 14.33（上升显著）
Mac OS 7.96 7.83（下降明显）
Linux 1.60 2.78（上升最快）
Win 2003 0.90 0.89（几乎持平）
iPhone 0.81 0.83（上升缓慢）
Win 2000 0.39 0.34（略有下降）
WAP 0.10 0.11（几乎持平）
Android 0.10 0.08（略微下降）
从以上统计数字我们可以看出，XP用户全球市场占有率已经不足一半
有人也许会问，Linux用户还会不会有可能跑再回到XP阵营呢？极少数Linux用户放弃Linux，又跑回 XP阵营，完全有这种可能性。但是，大规模地向XP“回归”已经是不可能了。为什么这样说呢？因为，进入今年5月份，有许多优秀的Linux桌面正式发 布，比如：Ubuntu 10.04（4月29日发布）、Fedora 13和Mint 9，事实已经证明，这些优秀的Linux计算机桌面可以作为XP“老古董”的通用替代品。
客观地说，数百万人群舍弃XP而选择Linux，不是在军队中吹一声口哨大家就开步向前走那样简单的事情。这种群 众性的大规模迁移（XP --> Linux ）必定有其内在的客观原因。当前，从XP升级到Win 7，还是从XP升级到Linux，在全球范围内，人们正在不断地探索着、思考着。特别是在我国境内，当前还缺少一个权威性的GNU/Linux中文网站， 把GNU/Linux原汁原味地介绍给国人，给人们指出正确的前进方向。
4月份 5月份
XP 51.86 49.95（下降最快）
Vista 18.19 17.60（下降明显）
Win 7 13.21 14.33（上升显著）
Mac OS 7.96 7.83（下降明显）
Linux 1.60 2.78（上升最快）
Win 2003 0.90 0.89（几乎持平）
iPhone 0.81 0.83（上升缓慢）
Win 2000 0.39 0.34（略有下降）
WAP 0.10 0.11（几乎持平）
Android 0.10 0.08（略微下降）
从以上统计数字我们可以看出，XP用户全球市场占有率已经不足一半
有人也许会问，Linux用户还会不会有可能跑再回到XP阵营呢？极少数Linux用户放弃Linux，又跑回 XP阵营，完全有这种可能性。但是，大规模地向XP“回归”已经是不可能了。为什么这样说呢？因为，进入今年5月份，有许多优秀的Linux桌面正式发 布，比如：Ubuntu 10.04（4月29日发布）、Fedora 13和Mint 9，事实已经证明，这些优秀的Linux计算机桌面可以作为XP“老古董”的通用替代品。
客观地说，数百万人群舍弃XP而选择Linux，不是在军队中吹一声口哨大家就开步向前走那样简单的事情。这种群 众性的大规模迁移（XP --> Linux ）必定有其内在的客观原因。当前，从XP升级到Win 7，还是从XP升级到Linux，在全球范围内，人们正在不断地探索着、思考着。特别是在我国境内，当前还缺少一个权威性的GNU/Linux中文网站， 把GNU/Linux原汁原味地介绍给国人，给人们指出正确的前进方向。
编者按：我听说当市场占有率达到5%的时候，主流软件都会提供支持。。。期待啊
Monday, June 7, 2010
GNOME Shell的“Alt＋Tab”革新
GNOME 3的GNOME Shell，将使任务切换提升到一个新的境界：它完美地结合了“窗口切换”和“应用程序切换”。
默认情况下，在GNOME 3下切换任务，也是像Mac OS X一样是基于应用程序的，而非窗口，效果也是类似OS X（当然GNOME Shell可以通过CSS来自定义效果）。
不过，GNOME Shell将窗口模式也很无缝地结合了进去，如果一个应用程序有多个窗口，GNOME Shell会在其下方显示一个方向图标。如图所示，当你用Alt＋Tab切换至Empathy时，此刻只需要松开“Tab”（不需要像Mac OS X一样全部松开），接着按下“`”，即可以在具体的某个应用程序的多个窗口之间进行切换。操作非常流畅！
经常打游戏的朋友一定熟悉：WSAD吧？嗯，这是“上下左右”导航嘛～你知道吗？在GNOME Shell中也能用它！
在用“Alt＋Tab”切换任务时，要想遍历至前一个时咋办，毕竟GNOME Shell下“Alt＋`”已经被用在窗口切换中了，不能像OS X一样进行反遍历。难道用“Shift＋Alt＋Tab”？
不需要。在“Alt＋Tab”激活任务切换以后，你马上可以按WSAD来进行你熟悉的方向导航。
Alt＋A：向左移动。
Alt＋D：向右移动。
Alt＋S：向下移动。
Alt＋W：向上移动。
很方便吧？反正我是用的很上手！毕竟我也是玩过几年游戏的！
另外，可千万不要以为，如果没有像Empathy这样开了多窗口的话，Alt＋S和Alt＋W就无效了，相反，依然有效！
此刻，如果我按Alt＋S在一个单窗口应用程序下面，GNOME Shell会将其缩略图也显示出来！这个设计相当赞！
GNOME Shell的任务切换完全保留了原有的习惯，在原有习惯的基础上加入革新的元素，大大加强了任务切换的灵活性。新增的快捷键很好的满足了有WSAD需求的用户，同时老用户也可以继续用旧的快捷键。
在对比了经典GNOME、Mac OS X和GNOME Shell的任务切换机制后，我个人认为GNOME Shell的机制是最强大和有效果的。
正所谓细节决定一切，GNOME Shell将这个细节打磨的这么完美，我有理由相信其他细节也会像这样一样得到改善。
毕竟现在GNOME 3还在不断开发当中，那些不完美都是可以解决的！
转自linux桌面中文网
默认情况下，在GNOME 3下切换任务，也是像Mac OS X一样是基于应用程序的，而非窗口，效果也是类似OS X（当然GNOME Shell可以通过CSS来自定义效果）。
不过，GNOME Shell将窗口模式也很无缝地结合了进去，如果一个应用程序有多个窗口，GNOME Shell会在其下方显示一个方向图标。如图所示，当你用Alt＋Tab切换至Empathy时，此刻只需要松开“Tab”（不需要像Mac OS X一样全部松开），接着按下“`”，即可以在具体的某个应用程序的多个窗口之间进行切换。操作非常流畅！
经常打游戏的朋友一定熟悉：WSAD吧？嗯，这是“上下左右”导航嘛～你知道吗？在GNOME Shell中也能用它！
在用“Alt＋Tab”切换任务时，要想遍历至前一个时咋办，毕竟GNOME Shell下“Alt＋`”已经被用在窗口切换中了，不能像OS X一样进行反遍历。难道用“Shift＋Alt＋Tab”？
不需要。在“Alt＋Tab”激活任务切换以后，你马上可以按WSAD来进行你熟悉的方向导航。
Alt＋A：向左移动。
Alt＋D：向右移动。
Alt＋S：向下移动。
Alt＋W：向上移动。
很方便吧？反正我是用的很上手！毕竟我也是玩过几年游戏的！
另外，可千万不要以为，如果没有像Empathy这样开了多窗口的话，Alt＋S和Alt＋W就无效了，相反，依然有效！
此刻，如果我按Alt＋S在一个单窗口应用程序下面，GNOME Shell会将其缩略图也显示出来！这个设计相当赞！
GNOME Shell的任务切换完全保留了原有的习惯，在原有习惯的基础上加入革新的元素，大大加强了任务切换的灵活性。新增的快捷键很好的满足了有WSAD需求的用户，同时老用户也可以继续用旧的快捷键。
在对比了经典GNOME、Mac OS X和GNOME Shell的任务切换机制后，我个人认为GNOME Shell的机制是最强大和有效果的。
正所谓细节决定一切，GNOME Shell将这个细节打磨的这么完美，我有理由相信其他细节也会像这样一样得到改善。
毕竟现在GNOME 3还在不断开发当中，那些不完美都是可以解决的！
转自linux桌面中文网
In the left corner, the 4-inch Samsung Galaxy S smartphone. In the right, the 7-inch Samsung Galaxy Tab. Not pictured: the tablets that will dwarf both. According to a South Korean newspaper, the Galaxy Tab is only one of three touchscreen tablet devices Sammy's got planned: while the 7-inch model is slated for August, 8-inch and 10-inch varieties are rumored to appear in November and December respectively. Though the "high-ranking industry official" who informed the publication sadly failed to mention a price, he or she did add that the devices will launch with SK Telecom -- the second time we've heard that -- meaning if any of this is true, they've almost certainly got cellular modems inside. All we need now is some official confirmation, and perhaps a nice, binding promise of OTA Froyo.
据国外媒体报道，三星电子公司计划今年第三四季度在韩国首先推出几款7/8/10寸屏幕的Galaxy Tab系列平板电脑产品。上周早些时候，三星官方Twitter上透露了一款7寸屏平板电脑的信息，宣称这款机型将于今年8月份推出；而8/10寸屏机型 则分别预计将于10/12月份推出.这些平板电脑将运行Android系统，使用TouchWiz界面设计，并有望内置3G无线互联功能。南韩最大的移动 运营商SK电信则将负责这几款机型的销售。
编者按：是不是觉得这条新闻好锉啊，看看下边的再联系一下呢
据市调公司Gartner统计，三星公司生产的处理器已经占到2009年手机所用处理器总数的39.2%之多，位居各厂商之首，其排位比2008年上升了 两位。另据这家市调公司统计，三星同时还是世界上最大的电脑内存芯片厂商，2009年三星公司生产的内存芯片在移动应用市场占据了39.2%的份额，一举 超过了08年的领头羊德州仪器公司。而日本瑞萨公司则在移动应用内存芯片市场上以27.7%的市占率位居第二，前年的老大哥德州仪器公司则仅占18.9%，名次滑落到了第三，相比之下前年这家公司的市占率则为30.9%之多。
Friday, June 4, 2010
Linaro，缩短手机的开发时程和减少成本
SoC（System on Chip）芯片商有很多家，智能型手机用的操作系统也有很多。对开发芯片的芯片商来说，为这些操作系统写各自的程序，就成了耗时耗钱的一件事。为了减少支 出，SoC 界和 Linux 界的大手们 -- ARM、IBM、Freescale、ST-Ericsson、TI 、Linux Foundation -- 决定合资成立一间非营利的公司「Linaro」，其主要的目的是有一批独立在所有厂商之外的工程师，专门写一套可以协助 Linux-based 的操作系统（Android、Meego、Ubuntu、WebOS etc）和 SoC 芯片的各项功能间的软件接口。对 SoC 商来说，这也意味着许多 SoC 芯片上的功能势必要以 Linaro 的产品为中心标准化，但另一方面这可以省下许多目前是重复的开发成本。
初步 Linaro 会有约 25 名工程师，未来将逐步扩大到百人左右，年预算则在数千万到一亿美元之间。预计的开发时程是每六个月推出一个新的版本，第一版将在 11 月为 ARM Cortex-AX 家族推出。这个公司的成立对消费者来说其实没有什么关连，但新的、更快的 CPU 或许可以因此而更快进入装置中，对消费者来说也是福音啊！
这个不知道对linux有什么促进作用呢？
初步 Linaro 会有约 25 名工程师，未来将逐步扩大到百人左右，年预算则在数千万到一亿美元之间。预计的开发时程是每六个月推出一个新的版本，第一版将在 11 月为 ARM Cortex-AX 家族推出。这个公司的成立对消费者来说其实没有什么关连，但新的、更快的 CPU 或许可以因此而更快进入装置中，对消费者来说也是福音啊！
这个不知道对linux有什么促进作用呢？
Thursday, June 3, 2010
Subscribe to:
Posts (Atom)