2017年01月14日

HP Pavilion Gaming 15のサスペンド問題

息子のHP Pavilion Gaming 15-ak022TX、その後、快調に使っていると思ったら、ふと気がつくと夜中にファンが回っている。サスペンドしないのかと聞いたら、メニューからサスペンドを選んだらサスペンドできるが、蓋を閉じただけでは自動でサスペンドしてくれないとのこと。これはちょっと困る。そこで調べたら、こちらのページに解決方法があった。要は、

/etc/systemd/logind.conf
HandleLidSwitchDocked=suspend
を加えろということ。
管理者権限でこのファイルを開いて確認すると、コメントアウトしてある文字列の中に、似たようなものがあった。ただ、実際にはドンピシャの文字列はなかったので、改めてこの文字列を記入してやる必要があるようだ。これが正しい方法かどうかは不明だが、とりあえずは蓋を閉じたときにサスペンドするようになったようだ。しばらくこれで使わせてみよう。
posted by 松本 at 23:36| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2016年12月24日

iBusではなかった

なぜだか新しい環境になってから、時折ではあるものの入力メソッドがインディケーターから消えるようになった。そうなると、再ログインしない限り日本語入力が効かなくなってしまう。入力メソッドであるはずのiBusを再起動しようと端末を立ち上げてみるのだが、なぜかiBusの再起動ができない。こまったなあと思っていたら、何のことはない、このシステムでは入力メソッドにiBusを使っていなかっただけだった。
気がつかなかったのだけれど、いつの頃からか、デフォルトの入力メソッドがFcitxに変わっていた。これは、システム設定の言語サポートから、iBusに変更可能。なんのことはない、それだけのことだった。
iBusとFcitxのどちらが優れているのかはわからない。どうやら、私が感心した変換候補の色分けはFcitxのものだったようだ。だが、私のシステム・使用方法では、どうやらiBusのほうが安定しているようだ。こっちで使っていこうと思う。
posted by 松本 at 23:02| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2016年05月30日

Ubuntu 16.04 Xenial Xerusの運用

Ubuntuの各リリースには英語の愛称がつけられている。確か6.06あたりからアルファベット順になり、初期にはそれぞれのリリースを愛称で呼んでいた。FeistyとかGuttsyとか、いまでは懐かしい。けれど、それももうXまできた。私はKoalaあたりからもう覚えるのが面倒になって番号で呼ぶようになってしまったし、Zまでいったらどうするんだろうとか、余分な心配までしてしまう。

ともかくも、この16.04に変えてから、いくつか不便なことがあった。まず、ときどきデスクトップの文字が消えてしまうこと。その後、どうやらその原因は私のローカルな環境にあることがわかった。フォントは、基本的にはシステムの領域のことだからリポジトリからインストールするのが基本なのだが、リポジトリにない追加フォントをダウンロードしてきた際には、homeの個人フォルダ内の隠しフォルダになっている.fontsフォルダ内に放り込んでやる。こうやって集めてきたフォントは、アップグレードしてもそのまま以前のものをコピーして使い続けてきた。思い起こせば、最初にそこにフォントを追加して以来ずっと同じフォルダをコピーし続けてきたわけで、ものによっては10年前に放り込んだファイルも残っている。そのなかのどれかが古びて時代遅れになったのか、あるいはリポジトリから導入したファイルと競合を起こしたのか、エラーの原因になっていたようだ。ということで、このフォルダを少し整理してやるだけで、ここは解決した。なあんだ、という感じ。

もうひとつは、サスペンド復帰後のネットワーク接続がおかしくなること。これもまた、私のローカルな問題であったようだ。というのは、数日前、息子のHPのPavilionの調子がおかしくなり、Ubuntuを再インストールする必要が発生した。このとき、古いファイルを残す必要から、私のAcer V5同様にシステム用のパーティションを新たに切り、元のUbuntu用パーティションのhomeにリンクを張ってそれを新たなhomeにするという作業を行った。すると、それまでに発生していなかった同様のバグが発生するようになったという。ということは、これはやってはいけない、というか、やるとネットワーク接続に影響が出てしまう処理だったらしい。

とはいえ、そういう運用にすることにしてしまった以上、当分はしかたない。これに関しては、ネットワークマネージャの再起動
 sudo systemctl restart network-manager.service
で対処することにした。いちいち端末を開くのも面倒なので、デスクトップ設定ファイルを作成し、そこに上記のコマンドを(ただしsudoをgksuに変更して)仕込んでやることにした。これで、接続がおかしいときにはそれをダブルクリックすれば済むようになった。この運用で、たぶん問題はないだろう。

なお、デスクトップ設定ファイルの作成方法はいろいろあるらしいのだが、面倒なので既存のデスクトップ設定ファイル(WineでWindowsアプリをインストールした際にデスクトップに作成されるショートカット)を複製し、そのプロパティを変更することで対応した。テキストエディタで開いて編集するほうが確実かもしれないが、その場合はテキストエディタを予め開いておいて、そっちから開くようにしないといけないようだ。
posted by 松本 at 13:50| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2015年06月24日

Sculptrisはwineのバージョンに注意

私は使わないのだけれど、中学1年になった息子がSculptrisという3Dモデリングソフトを使っている。先日息子のパソコンのOSをUbuntu 15.04にアップデートした後、改めてインストールしておいて欲しいプログラムの一覧を渡された。ほとんどがリポジトリに入っていてパッケージマネージャからワンクリックでインストールできるものだったし、そうでないものも(たとえばGoogle Chrome)もすぐにインストールできた。ところが、このSculptrisだけがインストールできなかった。
SculptrisにLinux版はない。けれど、WineでWindows版が文句なく動く。それは前回、Ubuntu 14.04のときに簡単にインストールできたことからわかっていた。そこでまず、Wineをインストールし、そしてダウンロードしたインストーラーを走らせてみた。けれど、途中でエラーになる。お手上げ。
はじめは、Wineの設定の問題だろうと思った。そこでPlayOnLinuxをインストールし、いろいろいじってみた。けれど、変化はない。次に、Ubuntuを64bit版にしたのがいけなかったのかとも思った。そこで32bit版のUbuntuを仮想環境にインストールして試してみたが、やっぱりアウト。
そこでようやく、Wineのバージョンではないかと気がついた。PlayOnLinuxでWineのバージョンを1.61に下げてみたら、すんなりとインストールできた。
調べてみると、システムのWineは1.62だった。わずかのバージョンのちがいで、インストールできなかったもののようだ。
ただ、さらに調べたら、14.04のWineも1.62らしいのだけれど…。まあ、解決したので悩まないようにしよう。
posted by 松本 at 14:06| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2015年03月25日

Playon Linuxではまる

今回、起動トラブルに伴って(そして14.10へのアップデートに伴って)環境が一新されたので、アプリケーションの追加インストールを行った。ただ、Ubuntuの場合これは楽なもので、定番のアプリをソフトウェアセンター(というか、私の場合は使い慣れたSynpaticパッケージマネージャ)から選択してOKのボタンを押すだけだ。Ubuntuを使い始めた頃には必要なことが多かった特殊な環境の構成は、いまではまず不要だ。
ただ、Wineでインストールしていたいくつかのアプリが動作しなくなった。これについては、(調整の仕方もあるのだろうけれど)、一からインストールしてやるほうが早いだろう。

以前の経験から、WineへのアプリケーションのインストールはPlayon Linuxを使うほうが簡単かつ確実だということを学んでいた。たとえばMS Office 2010のインストールにはいくつかのMS純正のプログラムを(正規に)追加インストールしなければならないのだが、これをwinetrickから実行するのは結構面倒で、おまけに失敗するケースもままあった(これはもちろんwinetrickのせいではなく、私のミスであるわけだけれど)。Playon Linuxならこのあたりが自動化されていて気楽に進めることができる。以前、驚くほど簡単に進んで拍子抜けしたことがあった。それ以来、必ずwineのフロントエンドであるPlayon Linuxを使うようにしている。

Playon Linuxを使う際には、前もってPlayon Linuxのインストールとともにwineのインストールをパッケージマネージャから実行しておく。Playon Linuxは必要なバージョンのwineを自分でダウンロードして構成してくれるスグレモノなのだが、そのインストールでは依存関係にあるwinbind(だったと思う)がインストールされない。パッケージマネージャ(ソフトウェアセンター)からwineをインストールしておけば依存関係は全て満たされるので、そうしておく必要があるわけだ。

さて、Playon Linuxを起動し、追加インストールのアイコンを押す。通常、ここからインストール可能なソフトの一覧を読み込んで作成するので、通常でも次の操作に移れるようになるまでかなりの時間を要する。ただし、その間でも進行状況を示すパーセント表示が出るので、どの程度待てばいいのかは把握することができる。
ところが、今回Playon Linuxを走らせてみると、いつまでも読み込みを続けて、進行状況が不明なままだ。そして、いつまでもソフトの一覧があらわれない。つまり、インストールに進むことができない。

これはかなり悩んだ。特に、以前は問題なく進行した手順だけに、理解ができなかった。設定ファイルを削除してみたりPlayon Linuxを最新バージョンにアップグレードしてみたりしてみたが、なにをやってもここで止まってしまう。
最終的な解決は、単純なことだった。システム設定の言語サポートから、言語環境を英語に変更してやり、いったんログアウトして再ログイン。これで環境が英語環境になるから、ここからPlayon Linuxを起動。そしてインストールに進むと、難なくソフトの一覧が表示され、そしてもちろん、そこから必要なソフトのインストールが可能になった。手続き後に日本語環境に戻して再ログインしておけば、それで全て完了。

英語の記事では問題なく使えるLinuxアプリケーションが日本語の記事ではたいそう難しいように書いてあることがたまにある。そういう場合はたいていは言語環境の問題だ。日本語で使うためにはそれなりの設定が必要な場合も少なくはないのだが、Playon Linuxのように一過的に使えばそれで十分というような場合には、言語環境を英語に変更して乗り切ることができる。そういえば以前にもこんなことがあったなあと、懐かしく思ったことだった。
posted by 松本 at 10:04| Comment(2) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2015年03月23日

大騒ぎして元通り

ちょうど1週間前、徹夜仕事が終わってホッとしたタイミングで、1年あまり愛用しているAcer V5-131の起動がおかしくなった。はじめのうちは「あれ、どうしたのかな?」程度の不具合で、再起動をやり直したらうまく起動する程度のものだった。前日にアップデートが入りカーネルが新しくなったので、その関係の不具合かとも思った。いろいろインストールしているうちにgrubの自動更新がうまくいかなくなっていたので、ここしばらく手動で更新している。そのあたりで手順を間違えたかなとも思った。
けれど、起動時にgrubで旧カーネルを選択しても、不具合は続く。そのうちに、完全に起動しなくなった。
これはUbuntuの再インストールかな、と思って、念のためにデュアルブートにしてあるWindowsを立ち上げようとしたら、そっちも起動しない。bootイメージを見つけられないようすだ。
このマシンは、導入時になぜかUEFIからのインストールがうまくいかず、BIOSでUEFIとLegacy BIOSを切り替えて、UEFIにWindows、Legacyの方にUbuntuという変則的なデュアルブートにしてある(詳しくはこちら)。だから、UbuntuのカーネルアップデートのミスがWindowsの起動に影響するわけはない、と考えた。
だとしたら、これはハードウェアの問題にちがいあるまい。USBからUbuntuを起動すると問題ないから、ハードディスクの問題だろうと見当をつけた。幸いにもUSBから起動して本体のハードディスクを読みにいったら問題なく読めるから、バックアップはできる。バックアップを取り、新たなハードディスクを購入して、さて、ハードディスクの換装を試みた。
ハードディスクの交換そのものは、特に困難はない。ところが、交換して、まずはWindowsをと思って以前につくってあったリカバリ用のUSBドライブを挿入してみると、なぜだかドライブの初期化はできるけれど、Windowsは復活しない。何かが抜けているようなのだが、よくわからない(実のところ、この問題はいまだに解決できていない)。ただ、過去1年間でWindowsを必要とした機会はごく数えるほどしかなかったので、「それはそれでかまわない」と割りきって、Ubuntuのインストールに進んだ。今回は、なぜだか前回うまくいかなかったUEFIからのインストールがすんなりと実行できた。このあたり、謎は深まるばかり。
ともかくも、Ubuntuがうまくインストールできたので、今度は古いハードディスクを外付けドライブとして接続し、診断してやると、特に不具合はないようす。それならWindowsのリカバリディスクをもう一度作り直せないかと欲が出て、再度ディスクを交換してもとに戻し、とりあえず電源を入れたら、今度はWindowsの自動修復がかかってなぜだかWindows 8.1のログイン画面になった。
理由がわからないのは気持よくないが、ともかくこれでリカバリディスクを作り直し、またもハードディスクを交換して今度こそWindowsを新しいハードディスクに回復しようとしたら、やっぱりできない。結果は同じことになる。そして、Ubuntuにログインしようとしたら、今度は起動ディスクが見つからないとのエラー。どうやら、いっぺん外付けディスクで読み込んだときにUEFIが誤認識するような何かが起こったのではないかと推測。このあたりも実態は不明。
特別にWindowsを使いたいわけではないけれど、もとのハードディスクにも特に不具合はないようだし、だったら元に戻したほうが早いと気がついて、またもハードディスクを交換。交換のたびにWindowsは自動修復をかける。このあたりもやっぱりUEFIの親切、というか、ありがた迷惑な仕様なのだろう。
ただ、このままではUbuntuからの起動ができない。こういうときには、USBディスクからGrubに入ってオプションをつけてハードディスク上のブートイメージを指定してやればハードディスクのUbuntuから起動することができる。昔使ったそういう手段を思い出してしのごうかとも思ったが(いったんハードディスク上のUbuntuから起動すれば、Grubの修復でたいていはうまくいく)、そういえば14.04からアップデートしていなかったので、アップデートを兼ねて14.10のディスクからOSの再インストールを選択してやる。個人データはいじらないから、これでアップデートとGrubの修復の両方がいっぺんにできるという算段だ。

ということで、最終的に大騒ぎの末に、元の木阿弥に落ち着いた。昔はよくこういうトラブルがあったなあと思う。久しぶりだった。



posted by 松本 at 11:52| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2014年05月27日

CUPSのアップデートでプリンタが使えなくなった

今回はじめて起こったわけではないのだが、というか、最近になって何度か起こったようなので気になって書くのだが、ソフトウェアアップデートでCUPSのアップデートがあったあとにプリンタが使えなくなっていた。対処方法は非常にベーシックなもので、設定からプリンタに行っていったんプリンタを削除し、改めてインストールすればOK。このとき接続先の選択を間違えて最初うまく行かなかったが、私のところの環境どおりにUSB接続を選択したら問題なかった。
CUPSはCommon UNIX Printing System、つまりプリントサーバーなので、そのアップデートで一時的な不具合が発生するというのは理解できる。ただ、今回の件は、たまたまその直前のアップデートにCUPSが含まれていたことを覚えていたからあっさり片付いたけれど、覚えていなかったらもうちょっと解決に時間がかかったかもしれない。

Ubunutのアップデートはほとんど自動化されていてアップデートマネージャのダイアログが出たら「はい」とクリックすれば済むようになっている。そこでいきおいいい加減になるのだけれど、やっぱり何が更新され何が新たにインストールされるのかのチェックは怠ってはならないと改めて思い知らされた。それと、できれば履歴が簡単に把握できるSynapticパッケージマネージャを使ったほうが安全かもしれないとも思った。楽ができるようになったとはいえ、やっぱりこれはLinuxなんだから。
posted by 松本 at 19:57| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2014年05月14日

MicrosoftのOfficeがWineで使えなくなった

Ubuntuを使っている以上、基本的にオフィス系のソフトはLibre Officeということになる。これはこれで何の不足もないし、使い慣れてしまえばそれなりに便利なのだが、不便を感じないことが全くないのかというとそうでもない。それは主に一般に普及しているMicrosoftのOfficeとの互換性の問題だ。どうしてもレイアウトは崩れるし、特にOffice 2007以降もうすっかり標準として定着した.docx形式の互換性がよろしくない。ある程度はだいじょうぶなのだけれど、たとえばコメントの再現性とか図形の処理なんかで情報が失われる場合がけっこうあったりして痛い。
まあ、そのあたりも誤魔化し方をある程度は会得してきたわけだけれど、やっぱり本来のMS Officeでどう見えるのか、確認する手段は必要だ。ずいぶん前には仮想環境のXP上の古いオフィスを使ったし、Microsoftが無償配布していたビューワーも利用できた。ただし、このビューワーはずいぶん古いもので、最近のファイルは互換性の問題がある。困ったなあと思っていたら、MS Office 2010の試用版がビューワーとして利用できることがわかった。これはMicrosoft自身が認めていた使用法なのだが、試用版の1ヶ月の使用期限が過ぎたものは、文書の保存、編集などはできないが、閲覧は可能になっている。これをビューワーとして使用できると説明されていた。そして、このMS Officeは、Ubuntu上でWineを利用して走らせることができる。フォントさえ共通させておけばレイアウトもWindows上での表示とほぼ変わらない。これは便利だ。
ということで、ここ数年はUbuntu上でOffice 2010の試用版をビューワーとして使用してきたのだけれど、これができなくなってしまった。

というのは、Office 2013の登場に伴って、MicrosoftがOffice 2010の試用版の配布をやめてしまったからだ。これは当然のことだろう。それならばOffice 2013の試用版を使えばいいかというと、これがWine上では走らない。インストーラーがネットワーク利用になっていることが要因だと思うのだが、インストールさえできない。
これには困ってしまった。もちろん、デュアルブーになっているWindowsの方に入ればOffice 2013を起動することはできるのだが、Ubuntu上で気軽にチェックすることができなくなってしまった。
解決方法としては、Office 2010の正式版を入手できるうちに入手することだろうか。インストールできることはわかっているし、正式版を購入したらどこにインストールしようが遠慮することもないだろう。しかし、普段使うわけでもなく、ただ確認用にたまに起動するだけのソフトにお金をかけるのも悔しい。
とりあえずはOffice Onlineでしのぐのだけれど、これはこれで使い勝手がよくないし、レイアウトの再現性も「本当に大丈夫なの?」と思ってしまう(確認する手段がいまはないのでなんともいえないのだけれど)。こんなことなら、Office 2010の試用版のインストーラーをどこかに保存しておけばよかったとも思うが、やっぱり配布元が配布をやめたようなソフトは使うべきはないだろうし。
posted by 松本 at 00:21| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2013年10月11日

PulseAudioを削除した

小学生の息子に与えたDellのInspiron mini 12なのだが、動画を再生したときに音がひどいのが気になっていた。YouTubeを見たい息子からも苦情がくる。もともとスペックの貧弱なネットブックだし、「Poulsboの呪い」というやつでビデオのドライバが十分ではなく、動画は決してなめらかとは言いがたい。音がひどいのもその関係だろうと思っていた。
ただ、ハードウェア的な故障ではない。たとえばスピーカーのコーンが破れているのなら、イヤホンで聞いたときはまともな音になるはずだ。以前はそれなりに音も出ていたのだから、やはりこれはOSのアップグレードにともなうソフトウェア的なトラブルだろうとは見当をつけた。ならば、どうにかなるのではないか。

サウンド設定の問題、ドライバの問題、カーネルのレイテンシの問題など、いろいろ情報を探してみたのだが、どうもピッタリとくるものがない。諦めかけたところで、PulseAudioによる遅延を指摘しているブログ記事を見つけた。実はこれも疑ってはいたのだけれど、対処方法がわからなかった。ところが、どうやらPulseAudioは削除してしまえばいいらしい。

もちろん不要なプログラムがデフォルトで含まれているわけはないので、PulseAudioを削除することによるマイナスはあるようだ。ただ、少なくともYouTubeの動画をブラウザで再生する分には、PulseAudioを経由しなくても音は出る。ということで、パッケージマネージャを開いてPulseAudioを削除してやった。関連ファイルがいくつか同時に削除されるが気にしない。再起動すると、嬉しいことに以前よりも音がだいぶマシになった。

非力なマシンだからこその対応だが、こんなふうに工夫することで使い物になるのだから、やっぱりUbuntuはありがたい。改めて思った。
posted by 松本 at 08:23| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2012年12月18日

ext3のせい? 12.10アップグレードでディスクのトラブル

先日、仕事先で使っているマシンのOSをUbuntu 12.04から12.10にアップグレードした。ちょっと遅めのタイミングだが、特に困ったことがあったわけでもなかったので、LTSだし、そのまま12.04でいくかとも思っていた。けれど、ほかで使っているマシンで12.10が調子がいいので、「じゃあ、暇なあいだにアップグレードしておこうか」と思って、空き時間にアップグレードした。

ところが、それを使っているうちに、なぜだかファイルの保存ができなかったり、アプリの起動ができなかったりするようになった。ディスクへの書き込み権限がないとか、設定ファイルにアプリが書き込めないとか、どうもディスクのエラーっぽい。思い当たるのは、安物のSDカードで同じようなI/Oエラーがあったこと。アクセスの制限をかけているわけでもないのに、権限がなくなってしまう。これはまずい。再起動すると、うまく稼働するようになる場合もあるが、起動そのものができない場合もある。うまく起動した場合でも、使っているうちにまた同じような症状が発生する。再起動時にディスクエラーの修復を求められる場合もある。反応が必ずしも一定しないのも、ハードウェア的なエラーっぽい気がする。

Ubuntuはうまく起動しないが、デュアルブートのXPなら問題なく起動するので、XP上でディスクの診断ソフトを入れてディスクを検査してみた。肝心のUbuntu領域はスキャンできないが、ディスクそのものに問題はなさそうだ。かなり老齢のディスクでいつトラブルが起こっても不思議ではないけれど、とりあえず重大なエラーは起こっていないらしい。

ということなら、やはり12.10へのアップグレードがトラブルの原因かもしれない。過去にも、アップグレードがうまく行かず、結局再インストールしたケースもあった。あまり使い込んでいないシステムの場合、アップグレードで問題が起こることは経験したことがないのだけれど、使い込んだシステムの場合、やはり新規インストールのほうが無難なようだ。そんなことを考えながら、ライブディスクから起動して、データのバックアップ、パーティションの初期化、そして初期化したパーティションにあらためて12.10をインストールと進んでみた。

ところが、結果は同じ。やはりI/Oエラーが頻発する。これはまずい。いよいよハードディスク交換かと、半ば覚悟をきめた。

けれど、ひょっとして12.10へのアップグレードが災いしたのではないかという疑念はぬぐいきれない。そこで、以前につくって保管してあった12.04のライブCDから12.04を再度インストールしなおしてみることにした。

このとき気がついたのだけれど、トラブルが起こったUbuntuパーティションのフォーマットは、ext3だった。これは、最初にXPのDドライブをLinux用に分割したときに、私がそう設定したのだろう。その後のアップグレードや再インストールでは、そのままそれを引き継いできたことになる。それはそれでOKなはずだ。

というのも、このあたりを見ると、Ubuntuをインストールするパーティションのフォーマットにはext3とext4がともに推奨されているからだ。けれど、ライブCDのデフォルトでは新規インストール用のLinuxパーティションはext4でフォーマットすることになっている。ひょっとしてこれはデフォルトを使うほうが正しいのかもしれないと思って、ext4でフォーマット、インストールを続行した。

その結果、ディスクエラーは起きなくなった。どうやらアップグレードに際してファイルシステムがext3であったことがエラーに関係していたらしい。

けれど、これはどうも理解しがたい。ちょっと検索しただけなので正確なことはいえないのだけれど、12.10をext3のディスクにインストールしてはならないというような情報はどこにも見当たらなかった。だいいち12.04ではこれまで問題なくext3で稼動してきたのだし、12.04と12.10でそれほど大きな変更があったという噂も聞かない。ここで私が「12.10のインストールではファイルシステムはext4にすべきですよ」みたいな根拠のあやふやな情報を流すべきではないだろう。

老齢のハードディスクなので、やはりハードウェア的なトラブルだという可能性は未だに残っている。もうちょっと使い込んでから、この件は再度検討したほうがよさそうだ。
posted by 松本 at 21:30| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2012年06月29日

メモリ増設の効能とデュアルコアの威力

以前、クリップボードマネージャに困っているという記事で、低スペックマシンでGlipperがうまく動かずに困るというようなことを書いた。クリップボードの履歴を管理するユーティリティとして推奨されているClipitがUnity環境ではバグっぽい動作をするので、その代用としてGlipperを使うのがいい。ところが、このGlipper、メモリ1Gのやや低スペックなマシンではしょっちゅう落ちる。しかたないからUnityを諦めてXfce環境でXfceのClipmanを使うことにしたというのが、一連の記事の流れだった。

ソフトウェア的な話としては以上で全てなのだけれど、出先で使っているこの低スペックマシン、他所の機械に細工をするのは申し訳ないのだけれど、勝手にメモリを増設させてもらった。わずか二千数百円、1回飲みに行けば消えてしまうほどの金額で仕事が快適になるのなら、そのぐらいのことはさせてもらいたい。増設の簡単な機種だったので、空きスロットを活用して合計2Gのメモリにアップグレードした。

さて、そうやってメモリに余裕ができてみると、特にXfceでなければならない理由はないような気がしてくる。そこでUnityに戻ってみると、以前よりも動きに余裕がある。そして、Glipperが落ちなくなった。十分に使える。

やはり、メモリを十分に積むことは、現代的なOSを使う上では重要なのだなあと改めて実感した。

もうひとつ感じるのは、やはりデュアルコアは意味があるのだなあということ。というのは、この低スペックマシンはPentiumのシングルコアのプロセッサを積んでいるのだけれど、同じオフィスの隣のマシンには発売時期としては大差ない(したがってスペック的にも大差はない)と思われるCeleronのデュアルコアのプロセッサが積まれている。ところが、同じUbuntuを使ってみると、デュアルコアのマシンのほうが圧倒的に快適だ。システムモニタを見ながら作業していると、その原因がよくわかる。通常のオペレーションではシングルコアでもデュアルコアでも特にちがいは感じないのだけれど、何かの都合で(その現場では特にネットワークの都合であることが多いが)プロセッサの利用が100%で天井にはりついてしまうようなとき、シングルコアのマシンでは処理が著しく遅くなる。ところがデュアルコアでは両方が占有されてしまわないせいか、そういった処理中でも特に不自由を感じることなく別のオペレーションを続けることができる。これは大きい。

Ubuntuは、古いマシンを復活させてくれる。これは正しい。たとえばVistaが搭載されているマシンや長期間使い続けたXPマシンにUbuntuをインストールすると、その軽快さに驚かされる。けれどまた、スペックの低いマシンではそれなりの動作しかしないのも事実だ。やっぱりスペックの高いマシンほど快適なことに変わりはない。デュアルコア、メモリ2Gはやっぱり欲しいよなあと、Ubuntuを使いはじめた頃なら信じられないような贅沢を思うこの頃だ。

posted by 松本 at 09:17| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2012年06月05日

Clipmanを使いたいのだけれど…

昨日、クリップボードマネージャに困っているという記事で、「xfce4-clipmanの説明には「システムトレイがあればXfce Panelでなくても使える」と書いてあるので、なにか工夫すればこれがUnityで走るのかもしれない。」と書いた。その手がかりを求めて公式サイトに行ってみると、「Clipmanにはxfce4-popup-clipmanというコマンドがある」と書いてある。xfce4-clipmanが起動している状態でこのコマンドを叩くと、クリップボードの履歴が表示される。公式サイトにはショートカットキーに仕込んで使うように書いてあるけれど、これをUnityのランチャーに仕込めばXfceのパネルでClipmanを使うのとほぼ同じ使用感覚が得られるだろう。これはやってみる価値がある。

ただ、UnityのランチャーはGnomeパネルやXfceパネルのランチャーとちがって、任意のコマンドを仕込むことができない。そこでまずデスクトップランチャーをつくることにした。これもUnityのUIからはできないので、いったんXfceでログインしてxfce4-popup-clipmanを仕込んだランチャーを作成。次にこのデスクトップランチャーをUnityのランチャーにドラッグして登録。そして最後に、Unityの「自動起動するアプリケーション」にxfce4-clipmanを仕込んだ。ログアウトして再ログインすると、xfce4-popup-clipmanのアイコンをクリックしたときにクリップボードの履歴が表示されるようになる。これはいい。

XfceのパネルのアプレットをこんなふうにしてUnityで使うのに成功した! と喜んだのも束の間、次にxfce4-popup-clipmanのアイコンをクリックしたときには、もう履歴は表示されない。おかしいなと思ってシステムモニタで調べると、xfce4-clipmanが起動していない。これはいけないと再度起動してシステムモニタで見ると、一応動いている。そして履歴も表示される。けれど、しばらく使うとまた使えなくなる。システムモニタで見ると、またも落ちている。

原因は不明だけれど、どういうわけかxfce4-clipmanはUnity環境に常駐してくれない。常駐させる方法がわからない。これはUnity 2Dでも同じだ。

ということで、残念ながらClipmanは使えない。幸い、スペックがまともなメインマシンではGlipperの調子がいいので、これを使い続けることにしよう。そして、出先で使う低スペックマシンは、Xfce環境で使うことにしよう。せっかくの最新のデスクトップ環境が利用できないのは悔しいけれど、調べてみたらUnityよりもXfceの方が素のままの状態で2割ほどメモリの消費量が少ない。低スペック環境ではこれは大きいから、そういう意味でもXfceでClipmanというのがよさそうだ。
posted by 松本 at 20:59| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2012年06月04日

クリップボードマネージャに困っている

テキストをコピー(またはカット)したとき、その文字列情報はクリップボードに保管される。このクリップボードの履歴を管理するソフトはむかしからあって、私の場合は90年代にMacを使っていたときに出会ったのが初めてだった。これはなかなか便利なので、Linuxでもないかと思っていたらちゃんとある。最初に何を使っていたのかはもう覚えていないが、3年前からはxfce4-clipmanを愛用してきた。これはXfceのパネルに表示されるクリップボードマネージャで、シンプルで扱いやすい。これが手に馴染むと、もう手放せなくなる。履歴を呼び出すだけでなく、コピーしたテキストの属性(フォントやスタイルの指定)をクリアする用途やテンポラリーなバックアップにも活用してきた。たとえばブログを書いている途中でCtrl+A、Ctrl+Cと続けて押すと、それまで書いたテキストがクリップボードに保管される。これを頻繁に行えば、書きかけでうっかりブラウザを閉じてしまうような事故を起こしても、コンテンツが失われることはない。

手に馴染めば馴染むほど手放せなくなるのがこのクリップボードマネージャなのだけれど、Unity環境ではxfce4-clipmanは使えない。むかしPerceliteというのをごく短期間使ったことがあったけれど、この系統のフォークでClipitというのがUnityに使えるというので、それをインストールして使ってきた。だが、少し不満がある。

というのは、ときどきコピーした文字列が「空のラベル」としか表示されない。それだけでなく、表示がおかしくなって、表示されている文字列と実際にクリップボードにある文字列がズレてくることがある。これでは使いにくいので、なにか代用になるものがないかと思っていた。同じようなことは誰も思うようで、Glipperを勧めるスレッドがあったので、早速Clipitをアンインストールして、こちらを入れてみた。

使ってみると、確かにClipitで感じた不都合は生じない。感覚的にはxfce4-clipmanと同じように使える。よし、これで一件落着かと思ったら、それは比較的スペックがマシなパソコン上でのことで、少し古くてスペックの低いパソコンを使っていると、これがしょっちゅう原因不明に落ちる。どうもメモリが足りないと、何かがわるさをするようだ。これでは困る。

ということで、正直言って現在、クリップボードマネージャには困っている。Clipitのバグも、どうもClipit自身のものというよりはUnityとの相性問題らしいので厄介だ。というのは、このClipit、Xfce環境でも作動するのだけれど、Xfce環境ならちゃんとラベルが表示される。皮肉なものでXfce環境なら使いやすいxfce4-clipmanがあるのでClipitは不要になる。Unityできちんと動くものが欲しいのに、低スペックマシンではそれが手に入らない。

xfce4-clipmanの説明には「システムトレイがあればXfce Panelでなくても使える」と書いてあるので、なにか工夫すればこれがUnityで走るのかもしれない。それがわかるまで、しばらく悩める日が続きそうだ。

posted by 松本 at 22:35| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2012年06月02日

やっぱりWubiは遅い?

前回のエントリ(そういえばUnityはCompizだった)で、古いXPマシンにWubiでインストールしたUbuntuがどうにも遅いという話を書いた。どうも3Dアクセラレーションが効いていないようなのでXfceで使ってみようと思っていたのだけれど、処理速度だけではない問題も出てきた。具体的にはいくつかのパッケージがインストールできない。Google Chromeやプリンタドラバが依存関係ではねられる。エラーメッセージを見る限り依存関係はクリアしているはずなのに、「キャッシュが壊れています」みたいなエラーで進まない。再インストールとかやってみても同じ。

そうこうするうちに、Wubiの仮想ハードディスクの容量が足りなくなってきた。これは最初にインストールしたときの見通しが甘かったわけでいってみれば自分のせいなのだけれど、どうにか対処しなければならない。調べるといくつかの方法があるようだが、確実な方法でやるならインストールCDが必要になるようだ。そこまでやるんだったら実機にインストールしてしまえと、ハードディスクを整理して空きスペースをつくり、インストールした。

すると、驚いたことにUnityがちゃんと動く。XPと比べても遜色ない軽快さだから、モダンなOSとしてこれは素晴らしいのではないだろうか。そして問題だったChromeやプリンタドライバのインストールもうまくいく。結局、マシンの問題ではなく、Wubiの問題だったようだ。

以前にも何度かWubiは使ったことがあるけれど、実機とそれほどの差が出た経験はなかった。機械の相性なのかバージョンの問題なのか、こういうことがあるんだなあと、改めて実感したことだった。
posted by 松本 at 19:55| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2012年05月31日

そういえばUnityはCompizだった

先日、Windows XPのパスワード回復というエントリで、「久々のレガシーなマシンで、遅いことこのうえない」と書いた。仮に使うだけのつもりではあるのだけれど、やっぱりある程度は環境を整備したいので、いくつかのアプリケーションをインストールした。ところが、これがほとんどフリーズしたのではないかというぐらいに処理が遅い。ひとつひとつのアプリケーションの動作はそうでもないのだけれど、複数のアプリケーションを立ち上げようとしたり、アプリケーション間の切り替えをしようとすると、どうしようもない鈍い動作になる。

「やっぱりメモリ1ギガではいまどきのOSは難しいのかな」とか、「グラボのドライバが動いていないんじゃないか」とか考えた。ノート型だけれど一応グラボにはATIのものを積んでいるらしい。プロプラのドライバでもあるかと思って「追加のドライバ」を起動したけれど空振りする。ドライバのせいではないようだ。となると、メモリを追加するしかないかとメモりの規格を調べ始めたりもしたが、よそのパソコンに勝手にメモリを増設するのもなあと、思いとどまった。

しかたないので、以前ロースペックのマシンのときにずっと使っていたOpenBox環境にデスクトップを変更しようと思った。私が愛用していたのはOpenBoxにXfceのパネルを併用した変則DEなので、この2つを入れた。そしてまずはXfceでログインすると、なんとも驚くほどの速さでサクサクと処理が進む。これはOpenBoxまでいく必要はないかもしれない。

「さすが軽量デスクトップ環境」と思ったけれど、よく考えたらそれだけのことではない。XfceがUnityに比較して圧倒的に軽量というわけではない、と気がついた。

どういうことかというと、UnityはもともとCompizの上で動くもので、CompizはOpenGLの3D機能がないとうまく動かない。そのあたりが古いATIのグラボでどうなっているのかしらないが、どうやら3DアクセラレーションがないからCompizがもたつき、結果としてUnityがフリーズしたようになる、というだけのようだ。だからこの差が出たに過ぎないのだろう。

となると、実はXfceではなくUnity 2Dを使えばよかったということなのかもしれない。まあ、久々にXfceも悪くないので、飽きるまでこれでつかってみようか。
posted by 松本 at 20:37| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2012年05月21日

SDカードが読めなくてハマる

最近のパソコンにはSDカードスロットがほとんど標準装備なのだけれど、このAsus UL20AにもSDカード用のスロットがついている。Ubuntuは、もう最近ではたいていのマシンのハードウェアを問題なく認識するが、このノートパソコンでもSDカードスロットはごくあたりまえに読み書きができる。それがふつうとなんの疑問も持たなかったのだけれど、思い起こせばUbuntuを使いはじめた頃はハードウェアの認識にけっこう苦労したものだ。そんな頃を思い出させる出来事があった。

古いSDカードがあってデジカメのデータを入れていたのだけれど、これは以前のバージョンのUbuntuを入れたこのUL20Aで特に問題なく読めていた。SDカードスロットに入れればなにも考えずにマウントできたわけだ。ところが、このSDカードが12.04にアップグレード後に読めなくなった。マウントしてくれない。これはハードウェアの認識に失敗しているのだとおもった。

こういうときはどうやればいいのだろう。昔はこういうケースにいろいろ苦心して解決したような気がするのだけれど、最近はすっかりUbuntu任せで苦労をしないから、どうやっていいのか手も足も出ない。これが12.04に特有の問題、あるいはUL20Aに特有の問題なら誰かがどこかで何か言っているだろうと思って検索するのだけれど、なにも出てこない。

そこで、ボリュームのマウントに関係しそうなプログラムを片っ端からインストールして試してみた。まずはMount Manager、次にStorage Device Manager、さらにKDE系統のKVPMと、いろいろ入れてみたけれど、そもそも認識していないのだからマウントできない。いろいろやっているうちに、灯台下暗し、使い慣れたパーティションエディタのGpartedでデバイスは認識することがわかったし、ディスクのフォーマットを始めとする操作もできることがわかった。けれど、マウントができない。

ひょっとしたらディスクが壊れているのかと思ってWindowsでこのSDカードを読んでやると、きちんとマウントする。デジカメでの使用も問題ない。これは深刻なバグなのかなあと思って、それでも念のためと思って別のSDカードを挿入すると、あっさりとマウントした。狐につままれた気分。

結局、どうもSDカードの相性問題だったらしい。このSDカードも外付けのカードリーダー経由なら読めるので、実用上はなんの問題もない。ちなみにこの外付けのカードリーダーは百均で売っていたもの。なんだかなあという感じの顛末だ。
posted by 松本 at 21:48| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2011年11月08日

Ubuntu11.10の言語設定でハマる

今回のアップグレードにはなんとなくついていけなくてまだメインマシンは11.04のままなのだけれど、別マシンのWindows環境上に仮想Ubuntu環境を設定することになって、そこは素直に最新版の11.10を選んだ。ということでようやく11.10に触れることになった。今回は(前回からそうだったかもしれないが)、Synapticパッケージマネージャがデフォルトからなくなっていて、プログラム管理はソフトウェアセンターに一本化されている。これはこれでいいのだけれど、Mozcをインストールしようとしたらソフトウェアセンターから見つけられなかった。振り返ってみたら検索のしかたが間違っていただけのようなのだけれど、そこはあまり考えず、手慣れたSynapticをインストールした。こういうことをしていると、だんだん一般ユーザーの感覚から離れてしまうと自戒。

さて、インストールをバックグラウンドで処理しながらほかの作業をしていたら、英語環境で立ち上がってしまった。言語設定がインストール時に選べたように思うのだけれど、どうもそこをパスしてしまったらしい。とはいえ、日本語環境に設定するのは何の難しいこともない。と、環境設定(11.04からシャットダウンメニューのところにある)を開いて、language settingをクリック。ここで言語の追加で日本語を追加するところまではうまくいった。ところが、そこから先、どうにも日本語を選択できない。ちょっと焦った。

なんのことはない。説明をよく読んでいなかっただけだった。「日本語」と書かれたバーを「English」と書いてあるバーの上にドラッグしていけばOKだった。そして、Appplyを押せばいい。それだけのことがわからず、一時は「英語環境で行くか」などと思っていたのだから実にいい加減なものだ。

UIの説明はよく読みましょうという教訓だった。
posted by 松本 at 05:54| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2011年10月05日

仮想環境XPでPDF Creator

あるWebサービスでPDF形式の文書を出力してくれるところがあるのだけれど、これがUbuntuでは文字化ける。いまどきPDFで文字化けを起こすのは珍しいのだけれど、どうやらこれはサービスの仕様らしい。

というのは、このPDFをWindows環境に持って行ってAdobe Readerで開くとちゃんと文字が表示されるのに、Windows環境のInkscapeで開くと文字を認識しないからだ。おそらく、サービスが使いまわされることを避けるためにこういうことをしているのだと思うけれど、ユーザーから見れば余計なお世話ということになる。

で、Ubuntu環境で読めるようにする方法を考えた。要は文字をアウトライン化するかビットマップ化すればいい。そこで、PDF CreatorをWindows環境でインストールし、Adobe Readerから改めてPDFを作成した。この際、オプションの奥のほうにあるポストスクリプト設定で、アウトライン化もしくはビットマップかが選択できるので、ここをチェック。こうやって出力したPDFをUbuntu環境に戻すと、無事にUbuntuで読めるPDFが得られた。

こういう手間をかけるぐらいなら、Webサービスなんか使わずにローカルで文書を作ったほうがよかったのかもしれないとも思う。とりあえず備忘録として。
posted by 松本 at 15:41| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2011年07月01日

OpenOffice(LibreOffice)の改行コード問題、とりあえず回避

スマートな方法ではないのだけれど、一昨日、OpenOffice(LibreOffice)とテキストエディタの改行コードで書いた問題をとりあえず回避する方法を書いておこうと思う。単純な話で、OpenOfficeでもテキストエディタでもないアプリケーションを経由してコピー&ペーストするだけ。

たとえば、ホームページビルダー式ののHTMLエディタとしてSeaMonkeyのComposerがあるが、ここにテキストファイルを貼りつけると、改行コードは<br />もしくは<p></p>として反映される。これを改めてコピーしてOpenOfficeに貼りつければ、改行マークはそれぞれ正しくLFもしくはCR+LFとして認識されるから、以後、保存時におかしな変換が行われて「行が増える」問題は発生しない。

これはたぶん、SeaMonkeyではない他のアプリケーションを経由しても同じ結果が得られるのではないかと思う。たとえばブログエディタのようなものでもいいと思う。なんならテキストエディタで\rや\nを<br />に一括変換しておいてそれをHTMLとしてブラウザに読み込ませておいてからコピー&ペーストしてもだいじょうぶだと思う。ただ、手間がかかるので、それよりは他のアプリケーションを経由するほうが簡単だろうと思う。

こんな変なことをしなくてもOpenOffice(LibreOffice)の方で.doc保存時に変なことにならなければいちばんなのだけれど。とりあえずは、ベタな回避策で運用するとしよう。
posted by 松本 at 20:12| Comment(6) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする

2011年06月29日

OpenOffice(LibreOffice)とテキストエディタの改行コード

以前から、OpenOffice、最近ではLibreOfficeを使っていて困ることがひとつある。それは、テキストエディタで処理した文字列をOpenOfficeのワープロWriterにコピー&ペーストして.doc形式で保存したあと、再度開くと、改行が増えてしまうことだ。具体的には、1つの改行マークが2つになる。だから、各段落の間に1行の空白ができてしまうことになる。これはちょっと都合が悪い。OpenOffice上で作成したテキストなら、こういうことは起こらない。なぜよそから持ってきたテキストでこういうことが起きるのか、不思議で仕方なかった。これを防止する方法も思いつかず、どうしてもまずい場合には、改めてOpenOffice上でいちいち手作業でいったん改行を削除し、再び改行してやるという面倒なことをしていた。これは面倒で、ときにはやっていられないと思うこともある。

OpenOffice上で改行マークの一括置換でもできればこういう問題は起こらないのだけれど、OpenOfficeはこういう特殊コードを検索対象にしてくれない。一方、テキストエディタでは、たいていは改行やタブストップなどの特殊コードも検索・置換の対象になる。だから、たとえば本来1つのはずの改行が2つになってしまったとしたら、それをテキストエディタに持っていった上で、2つの改行マークを検索対象にして1つの改行マークに一括置換してやれば、修正する処理はできる。けれど、この修正済みのテキストをコピー&ペーストでOpenOfficeに持っていったら、また同じことが起こるだけ。どうにもうまくいかない。

それでもこういう絡みの試行錯誤を続けていると、少しだけ見えてきたことがあった。それは、実際の改行コードと、テキストエディタ上で扱う改行コードが微妙にちがうということだ。

詳細はWikipediaのこちらに書いてあるのだけれど、テキストエディタ(少なくともgedit)上の検索置換では、改行マークは\n、\rもしくは\r\nで入力することができる。いずれでも改行になるのだけれど、これは概ねCR、LF、CR+LFに相当する。ただし、これは「概ね」であって、Wikipediaに「しかし一般的な認識に反して、これらのエスケープシーケンスは一般的にはLFやCRと等価ではない」と明記されている。どうやらこのことが、改行コードが増えてしまう原因のような気がしてきた。

詳しいメカニズムはわからないけれど、ペースト時と保存時にそれぞれ\n、\rからCR+LFへの書き換えが行われているのではないだろうか。そしてそれが重複してしまう。だから改行コードが倍増するのではないだろうか。ちなみに、\n、\r、\r\nのいずれに置換しても結果は同じなので、ここは一律の変換が行われているのだろう。このあたりにもヒントがありそうだ。

試しに、\nや\rに置換するのではなく、<br />と、HTMLの改行に置換してやり、これをHTMLとして読み込むと、改行マークの倍増は起こらなかった。このあたりにも別なヒントがありそうな気がする。

ちょっと厄介な問題だけれど、こんなふうに解決の糸口が見えてきたのには希望が持てる。うん、希望は失わずにいたいものだ、何事にせよ。

posted by 松本 at 05:35| Comment(0) | TrackBack(0) | Ubuntuでの失敗・トラブル | このブログの読者になる | 更新情報をチェックする