2010-05-21

Linux デスクトップ PC の時代は来るのか?

Linux と付き合いを始めて既に 15 年近く経ちました。そもそも Linux を使い始めるきっかけは、何といっても Windows 95 で使う Visual Studio より GNU/Linux の開発環境の方が、自分にとって魅力的だったからです。それ以来、もっと Linux が一般に普及すればいいのにと思って使い続けています。そんな中で一時は Microsoft の牙城であるデスクトップ OS とオフィススイートの市場で、Linux のデスクトップ PC が脅威になるだろうと喧伝された時期がありました。

[1] Linuxデスクトップの台頭に苦悩するマイクロソフト

でも、実際には、今でもそうはなっていません。そもそも、かつての Linux 関係誌のほとんどが休刊に追い込まれている状況をみると、言わずもがなという感はあります。

ちょっと古いですが、以下のような記事があります。

[2] Linuxデスクトップは市場に受け入れられていない--その現実を直視してみる

上の記事の、筆者が挙げている Linux がデスクトップ市場で普及しない理由の 1 から 3 は、ごく一般的なユーザーの視点では納得ができませんが、

4 企業は非難の矛先を向ける対象が欲しい

は頷けます。

自分が勤めている会社では、相変わらずの Windows XP がデスクトップ PC です。IT 部門が、基幹系も含めて Windows 系のシステムしか導入していないから仕方ありません。でも周りの人にいろいろ聞いてみると、Windows に対する専門的な知識の少なさには驚かされます。思うに、Excel, Word あるいは PowerPoint そしてメールクライアントソフト (Outlook Express) が使用できれば、業務では事が足りているようです。それに一旦企業に普及してしまった環境を変えるということは、もうなかなかできないのかもしれません。

一方、自宅での使用環境を振り返ってみると、最初は「Windows をメインに、Linux を切り替えて」使用していたのですが、ある時点で勇気を出して「Linux をメインに、Windows を切り替えて」使用するようになって以来、Windows を滅多に使用しなくなってしまいました。

それでも世間一般の環境も利用できるように、なんとか Windows Vista までは切り替えて利用できるように追従してきましたが、Windows 7 でついに挫折です。Windows をほとんど使わないので投資効果が全然ありません。

自宅では Windows がなくても不自由を感じないので、これはきっとある意味では慣れなのでしょう。また、長く使っているので信頼感とか安心感もあります。だから、大多数のユーザーにとっては、会社でも使っている Windows を自宅でも使うことは、なにかと便利であるし、Windows の細かいところを知らなくとも、なんとなく「慣れ」とか「安心感」があるのだと思います。MacOS なんていう、車で言うとポルシェみたいなブランドの OS も確かに聞いたことがあるけれど、実質的に Windows 以外の選択肢があるという事実すら認識していないのかもしれません。そこまで Windows を世間に普及させたのですから、そういう意味ではどう考えても Microsoft の市場における勝利です。

Linux のデスクトップ環境が Windows を凌駕するためには、Linux のデスクトップでなければ実現できない、しかも大多数を惹きつける「なにか」がなければなりません。Linux でしか実現できないなんてものはあるのでしょうか?

あるとすれば、もう Linux とは言えないかもしれない Chromium OS (Google Chrome OS) のようなアプローチが、将来そうなる可能性を秘めています。しかし、先の記事にも書いてある通り、現実的な話題になるのは、まだまだ先の話です。

[3] Download Chrome OS VMWare image After Google announced the availability of the Chrome OS... - gdgt

ちなみに Web クライアントのシェアを、デスクトップ PC のシェアと同じと考えれば、今のところ Linux のシェアは 1% 程度しかありません。

[4] Usage share of operating systems - Wikipedia, the free encyclopedia
 

2010-05-08

【備忘録】deltarpm の applydeltarpm

RPM の差分インストール (delta RPM, drpm) の処理について、yum のプラグイン presto にばかり目が行ってしまい、直接、差分 RPM を処理できる deltarpm パッケージがあることを知りませんでした。Google で drpm をキーワードに情報収集を続けていたことも、(インストールされているにもかかわらず)deltarpm をすぐに見つけられなかった原因のひとつかもしれません。

とにかく deltarpm パッケージの存在を知ったので、遅ればせながら試してみました。

$ rpm -q deltarpm
deltarpm-3.5-0.7.20100121git.fc13.x86_64
$ rpm -ql deltarpm
/usr/bin/applydeltarpm
/usr/bin/combinedeltarpm
/usr/bin/makedeltarpm
/usr/bin/rpmdumpheader
/usr/share/doc/deltarpm-3.5
/usr/share/doc/deltarpm-3.5/LICENSE.BSD
/usr/share/doc/deltarpm-3.5/README
/usr/share/man/man8/applydeltarpm.8.gz
/usr/share/man/man8/combinedeltarpm.8.gz
/usr/share/man/man8/makedeltarpm.8.gz
$

applydeltarpm を利用すると、差分 RPM から、新しい RPM を生成(再構成)することができます。差分 RPM を使ってインストールされたパッケージを直接アップデートすることははできません。しかし、そういうものが必要であれば、機能を組み合わせて、表面上は直接アップデートしてくれるようなツールができそうです。

man makedeltarpm の出力の一部を日本語に訳してみました。

NAME
applydeltarpm - 差分 RPM から RPM を再構成します

SYNOPSIS
applydeltarpm [-v] [-p] [-r oldrpm] deltarpm newrpm

DESCRIPTION
applydeltarpm は、バイナリの差分データを、古い RPM ファイルあるいはインス
トールされたディスク上のデータに適用して新しい RPM を生成します。古い RPM
は -r オプションで指定し、指定がない場合はディスク上のデータが使用されま
す。
-p オプションを指定すると完了率が表示され、-v オプションを指定すると、処
理状態が出力されます。

実行例を以下に示します。

$ rpm -q sawarabi-gothic-fonts
sawarabi-gothic-fonts-20100315-1.fc12.noarch
$ ls
sawarabi-gothic-fonts-20100315-1.fc12_20100430-1.fc13.noarch.drpm
$ applydeltarpm -p -v sawarabi-gothic-fonts-20100315-1.fc12_20100430-1.fc13.noar
ch.drpm sawarabi-gothic-fonts-20100430-1.fc13.noarch.rpm

reading deltarpm
applying delta
100 percent finished.
$ ls
sawarabi-gothic-fonts-20100315-1.fc12_20100430-1.fc13.noarch.drpm
sawarabi-gothic-fonts-20100430-1.fc13.noarch.rpm
$ su
パスワード:
# rpm -Uvh sawarabi-gothic-fonts-20100430-1.fc13.noarch.rpm
準備中... ########################################### [100%]
1:sawarabi-gothic-fonts ########################################### [100%]
#

deltarpm パッケージの makedeltarpm を利用すれば、差分 RPM を生成出来ます。しかしながら自分にとっては、前回紹介した presuto-utils パッケージの createdeltarpms の方が操作が簡単のように思います。使用例を以下に示しました。

$ ls
sawarabi-gothic-fonts-20100315-1.fc12.noarch.rpm
sawarabi-gothic-fonts-20100430-1.fc13.noarch.rpm
$ makedeltarpm sawarabi-gothic-fonts-20100315-1.fc12.noarch.rpm sawarabi-gothic-
fonts-20100430-1.fc13.noarch.rpm sawarabi-gothic-fonts-20100315-1.fc12_20100430-
1.fc13.noarch.drpm

$ ls
sawarabi-gothic-fonts-20100315-1.fc12.noarch.rpm
sawarabi-gothic-fonts-20100315-1.fc12_20100430-1.fc13.noarch.drpm
sawarabi-gothic-fonts-20100430-1.fc13.noarch.rpm
$

2010-05-05

【備忘録】drpm パッケージの作り方

Fedora 11 から yum のプラグインとして採用された、RPM の差分インストール (delta RPM, drpm) を処理する presto は、今では当たり前の機能のようになってしまっています。しかし、どうやって drpm を作成するのか知らなかったので、調べてみました。

drpm を作成するには、presto-utils が必要になります。

# yum install presto-utils

presuto-utils に収録されている createdeltarpms(処理の実体は Python のスクリプト)が RPM の差分を生成します。

createdeltarpms [options] directory-of-packages directory-of-deltarpms

Options:
-d, --dist-update <dir> = optional directory containing old distribution
to create an update from
-c, --count <number> = optional maximum number of deltarpms to create
per package. Default is maximum available
-n, --no-first = Don't create deltarpm against first rpm if number exceeds
count. Useful if you are running a continually-updated
distribution rather than one with set release cycles.
-q, --quiet = run quietly
-v, --verbose = run verbosely
-h, --help = show this help
-V, --version = output version

試しに、rpms というフォルダに、sawarabi-gothic-fonts の二種類のリリースの RPM パッケージをコピーし、drpms という空のディレクトリを用意して、createdeltarpms を実行してみました。

$ ls rpms
sawarabi-gothic-fonts-20100315-1.fc12.noarch.rpm
sawarabi-gothic-fonts-20100430-1.fc13.noarch.rpm
$ createdeltarpms ./rpms ./drpms
/usr/lib/python2.6/site-packages/presto-utils/dumpMetadata.py:23: DeprecationWar
ning: the md5 module is deprecated; use hashlib instead
import md5
/usr/lib/python2.6/site-packages/presto-utils/dumpMetadata.py:24: DeprecationWar
ning: the sha module is deprecated; use the hashlib module instead
import sha
Using base dir: rpms
Using destination dir: drpms
Generated delta rpm for sawarabi-gothic-fonts.noarch - 20100315-1.fc12 => 201004
30-1.fc13
$ ls drpms
sawarabi-gothic-fonts-20100315-1.fc12_20100430-1.fc13.noarch.drpm

RPM レポジトリを公開しているわけではないので、差分パッケージの作成方法が解ったからといって、なにかにすぐ使えるということはなさそうです。差分の操作をローカルでもう少しできるのかもしれません。
 

参考サイト


[1] 差分アップデートでダウンロード時間を短縮!--Fedora 11のDelta RPMを活用する - builder by ZDNet Japan
[2] 着実な進化を見せるFedora 11新機能レビュー - SourceForge.JP Magazine : オープンソースの話題満載
 

2010-05-04

CMake と クロスコンパイル

Get MinGW Cross Compiler at SourceForge.net. Fast, secure and Free Open Source software downloads
CMake を利用して、Linux 上で GTK+ のサンプルプログラムをビルドしてみました。使用マシン / OS は Fedora 13 β版 x86_64, 使用したサンプルは、以下のソース hello_gtk.c です。

#include <gtk/gtk.h>
 
static void
hello (GtkWidget * widget, gpointer data)
{
g_print ("Hello World!\n");
}
 
static gboolean
delete_event (GtkWidget * widget, GdkEvent * event, gpointer data)
{
g_print ("delete event occurred\n");
 
return TRUE;
}
 
static void
destroy (GtkWidget * widget, gpointer data)
{
gtk_main_quit ();
}
 
int
main (int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *button;
 
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
 
g_signal_connect (G_OBJECT (window), "delete_event",
G_CALLBACK (delete_event), NULL);
g_signal_connect (G_OBJECT (window), "destroy", G_CALLBACK (destroy), NULL);
 
gtk_container_set_border_width (GTK_CONTAINER (window), 10);
button = gtk_button_new_with_label ("こんにちは、世界!");
 
g_signal_connect (G_OBJECT (button), "clicked", G_CALLBACK (hello), NULL);
g_signal_connect_swapped (G_OBJECT (button), "clicked",
G_CALLBACK (gtk_widget_destroy),
G_OBJECT (window));
 
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (button);
gtk_widget_show (window);
 
gtk_main ();
 
return 0;
}

CMake 用に以下の CMakeLists.txt というテキストファイルを用意して、hello_gtk.c と同じディレクトリに保存します。

project(Hello)
cmake_minimum_required(VERSION 2.8)
 
include(FindPkgConfig)
pkg_check_modules(GLIB2 glib-2.0)
pkg_check_modules(GTK2 gtk+-2.0)
 
include_directories(${GTK2_INCLUDE_DIRS})
link_directories(${GTK2_LIBRARY_DIRS})
link_libraries(${GTK2_LIBRARIES})
 
if(MINGW)
set(CMAKE_C_FLAGS -mms-bitfields)
set(CMAKE_CXX_FLAGS -mms-bitfields)
set(CMAKE_EXE_LINKER_FLAGS -mwindows)
endif(MINGW)
 
add_executable(hello hello_gtk.c)

Linux ネイティブなビルド


まずは、Linux ネイティブなビルドをしてみましょう。カレントディレクトリが hello_gtk.c と同じとします。

$ mkdir unix
$ cd unix
$ cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/lib64/ccache/gcc
-- Check for working C compiler: /usr/lib64/ccache/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib64/ccache/c++
-- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- checking for module 'glib-2.0'
-- found glib-2.0, version 2.24.0
-- checking for module 'gtk+-2.0'
-- found gtk+-2.0, version 2.20.0
-- Configuring done
-- Generating done
-- Build files have been written to: /home/bitwalk/work/gtk_hello/unix
$ make
Scanning dependencies of target hello
[100%] Building C object CMakeFiles/hello.dir/hello_gtk.c.o
Linking C executable hello
[100%] Built target hello
$ ./hello
Hello World!
$ cd ..


MinGW 用クロスビルド


まず、MinGW クロスコンパイル環境に対応した CMake 用設定ファイル Toolchain-i686-mingw32.cmake を用意し、適当なディレクトリ(ここでは、$HOME/work/cmake)に保存しておきます。

set(CMAKE_SYSTEM_NAME Windows)
 
# specify the cross compiler
set(CMAKE_C_COMPILER /usr/bin/i686-pc-mingw32-gcc)
set(CMAKE_CXX_COMPILER /usr/bin/i686-pc-mingw32-g++)
 
# set PKG_CONFIG_PATH for MinGW Cross Compile Environment
set(ENV{PKG_CONFIG_PATH} /usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig)
 
# where is the target environment
set(CMAKE_FIND_ROOT_PATH /usr/i686-pc-mingw32/sys-root/mingw)

その上で、次のようにして cmake を実行して Makefile を生成して、make します。

$ mkdir win
$ cd win
$ cmake -DCMAKE_TOOLCHAIN_FILE=~/work/cmake/Toolchain-i686-mingw32.cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/i686-pc-mingw32-gcc
-- Check for working C compiler: /usr/bin/i686-pc-mingw32-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/i686-pc-mingw32-g++
-- Check for working CXX compiler: /usr/bin/i686-pc-mingw32-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- checking for module 'glib-2.0'
-- found glib-2.0, version 2.23.4
-- checking for module 'gtk+-2.0'
-- found gtk+-2.0, version 2.19.6
-- Configuring done
-- Generating done
-- Build files have been written to: /home/bitwalk/work/gtk_hello/win
$ make
Scanning dependencies of target hello
[100%] Building C object CMakeFiles/hello.dir/hello_gtk.c.obj
Linking C executable hello.exe
[100%] Built target hello
$ wine hello.exe
Hello World!
$ cd ..


まだまだ CMake を使いこなせてはいませんが、とにかく、クロスコンパイル環境でも CMake が使える事を確認できました。
 

参考サイト


[1] CMake Cross Compiling - KitwarePublic
 

2010-05-03

LLVM 2.7 のベンチマーク (2)

LLVM のベンチマークと言っても、コンパイルに使用するライブラリのほとんどが GCC でビルドされたものであることを考えると、前回の Tcl を使ったベンチマークは、あまりにもアバウトな比較だったように思います。
 
そこで、今回は、GMP を利用した円周率の計算プログラムで、GCC と LLVM/clang のパフォーマンスを較べてみました。計算の主要部分である GMP ライブラリを GCC と clang でビルドして用いれば、もう少し精度の良い比較が出きると考えたからです。
 
GMP は最新の 5.0.1 のスタティックライブラリを GCC, LLVM/clang それぞれでビルドしてローカルアカウントの領域にインストール、そのライブラリを使い、円周率計算プログラムを、それぞれに対応するコンパイラでビルドして比較してみました。
 
円周率の計算プログラムのソースは、GNU/Linux上で円周率の計算をおこなうで紹介されている pi.c を利用させていただきました。
 
GMP をビルドするのに使用したスクリプト build-gmp.sh を以下に示しました。このスクリプトは作業エリア $HOME/work/Pi/GMP/ 内に GMP のソースがあり、インストール先が使用したコンパイラに応じて、$HOME/work/Pi/GMP/${CC} であることを想定しています。

#!/bin/sh
 
# C compiler
#export CC=gcc
export CC=clang
 
# constants
export ver="5.0.1"
 
# remove old sources
echo "### Removing old sources & binaries"
rm -fR gmp-${ver}
 
# extract sources
echo "### Expanding sources to build"
tar jxvf gmp-${ver}.tar.bz2
 
# build GMP
echo "### build GMP"
cd gmp-${ver}
./configure --prefix=$HOME/work/Pi/GMP/${CC} \
--disable-shared --enable-static
make
make install

GCC と LLVM/clang でそれぞれビルド、円周率を計算した結果を以下に示しました。使用した PC は Thinkpad X31 です。なお、あらかじめ glibc のスタティックライブラリの RPM glibc-static がインストールされている必要があります。

### GCC 4.4.3
 
$ time ./build-gmp.sh
real 3m28.100s
user 0m50.568s
sys 1m19.172s
 
$ ls -l ./gcc/lib/libgmp.a
-rw-r--r--. 1 bitwalk bitwalk 816078 2010-05-03 23:24 ./gcc/lib/libgmp.a
 
$ gcc -static -O2 -I./gcc/include pi.c ./gcc/lib/libgmp.a -o pi
$ time ./pi > pi.dat
real 0m19.522s
user 0m18.564s
sys 0m0.661s
 
 
### LLVM/clang 2.7
 
$ time ./build-gmp.sh
real 4m2.098s
user 1m11.869s
sys 1m30.534s
 
$ ls -l ./clang/lib/libgmp.a
-rw-r--r--. 1 bitwalk bitwalk 739022 2010-05-03 23:36 ./clang/lib/libgmp.a
 
$ clang -static -O2 -I./clang/include pi.c ./clang/lib/libgmp.a -o pi
$ time ./pi > pi.dat
real 0m19.584s
user 0m18.661s
sys 0m0.622s

今回は、GMP のビルドに要した時間も計測してみましたが、意外にも clang でビルドした場合の方が時間が掛かっています(+16.3% 程度)。バイナリ libgmp.a のサイズは clang でビルドした方が明らかに小さく(-9.4% 程度)、実行速度は GCC よりやや遅い(+0.3% 程度)という結果になりました。
 
余談になりますが、Fedora 13(β版)の RPM パッケージ GMP 4.3.1 のスタティックライブラリを使って普通にビルドした場合の計算時間も確認しました。GMP 5.0.1 との差にびっくりです。

$ gcc -static -O2 pi.c -lgmp -o pi
$ time ./pi > pi.dat
real 0m38.492s
user 0m37.361s
sys 0m0.605s

参考サイト


[1] GNU/Linux上で円周率の計算をおこなう
[2] The GNU MP Bignum Library
 

2010-05-02

LLVM 2.7 のベンチマーク

日リリースされたばかりの LLVM 2.7 のベンチマークを、前回と同様に取ってみました。OS / マシン は、Fedora 13(β版)/ 32bit の古いノート PC (ThinkPad X31) を使用しています。

LLVM/clang の RPM は、rawhide のパッケージ llvm-2.7-0.1.pre1.fc14.src.rpm の spec ファイルを書き換え、LLVM と clang のソースファイルも 2.7 リリース版に置き換えてビルドしたパッケージを使用しました。

ベンチマークに使用した Tcl は、nightly-cvs 版 tcl-20100430.tar.gz です。 以下に GCC 4.4.3 と LLVM/clang-2.7 のベンチマーク結果を示しました。

Fedora 13 (32bit i686)
tcl-20100430
# GCC 4.4.3
1000000 repeats in 0.146364
10000 iterative factorial(100) in 74.794581
10000 iterative factorial(100) with 'if' in 75.131586
10000 recursive factorial(100) in 90.248124
1000 exec calls in 5.680614
total time was 246.00126899999998
 
# LLVM/clang 2.7
1000000 repeats in 0.170331
10000 iterative factorial(100) in 77.283847
10000 iterative factorial(100) with 'if' in 77.356544
10000 recursive factorial(100) in 93.987031
1000 exec calls in 5.631689
total time was 254.429442

依然として clang で生成したバイナリの方が遅いのですが、その差は 3 - 4% 程度でした。

clang-2.7 では C++ のセルフホスティングに対応し、LLVM と clang のビルドが可能になったということです。次の興味としては、clang でビルドした LLVM/clang のパフォーマンスがどうなのかなのですが、まずは clang でビルド出来ることを確認してみます。