学校に通わずに学ぶログ

私はaptosid(Debian GNU/Linux wheezy/sid)ユーザーだが、ある頃からaptitude updateを実行すると、 # aptitude update このままの状態で固まるようになってしまった。プロセスをkillしなければこのままの状態が延々続いた。このままではパッケージの更新がまったくできない。アンインストールはできるのだが、インストールはどうやらできない。apt-get update; apt-get upgradeのほうは使えるのだが、これまで一貫してaptitudeを使ってきたのでパッケージ管理システムに支障が出るかもしれないし、apt-getでは何かと不親切なことがあるので、aptitudeのほうをどうしても継続して使いたい。 aptitudeを何も引数なしに実行するとコンソール上で動くGUIが起動する。uを押してupdateを行おうとすると次のようなエラーメッセージが表示される。 エラー: 書き込みエラー - write (11: リソースが一時的に利用できません) エラー: Method http has died unexpectedly! debian-usersの投稿記事 によれば、この問題はDebian GNU/Linux lennyにすでに存在し、この記事によればどうやら日本語ロケールとの兼ね合いにあるらしい。したがってこの問題は次のようにしてやれば、やり過ごすことができるらしい。 # LANG=C # aptitude update 根本的な解決策ではないが、この方法で従来どおりaptitudeでのパッケージ管理が再開できた。

データはファイル単位とディレクトリ構造で管理されている Linuxでのファイル管理システムは階層構造を持っている。生物の進化を示す分岐図のような、ちょうど木のような構造図として表されることもあるため、木の構造（ツリー構造）と言い表されている。木の構造のそれぞれの枝はディレクトリと名付けられており、すべてのデータはファイルという単位にまとめられて特定のディレクトリに置かれている。ディレクトリの中にはさらにディレクトリを置くことができるため、ディレクトリは階層的になり、全体としては木の枝のような構造をしている。 木のようなディレクトリの構造の根元（ルート）にあたる部分は、その比喩された意味からしてそのままルート(root)ディレクトリと名付けられている。ルート(root)ディレクトリは、あらゆるディレクトリを包括するディレクトリであり、すべてのディレクトリをその配下に置いている根本的なディレクトリである。そして、ファイル管理システムの最高管理権限はルート(root)権限と名付けられ、ルート権限のパスワードを持っている管理者がその全管理権限を持つとともに、その最高責任を負っている。 データの管理作業は特定のディレクトリ上で行われる Linuxを基本ソフトとして搭載しているコンピュータにおいて、データを管理するファイル操作は特定のディレクトリ上で行われ、そのディレクトリは作業（カレント）ディレクトリと名付けられている。コマンドラインインタプリタを使って、すなわち、コマンド入力によってLinuxに働きかけたりLinux上でファイルを操作するために設計されたアクセス方法を使って、ディレクトリ間を移動するためには、cdというコマンドが一般的に使われている。 Linuxでもっとも標準的に使われているコマンドラインインタプリタ（Linuxではシェルとも呼ばれている）はbashである。bashが起動すると画面上には次のような文字列が一般的に現れる。 aaa@bbb:~$ 「aaa」とある部分にはユーザー名を意味する任意の文字列が表示され、「bbb」とある部分にはホスト名を意味する任意の文字列が表示される。「~」の部分は本来なら「/ディレクトリ名」というように作業ディレクトリ名が表示されるが、「~」とあるのはログイン中のこのユーザー自身のホームディレクトリにいることを示して...

xine のメニューが表示されず、空白になっている。xineの右クリックメニューの日本語が文字化けするか表示されない問題は伝統的なもので、長い間改善されていない模様。 表示されないのは日本語のメニューなので、xtermなどのターミナルエミュレータのコマンドラインで $ LC_ ALL="en_US.utf-8" xine & と入力して起動してやれば、文字化けせずに英語のメニューが表示される。 ネット上でいろいろ調べた結果、もう一つの解決法は、フォント設定及びカスタマイズ用のライブラリである fontconfig を使うこと。fontconfigのパッケージがインストールされていない場合はインストールしておく。 $ su # aptitude install fontconfig 一般ユーザのホームディレクトリに.fonts.confというXML形式の設定ファイルを作成して置いてやる。 <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <!-- ~/.fonts.conf for per-user font configuration --> <fontconfig> <!-- Helveticaフォントよりもunifontフォントのほうを選ぶ --> <alias binding="strong">     <family>Helvetica</family>     <prefer><family>unifont</family></prefer> </alias> </fontconfig> これを.fonts.confというファイル名で自分のホームディレクトリ直下に保存する。 binding="strong"はbinding="same"でもよい。<prefer>は<accept>でもよい。いずれにしても私の環境ではうまくいった。日本語文字の表...

前回の投稿「 bloggerにログインできない！？ 」でbloggerのホームページからのサインインではbloggerに正常にログインできず、「Not Found Error 404」と表示されると書いたが、今回のサインインでは正常にログインできたので、すでに改善された模倣。 その報告ということで。

https://www.blogger.com/からサインインすると、 Not Found Error 404 と表示されてログインできなくなる状態がつづいている。ちなみに、「404」はHTTPプロトコルが用いるステータスコードと呼ばれているもの。 https://www.google.com/accounts/でサイインすると正常にログインできるので、現在はこちらからサインインするようにしている。

opera_11.01.1190_i386.debからopera_11.10.2092_i386.debまたはopera_11.11.2109_i386.debにアップグレードしてから、Operaを起動しようとすると「不正な命令です」というエラーメッセージが表示されて起動不能になった。 $ opera 不正な命令です Operaをパージ(purge)し、ホームディレクトリ内の.operaディレクトリを削除してからインストールし直してみても、この症状はまったく改善しなかった。 # aptitude purge opera （中略） # exit $ cd ~ $ rm -r .opera cd ~ はホームディレクトリへと作業ディレクトリを移動することを意味し、 rm -r .opera は.operaディレクトリごと（その下にあるファイルやディレクトリごと）削除することを意味する。 # dpkg -i opera_11.11.2109_i386.deb 未選択パッケージ opera を選択しています。 (データベースを読み込んでいます ... 現在 33300 個のファイルとディレクトリがインストールされています。) (opera_11.11.2109_i386.deb から) opera を展開しています... dpkg: 依存関係の問題により opera の設定ができません: opera は以下に依存 (depends) します: libgstreamer-plugins-base0.10-0 (>= 0.10.16) ...しかし: パッケージ libgstreamer-plugins-base0.10-0 はまだインストールされていません。 opera は以下に依存 (depends) します: libgstreamer0.10-0 (>= 0.10.15) ...しかし: パッケージ libgstreamer0.10-0 はまだインストールされていません。 opera は以下に依存 (depends) します: gstreamer0.10-plugins-good ...しかし: パッケージ gstreamer0.10-plugins-good はまだインストールされていません。 opera ...

前回、dpkgを使ってインストールしたgoogle-chrome-stableは、aptitudeを使ってアンインストールすることできる。私の場合はsudoを使っていないのでsuを使って一時的にrootになり、google-chrome-stableのdebパッケージをアンインストールすることにした。 アンインストールのためのaptitudeのオプションにはremoveとpurgeがあるが、purgeは設定ファイルまでも削除するので、Googleリポジトリが記載されている/etc/apt/sources.list.d/google-chrome.listファイルまでおそらく削除してしまうだろう。私にとってそれは本意ではなかったので、ここではremoveによってアンインストールした。 $ su # aptitude remove google-chrome-stable これでアンインストールは完了。しかし、インストール時に依存関係のエラーが出て、aptitudeによって追加でインストールしたパッケージ（私の場合はlibxss1）まではアンインストールされなかった。 Googleのリポジトリが記述されているファイルが残っているかを念のために確認した。 $ ls /etc/apt/sources.list.d google-chrome.list 残っていた。このリポジトリファイルまで綺麗さっぱり掃除したければpurgeオプションでアンインストールすればよいと想像するが、ここでは確認しなかった。ただし、purgeオプションでアンインストールしても、各ユーザ用のホームディレクトリに作成される設定ファイル群（~/.config/google-chrome）は、手動で削除しなければならないと思う。 ところで、次のようにしたら、google-chromeのstableバージョン以外にもunstableやbetaバージョンがリポジトリにあることを確認できた。 $ aptitude search google v google-chrome - ...