«前の日(12-23) 最新 次の日(12-25)» 追記

ポケットを空にして。

1985|10|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2100|01|

「人の心に残るというのが大事」と言う話。

何か連絡がある場合はメールでどうぞ(過去の日記へのツッコミは基本的にみていません)
プレゼントは随時受け付けております :-) ここ最近のツッコミ/トラックバックリスト。

  1. tsekine (12-26)
  2. Anonymous Coward (12-25)


2004-12-24 この日を編集

po-debconf 翻訳推移状況

ドイツ語  de 1868 (35%) →2574 (44%) →2946 (47%) →3250 (46%) →3712 (47%) →5031 (57%) →5665 (62%)
日本語     ja 1677 (31%) →2007 (34%) →2471 (40%) →2897 (41%) →3256 (41%) →4349 (49%) →4964 (54%)

うーん、同じように増えてはいるんですが、いまだにパーセンテージがこんなもの。前年度比300%なんですがねぇ…。
オランダ(nl) がほぼ射程距離内 (4989 (55%)) なので、抜き去りたい。


2005-12-24 この日を編集

新居昭乃「Happiness is Here」

ということで歌舞伎町まで新居昭乃のliveを見に。

VJ 演出が今までの中でも出色の出来だな。問題は空調があまり効いていなかったのと、番号が悪くて立ちっぱなしだったことか。

明日もごー、である。

らんちゃー

シーエルみたいなアプリケーションないかな。

嘘イクナイ

mycom pcweb の記事だが

「LinuxではLinus Torvalds氏の賛同が得られないためカーネルに採り入れられる予定はない。
FreeBSDやNetBSD、DragonFly BSDではそれぞれスタンスは異なるものの、ユーザランドファイルシステムへの対応は行っている。 」

...って思いっきり間違いやん。この記事が書かれた2週間前に FUSE は 2.6.14 で採り入れられている。
つか、BSD の方を持ち上げたいだけなんかね。指摘コメントはしてみたけど何の反応もないし。
反応/修正してくれる CNet や atmarkit や ITMedia などの方がまだいいな。

新居昭乃「sora no uta(DVD付限定盤) [Limited Edition]」

「『Sora No Uta』ツアー最終日・横浜Blitz(2005年)での公演からセレクトした映像)」ということで DVD がついてきた。

本日のツッコミ(全2件) [ツッコミを入れる]

_ Anonymous Coward [mycom は昔からそんな感じですよ。 中の人が Mac/*BSD 「信者」(ここ強調)な方ばかりですから...]

_ tsekine [んー、mycom がというよりは、書いてる人がね〜。 http://pc8.2ch.net/test/read.cg..]


2013-12-24 この日を編集

全くまとまってない徒然なること。

Debianでのパッケージマネージャといえばdpkgとapt、rpm/yumの方がよい。。。点はあまり思いつかないです。なんだろ?あーdeltarpmはうらやましいですね。差分だけダウンロードしてローカルで当てる、と。しかしまぁ、ローカルのCPUとI/O食うんで遅いマシンだと嫌がられるかな。日本みたいなブロードバンドの国だと普通にダウンロードして展開、のほうが楽だと思うのですが、それは世界でも少数派ですよね。あ、deb packageでも確かdebdeltaってのもあるはずなんですが、どうなのかな。。。

rpmパッケージの作成だとspecファイル一つぱっと書けばいいしすぐわかる。。。という言い方をされる方も多いんですけど、確かにdebパッケージの方がお約束ごとが多いのかも。でも最新のパッケージング(dh7以降)だと「設定よりも規約」な感じで私は好きです。フリーハンドすぎるのはメンテナンスは大変だと思うんですよね。

システムでいうとFedoraのkojiやbohdiはいいですね。特にbohdiのカルマで特定バージョンのgo/nogoを決められるのはいいです。こういうユーザーの小さな参加をもっと増やす方がいいですよね。パッケージメンテナの数は限りがあるし、時間も有限だし。launchpadやFedora Account Systemみたいにアカウントを管理するシステムがあってシステム間で連携とかできたほうがいいのかも。でもまぁ、DebianBTSとかアカウントなしでメールアドレスだけあれば使えるというある意味の手軽さも捨てがたいわけで。bugzillaに報告するためにアカウントとらなきゃいけないのは面倒。

ebuild/ports/Homebrewとか

最近だとOSXでHomebrewが人気のようですね。これがいい点は何なんでしょう。 OSX側で基本的なソフトウェアについては個別のインストーラーで何も考えることなくインストールできて、すべてのソフトウェアでの整合性を考えることなく、欲しいソフトをインストールできる、のがいい点ですかね?基本/usr/local以下に閉じた世界でOSX側の方はいじらないから、さほどシステム崩壊とかはなさそう。Debianでも同様にするのは面白いかもしれない、かな?/usr/localみたいなポイントを作ってそこ以下にユーザーの欲しいソフトをひたすらソースから入れるの。でもbrew使っても同じかな。aptでいれる。。。とchrootになっちゃう?うーん、chrootだと大げさで扱いにくい。。。か。

ソースベースパッケージシステムは、「ユーザーが皆ビルドテストをしてくれている」状態なので、クオリティ維持に役立っている、のかも。でもビルドオプション違うと問題の再現がややこしかったりするかな?マイナーアーキテクチャは皆使わないから、そんなにメリットでもないのかな。あ、ebuildのmaskはいい機能ですね。しかし同様の機能がDebianにあったら、みんながみんなmaskしちゃうとunstableでテストしてもらいたいのにテストされないうちにtestingへパッケージが落ちちゃうということがありえるので悩ましそう。portsは特にこれといううらやましい機能はない、かも(知らない。あったら教えてほしいな)。

いろいろなリポジトリ

バイナリビルドだと、リポジトリ間でのライブラリバージョンの整合性を考えなくてはならなくなったり、そもそも出来が悪いリポジトリを追加すると崩壊するなどの問題がありますね。うーん。とはいえ、でかいものとか複雑なものが時間をかけることなくさっくり入るというのは魅力ではありますよね。LibreOfficeとか。。。pkgsrcで入れるのにむっちゃ時間がかかった、という話を聞いてそりゃそうだよね、と思ったり。

UbuntuでのPPAなどみていても、同様の機能があっていいかな、という気がします。あれはlaunchpadありき(だし、体力的に大変そうなビルドサーバーの準備の関係もあるから)、実装が結構大変そうですが。一つのリポジトリに収束しない点で最終的に整合性を取る点での複雑さが増しますが、一つのリポジトリでいろいろと実験的なことはやりづらいですしね。Debianではexperimentalがその役割。。。なはずだったのですが、unstableに突っ込みづらいバージョンだけとりあえず入れておく、という感じになっていますし(私もそんな感じで使っています。バージョン間が開きすぎると追随するためにパッケージングの手間がものすごくかかることがあるので、ちょこちょことアップデートしていくのがいいんですよね)。特定の目的について、あるソフトウェア群の試験版をすべて入れるのは結構大変ですから、PPAというアイデアはありですね。

メンテナがアップデートしてくれないときに「とりあえずアップデートして共有できる」リポジトリは欲しい。hijackするのはさすがに抵抗があるし、ずっとメンテナンスし続けるほどの気合いはないんだけど、これはいくらなんでも古すぎるやろーとかあったりするので(subversionがそんなかんじでまだ現時点で1.8が入ってない)。メンテナンス対象のパッケージが増えすぎるのはしんどい。とりあえずのアップロード先としてmentorsは微妙に違うような気もするし(あれはパッケージングの練習場所的な意味合いが強い、と思っている)。うーん。

つれづれつれづれ

野望としては、言語のパッケージマネージャーをaptと連動してスムースに動作するのが欲しいなぁ、とか。全部debianパッケージにパッケージングしていくのはタイムラグがあるんですよね。あぁ、そうだ。パッケージをupstream releaseにあわせて更新した際にパッチがあたらなくなってビルドが失敗した場合にパッチ全部外してビルドする機能とかありかなぁ。なしかなぁ。あ。そうそう、aptというかdpkgは地味ーに更新され続けていたりしてるのですが、先日も「xzなファイルを標準にすると余計にメモリとか食うんじゃね?」という質問をした人に「見直ししてメモリ使用量を削減した」って返事を返していて、おー!と思うのと同時にもしかしたらもっと改善とかする余地も残されていたりするのかも、とか思ったり。私はできませんが。

  • mozilla.debian.netみたいにgnome.debian.netとかあればいいのにー最新のを試してみないと、色々と意見もいえないわけで、周回遅れでいつの間にかUIとかが望まぬ方向に行ってたりするし。
  • autopkgtestは身につけないとだめだな
  • buildbotを設定するのがいいのかも。jenkinsさんはパッケージでの横展開がしづらそうである。

特に脈絡も盛り上がりも落ちもなく終わり。どっとはらい。

あ、これはディストリビューション/パッケージマネージャー Advent Calendar2013の 24 日目の記事だったらしい、です。

Xeon E5の上で2.6.32カーネル使ってると電源入れてから208.5日後に再起動でハングするらしいですよ?

Xeon E5の上で2.6.32カーネル使ってると208.5日後の再起動(warm reboot)でハングするというのがある、というのが流れてきた。
何か以前に似たのを聞いたことあるな?という気もしないでもないが、今回のはXeon E5の方でバグがあって、再起動してもTSCがリセットされずにあふれちゃうという感じらしいですよ。あらら。

で、RHEL6.xが影響を受けるのでアップデートが出たそうな。あれ、2.6.32ってSqueezeもじゃん?

と思ってchangelogみる。
…今のパッケージのソース見る。
…svn repoみる。
…修正が入ってないね!(´・ω・`) ショボーン

で、upstreamのgitからパチってBTSしてみました。クリスマスの贈り物だよー つDebian Bug#733043

あ、僕もプレゼント欲しいので誰か贈ってください。