«前の日(05-09) 最新 次の日(05-11)» 追記

ポケットを空にして。

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|

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

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


2004-05-10 Asiatisch schwarz この日を編集

がっくり。

…仕事増やしてしまった。ダメじゃん…


2005-05-10 この日を編集

アピールのために apt line はそのまま

せっかく設定したのだから使ってもらいたいんですがねぇ。
アピールするなら wiki ページとか forum での発言のほうがよいんじゃないでしょうか。なんか間違ってるかな。


2007-05-10 この日を編集

Debian に関する2005年2月の時点での私の予想。

以前勉強会でやったのを見てみた。

■リリース
 さすがに sarge はリリースされているでしょう。

■セキュリティ対応の面から
 より多くのセキュリティ勧告が発行されているでしょう。下手をすると1000 の大台まで行くかもしれません。これだけ多くの数のセキュリティ勧告の発行には、多大な工数を必要とします。しかしながら、セキュリティチームという人的資源には限りがあり、彼らも会社に対してフルタイムで勤務している社員ではないため、どのようにしてそのリソース不足を補うのかを真剣に考え始める必要があるように思います。この問題は深刻です。 また、このセキュリティ勧告にはチェック漏れが多く発生し、セキュリティアップデートによって「動かない」という事態がより出てくるでしょう。これは利用環境構成の多様化の問題に伴って指数関数的に増える問題です。特に kenrel についてはこの問題が多く付きまとうことになり、それが故にタイムリーに勧告を発行できないジレンマも発生します。この点に関する不満が大きくなるでしょう。

 これに対応するには、セキュリティ問題を事前に防ぐ「監査」がより重要な意味を持つように思います。その際には人的資源の問題から、より多くの自動チェックが必要とされるでしょう。しかし、自動チェックを行うにしてもどのように行っていくのか、実際行うとしたら upstream レベルでの対応を行わなければ意味が無いのではないか、などの問題点が残されています。

 良い点としては sarge のリリースによって、 upstream とのバージョン間の差異が縮まることで security update の backport の手間が多少減ることでしょうか。php の例にもあるように、リリース期間が伸びることによって upstream との乖離が大きくなり、単純な patch で解決できない状況が生まれつつあったので、この点は喜ぶべきことだと思います。

■権利関連
 より多くのライセンス・特許・商標関連問題が山積みになるでしょう。ユーザ側が多少の手間をかけることによって解決できることも多いですが( Unofficial なdeb を利用するなど)、これは一般のユーザにとっては 敷居が高く、「不自由さ」を感じさせることになるでしょう。

それとは逆に、今までライセンスの関係上導入が難しかった部分が一部ながらも解決されていくでしょう。これは特に Java に関して顕著になるかと思います。

■ Debian 固有の l18n/l10n 問題は改善されていくでしょう。
 debconf やpackage description の母国語化の作業はほぼフレームワークが出来つつあり、あとは作業を進めるだけとなっています。問題は翻訳の質をどのようにたかめていくかですが、一般ユーザからのフィードバックをどのように迅速に適用するかが肝かもしれません。

■ Quality の問題をどう解決していくのか
 多数のパッケージの集合体が Debian なわけですが、その質はさまざまです。この品質をどう上げていくのか、単なる packaging issue ではない、本当の意味での QA が求められるようになっていくと思われます。現状では、MIA の追跡から NMU の打診などが debian-qa では行われているようですが、実際に「質を上げる」という意味では機能していないようです。誰がどのようなパッケージを保持しててどんなバグを持っているのか、まではシステマチックに追いかけているようですが、実際にそのバグを潰す方法・もっと能動的に質を高めていく方法がそろそろ問われ始めるのではないでしょうか。

まぁ、あたらずとも遠からず。予想通りだったこと

  • セキュリティ勧告は 1000 を超えた
  • チェック漏れで「動かない」が増えている
  • カーネルはタイムリーに DSA が出ない
  • sarge で backport の手間は減っている。でもまた時間が経ったことで増えてるかも。
  • 不自由さを感じることも多くなっている。codec など
  • Java のライセンスの問題が解決された

2014-05-10 この日を編集

parallel makeの話

openSUSEのWikiではParallel makeという項目で書いてある。

Whenever possible, invocations of make should be done as
 
make %{?_smp_mflags}

…とはいえ、specファイルをいちいち直して回るのは面倒なんじゃないかね。