« 期待が高まりますなぁ。 | トップページ | MacOSに先越されそうですねぇ。(笑) »

一方でこんな記事もあるようで。

2009年に出荷されたネットブックの3分の1がGNU/Linuxを搭載--米調査 - Editor’s FYI - ZDNet Japan

別の統計では、Dellの通販を勘定してなかったとか。
Dellのネットブックの出荷は、Linux搭載が1/3を占める、と記事中にありました。

まあ、これ、以前に松本さんが指摘してたように、OSライセンスをすでに持っているユーザーが、XP Homeではなく、Professinalを使いたいので、安価なUbuntu搭載のネットブックを購入し、XPに載せ替えている場合も、多々ある、らしい、との話もあり。

出荷数、すなわち稼働数ってこともないんだろうな、と思います。
その前のエントリ「年末だからか?」の元記事の方で参照しているグラフは、稼働数を現しているので、まあ、こっちの数字、すなわち1%程度って方が、リアルな数字なんでしょうね。

とはいえ。
数字として出荷数があれば、数字のマジックで、一般ユーザーは、Linuxって普及しつつあるのかな、と興味を持つ可能性もあり。
そうなれば、いずれは、Ubuntuを潰してXPに載せ替えるとしても、その前にちょっと触ってみよう、とか思う人も増えてくるのかも知れません。

いずれにせよ、「Ubuntuに触る」機会が、これまでは圧倒的に少なかったのが、Dellのおかげで、ネットブックとは言え、触れることができる機会が増えたのは、Ubuntuユーザーにとっては喜ばしいことではないかな、と思います。

まあ、ね、それがそのまま普及の足がかりになるとは思いませんけど。
来年は、例えば、0.5%くらい伸びるといいよね。(笑)

|

« 期待が高まりますなぁ。 | トップページ | MacOSに先越されそうですねぇ。(笑) »

Ubuntu」カテゴリの記事

パソコン・インターネット」カテゴリの記事

コメント

> 来年は、例えば、0.5%くらい伸びるといいよね。(笑)

いや、実際、ここ数年の伸びの傾向を外挿すれば、その程度伸びれば御の字という感じですね。けれど、逆に言えばそれに近いぐらいは伸びそうな気配です。で、その調子でいけば、数年後には3%とか、そういう目に見えるシェアまで到達するんだろうなという感じです。

Firefoxのシェアが3%ぐらいとったころのことをよく覚えているんですが、そこから10%まではあっという間でしたね。OSとブラウザではタイムスケールが違うようなんですが、「はじめちょろちょろ、なかパッパ」というのは多くの成長曲線に当てはまるものだと思います

投稿: 松本 | 2009年12月10日 (木) 22時10分

FireFoxの例にならうといいんですけどね。
実際、数%を超えると、たぶん、あちこちで注目されるようになって、ギーク以外のひとが使うようになってくるんだと思うんですよ。
まあ、確かにブラウザほどの気軽さではOSは語れないかも知れませんが、例えば、最近のノートPCの買い替え状況って解らないんですが、結構古い機械(2~3年前の機械)を死蔵しているひとは多いと思うんですね。
#まだなんかに使えそう、みたいな。

なので、そういうちょっと古い端末で使ってみようか、って気持ちにはなるんだと思うんですよ。注目されれば。
まあ、今、Ubuntuがわりとそういう状況なので、この2年内に、「一般ユーザーが」感心するだけの完成度に持って行ければ、10%まではあっという間、というのも夢ではなくなると思います。

やはり、OSインストールは敷居が高いので、この辺、なんかクリアする策があればいいんですけどね。

投稿: かおりん | 2009年12月10日 (木) 22時16分

僕は逆にXPの入ったEee PCを買ってUbuntuを入れましたよ。
そういうのも考慮すれば実はもっともっと広まってるハズ…!(`・ω・´)


…と、まあそれぐらい楽観的にいかないとw
くらい話ばかりしてもしょうがないですよ(^^

昨年にくらべるとUbuntu関連のニュースだってものすごくたくさん流れるようになりましたし、
実際ひろまってますよ。
# うちの学校の教師も一人Ubuntu使ってる人がいましたw

投稿: わさびー | 2009年12月10日 (木) 22時45分

売ってないですからねぇ。Linux入ったEeePC。(笑)
今のところ、Dell以外ではUbuntu使いたければ、自前で入れるしかない、ってのが実状で。

この記事の予測の「Linux」の中には、なんとなく「ChromeOS」も含まれているような気がしてなりません。
今のところはあれも、カーネルはLinuxですしね。
#今後は解りませんが。

棲み分けして欲しいとも思いませんが、まあ、少しでも普及してくれれば、それで。

今のところは、この分野ならLinuxが強い、ってのがないのが痛いですよね。(^^;

そういう、強みがデスクトップLinuxにもあると、普及には弾みがつくんですが。

こう、流行りのアイドルグループが、実はLinux使ってます、とかね。(笑)

投稿: かおりん | 2009年12月10日 (木) 23時13分

やっぱわさびーさんとかおりんさんでUbuntu専用のオープンソースエロゲ企画立ち上げるべきだと思います(爆)。

投稿: cametan | 2009年12月11日 (金) 01時51分

エロゲ作るには、絵描きがいるんですよ。(笑)

投稿: かおりん | 2009年12月11日 (金) 05時38分

>>エロゲ作るには、絵描きがいるんですよ。(笑)

多分、最初はテキスト「だけ」でいいんじゃないですか?
オープンソースだから「絵描き募集」とか言って、そこは開けとく(笑)。

投稿: cametan | 2009年12月11日 (金) 05時47分

いやぁ、それじゃあ普及の原動力にならないでしょう。(爆)

カリスマ絵描き連れてきて、もう絵だけで強引に引っ張らないと。
#これじゃ萌え☆彡OSだ。

投稿: かおりん | 2009年12月11日 (金) 06時16分

ああ、やっぱエロゲって絵描きなのかなあ。

フランス書院文庫が萌え絵表紙で文庫出してたりするんですが、

美少女文庫:
http://www.france.jp/servlet/Satellite?c=Page&cid=1176293009036&p=1176754150848&pagename=bisyojo%2FB_Simple3

やっぱり「中身」は小説ですよね。
だから、結局テキスト中心でも構成しっかりしてればウケるのかな、って気もするんですが、甘いですかね(笑)?

「かまいたちの夜」みたいなサウンドノベル系だとダメなのかしら?
ネットで引っ張ってきた写真コラージュしたりして(笑)、それで行く、とか(笑)。
ダメか(笑)。

投稿: cametan | 2009年12月11日 (金) 07時29分

エロゲは、基本テキストですよ。それは間違いない。
でも、購買意欲をそそるのは、絵ですね。
#一部システム、ってひともいるかも。3Dものとか。

まあ、そんでも、どんだけシナリオがタコでも、絵が良ければユーザーは納得しますけど、これが逆だと、納得しないし、そもそも手に取らないんですよね。
#って本格エロゲ談義に入りそうなので、やめときますが。

エロゲというジャンルなら、かまいたちの夜的なものはアリですが、Ubuntu普及の原動力になるようなもの、を目指すなら、絵は抜きに語れないでしょう。
ま、OpenGL使った3Dものでもアリかも知れません。
#フリーで出回ってる3Dモデル使って見たりな。MikuMikuダンスのアレとか。

投稿: かおりん | 2009年12月11日 (金) 08時54分

なるほど。OpenGLって手があるか。
でもPython辺りでOpenGLって操作出来るのかな?

僕も今、Schemeでアドヴェンチャーゲームって作れないか、って色々調べてはいるんですよね。
エロゲやれるか、とか(笑)。
でも、やっぱり「絵」とか「音」とかどうやって繋げるんだ、って辺りで引っかかっているのです。

C言語での「アドヴェンチャーゲームの作り方」とか読んでて

「随分メンドっちい事してんな」

とか感心してたりしてなかったり(笑)。
でも、やっぱ「絵」で引っかかるんですよね。あと音。
何かやれればやりたいんですけどねえ。

投稿: cametan | 2009年12月11日 (金) 09時14分

ああそういえば。
こう言うブログがあるんですけど。

poserで結城彩雨:
http://pozayuki.blog109.fc2.com/

3Dってある種エロくないのね(笑)。リアリティはあるんですが(笑)。
poserって何だろ(笑)?

投稿: cametan | 2009年12月11日 (金) 09時17分

ちょっと真面目な話に展開しそうですが。(笑)
scheme使うのはいい手だと思うんです。
特にシナリオエンジンですね。ある意味、アドベンチャーゲームのシナリオってのは簡易言語なので。
どういう選択を行ったから、フラグが設定されて、次の分岐はどちらの台詞が出る、とか、ですね。
ついでに言うなら、選択肢、あるいはフラグによって、反応の重み付けを変えるのもいい。
なので、ある程度、シナリオエンジンとして、言語の要素が必要なのです。

その観点から、schemeとかを(ライブラリとして)シナリオエンジンとして組み込んで、GUI部分は、pythonとか、それらで処理をしてしまう。
pythonは、シナリオエンジンへのフロントエンドとして動作するわけです。
pythonで使うGUIライブラリとQtとかにしてしまえば、Windowsでも動作しますし、汎用アドベンチャーゲームエンジンとして機能するものは作れそうな気がします。
ちなみに、シナリオエンジンの方では、選択の結果を判定して、戻り値を戻すイメージでしょうかね。
シーン番号と、これまでの選択の配列を貰う感じ。
scheme側では、読み込まれているシナリオからシーン番号と選択肢情報を使用して、次に進むべきシナリオ(表示文字列と表示グラフィック番号とかですね。)を返却する。

こうして、得意分野で分業すれば、実装工数は押さえられそうな気がするんですよね。
シナリオその物がschemeの文法に乗っててもいいんじゃないかと思いますし。
#その場合、逆にpython側がschemeから呼ばれるイメージですか。

いずれにせよ、schemeの処理系を知らんので(^^;、そういうライブラリコールが可能かどうかも知らんで書いてますけどね。(笑)

schemeのような構文解析が得意、あるいは配列処理が得意な言語はシナリオエンジンに向いているんですよね。
面白いとは思います。

3Dにエロを感じるかどうかは、まあ、微妙かと思いますね。(笑)
いずれにせよ、2Dの記号化されたエロも、その背景を含めた表情や台詞などのシチェイションがイメージをかきたてるから、エロが成り立つので、デフォルメされた記号ではない3Dグラフィックだと、リアルな分だけ、表情なんかが嘘くさかったり、無表情だったりすると、エロさは出ないんじゃないかと思います。

Poserってのは、ワタクシの知ってるものと同じなら、3Dモデリングデータを使用して、部品単位にアニメーションを作るツールだったと思います。
おもに、人体モデルをターゲットにしているから、Poserだったんじゃないですかね。
購入すると、結構な数のモデルデータが付属するはずで、それをちょっと変形させるようなツールもあったような。
付属データがフリーかどうかは知りませんが、3Dセンスがあるひとなら、テクスチャの工夫と、モデルデータの追加で、案外エロなアニメを作れるかもしれません。(笑)

投稿: かおりん | 2009年12月11日 (金) 10時36分

>ある程度、シナリオエンジンとして、言語の要素が必要なのです。

そうなんでしょうね。
実はこのサイト読んでたんですが。

k-katoh's Page:
http://www.gg.e-mansion.com/~kkatoh/program/novell/novel01.html

もうCでアドヴェンチャーゲーム作るのってしんどそうだな、と(笑)。
自作でインタプリタやコンパイラまでCで設計して……って相当ハードだぞこりゃ、とか思って。

ただ、ああ、シナリオそのものの「構文」決定するの、ってある種大事なんだろうな、とか思いました。
多分シナリオライター的な立場(自分で書く場合も含み)で言うと、あんま押し付けの「プログラミング様式に則った」スタイルで書くより、確かに「フツーに」書けた方が労力少ねえだろな、ってのはなるほどな、と。
それでScheme側なり何なりに「テキストファイルとして」読み込ませて構造体に置換する、ってのは上手いアイディアかも、と。
なるほどねえ、とは思ったんですけどね。

それで、例えばNScripterのゲームの中身とかも調べてたんですよ。
NScripterでのソースってのは実は結構グチャグチャで(笑)。アレはプログラム実行部分とスクリプト部分って分けないんですね。マジでスクリプト内にプログラミングのソース突っ込んでて、gotoで飛ぶと言う感じで。これは結構、BASIC的なんだけど汚いんじゃないの?と。こっちはあまり食指が動きませんでした。

結構ちょこちょこ調べてたんですけど、面白いです(笑)。はあ、なるほど、とか思って(笑)。

>いずれにせよ、schemeの処理系を知らんので(^^;、そういうライブラリコールが可能かどうかも知らんで書いてますけどね。(笑)

Scheme処理系ならPLT Schemeが良いですね。

PLT Scheme:
http://www.plt-scheme.org/

ドキュメントがデカすぎて、調べるの大変なんですけど、一応バイトコードレベルへのソースのコンパイルも可能ですし、Cとのやり取りも上手いみたいです。
色々実験的にはちょこちょこ作ってたんですよ。Wikipediaの「簡単なゲームブックの例」とか参考にしながら(笑)。
動かすくらいだったら60~70行ほどで実装が可能でした。テキストベース「だけ」だったら大した事無かったんです。
連想リストでシナリオ作って、番号で振り分ける簡単なヤツで全然凝ったことしてませんけど。
Python辺りだったらディクショナリ型(ハッシュ)でシナリオ作っても恐らく似たように短く作れるだろうな、とは思うんです。

テキスト「だけ」だったら異様に簡単です(笑)。
だから、やっぱり「シナリオ」が一番難しいですよね。あと、本体とシナリオ部を分けるのなら、シナリオを「どう」フォーマットするのか、が。

>>poser

ああ、そう言うソフトなんですか。なるへそ。

投稿: cametan | 2009年12月11日 (金) 21時21分

まあ、シナリオに関しては、普通にト書きのシナリオで書いて、ルール決めて、sedで置換するなり、awkで置換するなりして、シナリオファイルを出力すればいいんですけどね。
まあ、専用のコンパイラにしてしまってバイナリで吐く方が、ファイルサイズの点で有利なのと、改竄を防げるので、ゲームとしては有効かと思いますが。
#昔を思い出すなぁ。(笑)

この辺、コマンドその物を文字列で定義してしまって(例えば$graphics ####とか)、最終的にschemeのプログラムを吐いてしまえばいいんですよ。
プリプロセッサを作るってことですけどね。
で、scheme処理系に食わせてデータを管理してあげれば、簡単なアドベンチャーゲームが作れます。
セーブポイントとか持たない、ワンパスだけのシンプルなアドベンチャーゲームで、選択肢によって、結果がまるで違うほどの情報量を持ったシナリオが書ければ、これだけで十分に「ゲームとしては」面白いモノになりますけどね。

まあ、それでLinuxの求心力が上がるかどうかは解りませんが。(爆)
作るなら協力できることはあるかもしれませんよ。(笑)

投稿: かおりん | 2009年12月11日 (金) 21時38分

>普通にト書きのシナリオで書いて、ルール決めて、sedで置換するなり、awkで置換するなりして、シナリオファイルを出力すればいいんですけどね。

ああそうか。なるほど。
その辺のツールだとLinuxだと「標準」で入ってるんで、問題無いですしね。
「Windowsだと別途インストール」になるんで、意外と「Linux専用」って意味じゃいいかも。
でも、人によってはsedやawkならPerl使った方が簡単だ、って話になるんだろうなあ(笑)。

>セーブポイントとか持たない、ワンパスだけのシンプルなアドベンチャーゲームで、選択肢によって、結果がまるで違うほどの情報量を持ったシナリオが書ければ、これだけで十分に「ゲームとしては」面白いモノになりますけどね。

そうですね。
結局、アドヴェンチャーゲームの「エンジン」より、シナリオ書くのが一番手間でしょうね(笑)。

前、話したと思うんですけど、Linuxなんかじゃ、例えば「RPGそのもの」よりも「RPGフレームワーク」の方が数多いんですよ(笑)。
つまり、「ゲームとして」キャラ用意するとか、あるいはシナリオ用意するより、ハッカー的な観点だと「フレームワーク」作った方が簡単なんですよね(笑)。
従って、やたら「フレームワークだけ」が増えて行ってしまうと言う(笑)。
これ、Webサイトもある意味そうなんでしょうけど、「Webサイトのコンテンツ」作成するより、プログラマ的な考え方だと「枠組み」提供する方が簡単だ、ってのとある種似ていて。
Webの場合は、需要と供給の関係で上手くハマってるんですが、ゲームだとフレームワーク供給の方が過剰化してんですよね。

>作るなら協力できることはあるかもしれませんよ。(笑)

そうですねえ。
エロゲにこだわらないで、あくまで「試作」で考えるのなら、意外とミステリとかも面白そうなんですけどね。
シナリオだな、一番難しいトコは。

投稿: cametan | 2009年12月11日 (金) 23時09分

ああ、なんか納得できるなぁ。RPGのフレームワークばかりっての。(笑)
アドベンチャーゲームなんかもそうなんですが、やっぱり、「中身が大事」なんですよね。

なかなか、プログラムも書けるけど、シナリオもイケるって人は少ないのかな、ってのと、やっぱり面白いゲームってのは、シナリオが大変なんですよね。
まあ、たぶんフレームワーク作った人たちは、それなりに序盤の中身も書いているんでしょうけど、全体となると、なかなか、ね。(^^;

結構、時間掛かるんですよ。シナリオのデバッグも何度も繰り返しているうちに、慣れてしまって、それが面白いかどうかが麻痺してくる。

まあ、アプリケーションなんかと違って、難しい部分はそこかもしれません。

ミステリも、既製品の真似で作るなら、案外ラクにいけるかも知れませんが、トリック含め、一から考えるとなると、なかなか。
それができるくらいなら、ミステリ大賞に応募します。(爆)

投稿: かおりん | 2009年12月12日 (土) 01時17分

9.10インストール中です(爆)。やっと。

>たぶんフレームワーク作った人たちは、それなりに序盤の中身も書いているんでしょうけど、全体となると、なかなか、ね。

そうそう。
その辺、ゲームとして成り立ってるのが

「Rogue系だけ」

って原因なんですよね。
Rogueだったらシナリオ要りませんから。システム作っちゃえばあとは終わり、みたいな。

>時間掛かるんですよ。シナリオのデバッグも何度も繰り返しているうちに、慣れてしまって、それが面白いかどうかが麻痺してくる。
>まあ、アプリケーションなんかと違って、難しい部分はそこかもしれません。

そうなんですよ。
それでね、「試作」考えた時、どっかにオープンソースっぽく公開されてるゲームブックってねえのかな、とか結構探したんです。
でも無い(笑)。
そもそも、ゲームブック自体が歴史が新しいんで、「著作権切れ」ってのが無いんですよね。まだ誕生してから50年経ってないんで。
その辺、「試作」自体が大変なんです。まずシナリオ無いと「動き」が見れないんですよねえ。
しょーがねえからWikipediaの記事参考にして、ってのがあったんですよ。アレならOpen Licenseなんで。

Wizardryのパロディやりたい、ってのも、まあ、ダンジョン線画はいいとして、グラフィックどうしようか、ってのも考えてたんですけど。
海外のWikipediaとか見てると、モンスター名で検索すると、それなりにOpen Licenseの絵があるわけですよ(笑)。
もちろん、統一されてないんですが、使うのなら、こう言うの流用するのも一つの手だろうな、とかちょっと思っています。ライセンス的に問題がないアーカイヴとして考えるとWikipediaって結構美味しいんですよ。

>ミステリも、既製品の真似で作るなら、案外ラクにいけるかも知れませんが、トリック含め、一から考えるとなると、なかなか。
>それができるくらいなら、ミステリ大賞に応募します。(爆)

そうですよねえ。
まあ、ミステリいい線行かなくても、神宮寺三郎とか、そう言うヤツでもいいんでしょうけどね。
僕は、結構神宮寺シリーズ好きだったんで。

あ、9.10インストール終了しました(笑)。

投稿: cametan | 2009年12月12日 (土) 02時33分

うげえ。
9.10の「日本語セットアップヘルパ」からEmacs消えてるやん。
何やってんだろ、JapaneseTeam。これが簡易だから愛用してんのに。
自分でセッティングするのメンドっちいぞ。
あまりと言えばあまりな改悪(怒)。

投稿: cametan | 2009年12月12日 (土) 02時46分

いやぁ、Emacsそのものが主流じゃなくなったから。(笑)
Emacs使う人なら、自分でセットアップできるでしょ、ってことでは。(爆)
#バグだったり。

投稿: かおりん | 2009年12月12日 (土) 06時42分

>#バグだったり。

あり得ます(爆)。
実はUbuntuインストールしてから後、Emacs23の設定でテンテコ舞いです(笑)。
今んとこ、Canonical公式の「Ubuntuマーク付きサポート対象」になってないから、かもしれません。
ちょっとおかしな挙動してるし、全般的に結構なファイルがEmacs22依存になってるんで、これちょっと弄るの大変そうです。

良くなった点:
・フォントが綺麗
・特に設定必要なく、日本語入力が可能→UTF-8のお陰
・全般的にそこはかとなくカラーが利いていて、今までのEmacsっぽい「モノクロームさ」が払拭されている。

おかしな点:
・サイズ調整が変。
・透明化の挙動がおかしい。

って感じですかね。

でも、全般的に「ブラウザ上で動かしてる」的な感触で、結構良いです。
本格的に使われだすのって、10.04以降かもしれませんね。前回の22もリリースされた後、かなりタイムラグがあったんで。

投稿: cametan | 2009年12月12日 (土) 07時42分

ほほう。
フォントが綺麗はいいですね。
でも、全体にそのせいでレスポンスの軽快さが失われてたりしません?
そもそもGTKなんでしたっけ。
#アレ使いこなせると武器としては強力なんだけどなぁ。

投稿: かおりん | 2009年12月12日 (土) 07時54分

GTKですね。
Motif系使ってたのは21まで、です。22からGTKになってます。
ただ、それでも、例えばブラウザへのコードのペーストとか問題多かったんですが。
その辺、ちょっと触った感触では23は改良されていますね。

投稿: cametan | 2009年12月12日 (土) 10時09分

GTKなら、他のエディタと軽さでは大差ないのか。
んでも、IMEは普通にSCIMとかiBusとか使えるんですよね?
なんで、IM用のモジュールがあるんだろ。

投稿: かおりん | 2009年12月12日 (土) 10時12分

>IMEは普通にSCIMとかiBusとか使えるんですよね?

使えます。
9.10からはiBusでしたっけ?
普通に入力可能ですよ。

投稿: cametan | 2009年12月12日 (土) 10時32分

iBusですね。
SCIMよりは軽量な印象ですが。
#単にSCIMって描画が遅いんじゃないかと最近思ってきた。

となると、結構Emacs23って選択はエディタとして普通にアリだなぁ。
今まで、あの辺のモジュールとか入れないと日本語使えないとかネックだったんで。
ちと真面目に検討。(笑)

投稿: かおりん | 2009年12月12日 (土) 11時30分

I'm still stucked with the fuckin' stupid phenomena on Emacs 23!!!

いやいや、大変。

基本的な部分はいいんですけど、サイズ調整部分に深刻なバグがあるっぽい。
Emacs23は開くといっつも「最大化」しちゃって縮める方法ってのが分からんのです(爆)。
これはいまだ不安定版、って印象ですね。
道理で、Canonicalが「正式に」サポートしてないのか、分かってきました。

>今まで、あの辺のモジュールとか入れないと日本語使えないとかネックだったんで。

前から気になってたんですけど、22だと特にモジュール必要無かった筈なんですけどね?
ひょっとしたら、それこそ「日本語セットアップヘルパ」じゃない方から(つまり、Synapticから)ストレートに入れました?

投稿: cametan | 2009年12月12日 (土) 11時55分

>ひょっとしたら、それこそ「日本語セットアップヘルパ」じゃない方から(つまり、Synapticから)ストレートに入れました?

ええ、ストレートに入れましたとも。orz
#それじゃダメだったんか…。

投稿: かおりん | 2009年12月12日 (土) 12時04分

あああ。それでCtrl+\とか言ってたんですか。
僕は半角/全角でAnthy切り替えてたんで、かおりんさんが「これじゃダメだ」とか言ってるの見て、

「ああ、インライン変換にこだわってるのかな」

とか勘違いしてました。
ごめんなさい。早く気づけば良かったです。

そうなんですよ。Ubuntu Japanese Teamは「日本語セットアップヘルパ」でEmacs用意してくれてたんで、セットアップは「最小限」で済んでた筈、なんです。
そうかそうか。意外と「日本語セットアップヘルパ」に何があったか、なんて覚えてないですからね。
すいません。盲点でした。

投稿: cametan | 2009年12月12日 (土) 12時18分

いや、こちらが迂闊だっただけのことなので。(^^;

もう少し、安定したらEmacs23を使ってみようか、と思いますけど。
まあ、10.04なのかなぁ。

投稿: かおりん | 2009年12月12日 (土) 12時22分

10.04っぽいですね。

今、英語圏の方の情報も漁ってたんですが、「まったく解決策が上がってない」んですよ。
探し方悪いのかもしれませんが。
しょーがないんで、twitterで英語で愚痴っておいて(笑)、誰か情報拾ってくれるかもしれない、と言う非常に消極的な賭けに出ています(爆)。

投稿: cametan | 2009年12月12日 (土) 12時45分

それなら本家に報告した方がいいのでは。

投稿: かおりん | 2009年12月12日 (土) 13時05分

うん。そうかもしれませんねえ。

Ubuntu9.10が出てから一ヶ月経ってるのに、何でこのバグに付いて何も上がってないんだろ?
あるいは、本家は本家でもGNU Emacs大本のバグなのかもしれません。

いやあ、ようやくエラーメッセージが出ないトコまでこぎつけました。
UbuntuのインストールよりEmacsのセッティングの方が時間かかるんだからたまらないですよ(苦笑)。

投稿: cametan | 2009年12月12日 (土) 13時46分

いや、えてしてOSのインストールとかアップグレードなんてそんなもんですよ。
本体のインストールは、数時間で済んでも、そこから先、環境の再構築の方に、下手すれば数日とか掛かりますから。
だから、みんなバックアップを取っておけ、なんて話になるので。

ツールのバージョンが変わって、互換性が怪しいと最悪ですけどね。
結局設定ファイルとか使えなくて、一から手動で再構築になるので。

もしかして、今まさにその状態?(笑)

投稿: かおりん | 2009年12月12日 (土) 14時03分

う~んと。若干複雑なんですよね。

要するに、レポジトリにあるEmacs22と依存関係にあるファイルってのが22入れてないと使い物にならないんですよ。
パッケージマネージャは依存関係に強いのは事実なんですが、こう言う場合困るんですよね(笑)。流用が効かない。
それでしょーがないんで、Emacs22と依存関係にあるパッケージはレポジトリから入れるのを諦めて、殆ど野良ビルドに頼ろうと(笑)。それが大変なんです(笑)。それ経由して「再セットアップ」目論んだわけですから(笑)。

でも、終わってみると、思ったより互換性あるんでホッとしています。手間かかるは互換性危ういわ、じゃシャレになりませんからね(笑)。

投稿: cametan | 2009年12月12日 (土) 14時14分

野良ビルドが入ってるのか。
依存関係あるところの野良ビルドがあると、かなり厳しいでしょう。
その関係があるから、野良ビルドは、完結しているもの以外は避けてるもんなぁ。
#ffmpegなんかもそうだけど。

やっぱり、正式版として23が入るまで待つのが吉かも知れません。
ちと先か。

投稿: かおりん | 2009年12月12日 (土) 16時51分

ああ、まあ、from scratchからじゃ関係無いんですけどね。
僕の場合、Common Lispの開発環境が軒並みダメだったんで顔面蒼白、って感じだったんですよ(笑)。CL使わなきゃ関係無い、ってばないんですけど。
CL関連のEmacsの開発環境がとにかくデカいんで、これを野良ビルド、ってのは・・・って感じだったわけです。

>正式版として23が入るまで待つのが吉かも知れません。
>ちと先か。

うんそうですね。
やっとEmacs23の画面拡大問題関係を語ってるメーリングリストの記事見かけたんですが、やっぱり誰も「本質的な」解決法が分かんないみたいで。.Xresources弄れ、とかアクロバットな話になっていて(笑)。
これだと、23.2辺りになんないと(現行23.1)Ubuntuは正式に対応しないかも。

投稿: cametan | 2009年12月12日 (土) 21時26分

Emacs初心者なんで、安定版が正規にリリースされるまで待ちますよ。
手慣れてればなんてことないんでしょうけどね。

投稿: かおりん | 2009年12月12日 (土) 23時09分

いやいや、結構手こずりました(笑)。「手慣れてれば~」ってのはこの場合、Ubuntuみたいなスマートな環境じゃなくって、Slackware的な環境でのユーザーの話ですよ(笑)。

w3mと言うテキストブラウザ用のインターフェースの「野良ビルド」も手こずりましたもの。
安定版じゃなくってCVS版使う、って事まで突き止めたんですが、configureファイルが無くってconfigure出来ない。初めて、です、auto-confなるもの入れてビルドしたの。
んで、

「ああ~~、auto-confって便利だな~~。」

とか思ったんですが、よくよく考えてみると「野良ビルド」ってのがクソメンド臭いのが前提の上での「便利さ」ですからね(笑)。「感動する」はするんだけど、その「感動」は明後日の方向です(爆)。

こう言う辺り、CLIでの環境って「便利を目標にして進化はしてる」んですが、別の観点から言うとGUIにはかなわないんだな、とかやっぱ思いますね。GUIって別の文脈からコンピュータに現れた「核弾頭」って感じで、亀の歩みのようなCLIの「進歩」を全部吹き飛ばしちゃったのね、って気がします。

投稿: cametan | 2009年12月12日 (土) 23時56分

CVS版とか、正直ないでしょ。(^^;

まあ、どうしても必要なら止むを得ませんが。
正直、もうすっかり軟弱者になってしまったので、ビルドとかですら嫌なのに、CVSとかGitとかSVNとかからソース持ってきて、なんてやりたくないです。(笑)

いや、ご苦労様でした。

投稿: かおりん | 2009年12月13日 (日) 01時08分

>CVS版とか、正直ないでしょ。

とか僕も思ってたんですけどね~~~(笑)。
いや、結構SVNとかは使っています。CVSが嫌なのは、「CVSと言うソフトウェア自体が嫌でインストールしたくない」から(笑)。
一方、割にSVNで「安定版配布」ってのは、Ubuntu/Linux以外だと多いんですよ。
(特にMac OS X生まれのオープンソースに多い、です)

今回、割にCVS絡み(特にEmacs関連で、歴史がそれなりにある開発過程を経てるものは圧倒的にCVS使用)が多かったんで、さすがに凹みましたが(笑)。

投稿: cametan | 2009年12月13日 (日) 01時41分

Ubuntu管理のものだと、結構パッチが入ってるみたいなんで、野良ビルドはいずれにせよ、ってところがありますよね。
カーネル追っかけてたときに、それがあって。(^^;
今もカーネルは自前でビルドですが、それがあるので、ソースはUbuntuのものを落としてきて、パッチもUbuntuのパッチでそのままビルドしてます。
正直やりたくないんですけどねぇ。(^^;

投稿: かおりん | 2009年12月13日 (日) 07時07分

ちょっと借ります。Emacs23の「初期化画面最大化問題」の解決策が分かったんで。
僕のブログに書くより、こっちに書いた方がヒット率高いでしょうしね(笑)。

Emacs23はアンチエイリアスフォントが導入されたお陰で、画面は綺麗にはなったんですが、フォントまわりが大きく変わって、それにまつわるトラブルに発展した模様です。
要するに、.emacsに於けるような「初期化設定」が上手く行えない、と。
そんなわけで、.Xresourceなる別の初期化ファイルを$HOME上に作って凌ぎます。

$ gedit .Xresources

等として空ファイルを起動して、Emacs23で使いたいフォントをここで指定する為に記述します。
例えば、アンチエイリアスフォント、VL Gothic-10を使用したい場合は、

Emacs.Font: VL Gothic-10

のように。
保存して閉じます。
実は、.Xresources自体は、今作ったファイルと別にUbuntu内の「どっか」に存在してて(笑)、設定はそっちが反映されてるんですね。
よって、今新規に作成したファイルとそれを「マージ」せんとならんわけです。
このコマンドが次のコマンドです。

$ xrdb -merge ~/.Xresources

これで$HOME上の.XresourcesとUbuntu本体の.Xresourcesの中身がマージされて、全体結果として反映されます。
これで、取りあえず「Emacs23初期状態最大化バグ」は回避されます。

っつーか、上のコマンドは、色々検索した果てで見つけたコマンドなんですけどね。
こんなxrdbなんてコマンドは「一体いつ使うんだ」ってなもんですよ。これ知ってる人偉いと言うか、良く知ってんな、っつーか・・・。
X回りを「全く触らせない」方針か、あるいはX自体を弄くれるGUIツールが欲しいトコですよね、ホントは。

投稿: cametan | 2009年12月14日 (月) 09時06分

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/500703/46987327

この記事へのトラックバック一覧です: 一方でこんな記事もあるようで。:

« 期待が高まりますなぁ。 | トップページ | MacOSに先越されそうですねぇ。(笑) »