ゆたりんブログ

昨日(2018年7月29日)の深夜にパソコンをサスペンドにして就寝。 その後、昼前くらいにサスペンドから復帰させて数分間は普通に使えていたんですよ。FirefoxでTwitterのタイムラインは流れるし特に変わった様子もなく。 で、しばらくするとThunderbirdで受信エラーが発生。 ファイルシステムに書き込み権限が無いか、ディスク容量が足りてません、みたいなエラーメッセージのダイアログが表示されてました。この時点ではTunderbirdのアーカイブでも破損したのかと思い、一応このダイアログのスクリーンショットを撮って記録しておこうと思ったらこちらでも保存時にエラー。こちらでも「読み込み専用ファイルシステムです」というようなエラーメッセージが表示されました。 この時点で何かものすごく嫌な予感がしたわけです。1つだけのソフトでエラーが出ても、結局はソフト側の不具合踏んだ程度で終わることがほとんど。それが2つの別々のソフトでファイルシステムに関わる同様のエラーが出たとなると、一気に緊急度が跳ね上がります。ついでに確認のため端末でファイル作成のコマンドを試してみても、ここでもファイルシステムエラー的なのが表示される始末。 「あー、これは詰んだかなぁ…」とやや諦めモードに入りました…。 それでもこのまま放置しておいても、さらに破損が拡大するやも知れないと思い、ここで一旦パソコンを再起動をさせました。 で、再起動させると特に問題なく起動して、ファイルを書き込む操作をしても今度はちゃんと書き込むことが出来ました。ただたまたま起動しただけの可能性もあるので、ハードディスクのSMARTをチェックしたり、起動時にfsckを走らせるようにしたりして出来る範囲で確認作業。 (fsckのログがどこに出てるのか分からなかったけど…) それと起動時のGRUBメニューからリカバリーモードに入ってここでもfsckを走らせました。 もう何年もUbuntuに限らずLinuxを使ってますが、この手のトラブルは初めてでした。なので対応がこんなものでいいのかは自信がないのですが、とりあえず分かる範囲で確認して問題は無さそうだったので一安心です。 ネットで検索してみると、同様のトラブルが起きたという事例がいくつか見つかりました。ただ原因にまで詳しく言及されているものは無か

Ubuntu 18.04 LTSがリリースされたのが今年(2018年)の4月。 その後、順調に進んで18.04.1のポイントリリースが出ました。確か当初の予定だとポイントリリースが出るのは7月の終わり頃だったと思うので、予定通りのリリースになったのかと。ちょっと確認してみたら、Ubuntuのサイトからはもうイメージファイルのダウンロードが出来るようになっていました。 リリースノートもそれに合わせて18.04.1のものが出ています。 BionicBeaver/ReleaseNotes - Ubuntu Wiki ポイントリリースに関する記事 First point release of 18.04 LTS available today - Ubuntu Blog | Ubuntu Blog Ubuntu 18.04.1 LTS Released, Download Links & Details Inside - OMG! Ubuntu! 16.04から18.04へのアップグレードは初めのポイントリリース(つまり18.04.1)が出てからとされていました。いま16.04 LTSを使っていてUbuntuのアップグレード対象を次のLTSと設定している場合は、そろそろアップグレードの案内が来るかと思います。 (さっき試してみましたがまだのようでした) 16.04でもサポート期間はまだ2021年まであるので、特にまだアップグレードする理由が無かったり、準備が整っていない場合はそれほど慌ててアップグレードする必要はないでしょう。 すでに18.04 LTSを使っている場合は、すでに上がっているかアップデートしたら上がると思われます。新しくインストールしたりアップグレードする必要はないはずです。使用しているUbuntuのバージョンを確認するコマンドは $ lsb_release -a です。気になる場合は確認してみて下さい。 以下、あまり関係ない脱線した話。 さて、ポイントリリースはなんぞや？と言われると自分はよく分かってはいないのですが、まぁ一つの区切り？みたいなものでしょうか。OSやソフトがバグ修正やセキュリティ対応などでアップデートされていくと、段々とリリースした当時のものとは変わっていきます。もしOSのイメージファイルがず

まずはPygameをインストールしようと思ったところから ことの起こりはPygameをインストールしようとしたところから。 システムと開発環境を分けるためにvenvで仮想環境を作って、そこにPygameを入れようと以下のページは参考に操作していました。 GettingStarted - pygame wiki そこに書かれていたコマンドは $ python3 -m pip install -U pygame --user これでインストール自体はちゃんと出来ました。がしかし、Pythonのインタープリタから >>> import pygame としてもエラーが出てしまい読み込むことが出来ません。インストール時のpipのオプションに付けた--userが余計だったのか？と思い、このオプションを付けずに再度インストールコマンドを実行。今度は、ちゃんとimportでpygameを読み込めるようになりました。 と、話がここで終わっていればよかったのですが、初めに--userオプションを付けて実行したことが尾を引いて影響してきます…。 何がどうなったのか？ 今回は仮想環境(venv)のPythonにPygameをインストールしました。仮想環境ですから当然このPygameは仮想領域に分離されていてシステム側のPythonからは認識出来ないはずです。が、しかし試しにシステム側のPythonでimportしてみるとPygameを読み込むことが出来てしまいました…。 はてさてこれはどういうことなのだろう？と思い、aptでシステム側にPygameをインストールしていないかを調べましたがそんなことは無し。じゃあシステム側のPythonのpipでインストールしたのではと思ったのですが、システム側にはpipはインストールしていないのでそもそもそんなこともあり得ません。 この時点で考えられることとしては、実は仮想環境でインストールしたのはシステム側からも認識出来ちゃいますというパターン。ですが、それじゃ何のための仮想環境なんだか分かったもんじゃありません。とりあえず、その線はかなり可能性が低いだろうと判断して他の原因を探ることにしました。 まずPygameが一体どこにインストールされているのかlocateコマンドで探してみます。

Pythonを仮想環境で使う場合、いくつか方法があります。それぞれの方法の違いは正直よく分からないので、今回はPythonの公式のドキュメントに載っている方法で試した時の話を書いておきます。 環境はUbuntu 16.04 LTSです。 Pythonドキュメント The Python Tutorial   12. Virtual Environments and Packages — Python 3.7.0 documentation The Python Standard Library   29.3. venv — Creation of virtual environments — Python 3.7.0 documentation まずドキュメントに書かれている方法で仮想環境構築をしようとしましたが、以下のコマンドではパッケージが足りてないというエラーが出ます。 $ python3 -m venv virtual01 ここではpython3-venvというパッケージが足りていないので、aptでインストールします。Ubuntuのリポジトリには「python3-venv」と「python3.5-venv」の2つがありました。違いがよく分からなかったのですが、バージョン的にpython3.5-venvの方をインストールすることにしました。 $ sudo apt install python3.5-venv 必要なパッケージもインストールしたので再び仮想環境構築。　 $ python3 -m venv virtual01 今度は仮想環境構築に成功したので、次に以下のコマンドで仮想環境のPythonを有効にして使うようにしました。 $ source virtual01/bin/activate (shellにbashではなくfishやcshを使っている場合はコマンドがこれとはやや異なります) これによりbashのプロンプト表示が変化します。そして $ python とするといま作った仮想環境のPythonが実行されます。 Ubuntu16.04では「python3」とコマンドを打たないと3系のpythonが実行されませんが、仮想環境下では「python」コマンドだけで作った環境のpythonが実行されます

 さて趣味程度にぽちぽちとPythonでプログラミングをしているのですが、以前から気になっていた疑問が一つ。 Pythonでインストールされていないモジュールを使いたいときに、どんな方法でインストールすればよいか というのを考えていました。 (以下、Ubuntuを使うという前提で話を進めていきます) 代表的なモジュールならUbuntuのリポジトリに用意されているので、aptを使ってインストールすることが出来ます。 そしてPython自体もpipという独自のパッケージ管理システムを持っています。pipを使ったインストールではPyPI(Python Package Index)というリポジトリを参照するようです。 本格的にPythonでプログラミングをする場合は、膨大なパッケージがあるpipを使った方が良さそうです。Ubuntuのaptでインストール出来るものは代表的なものは揃っているのですが、それでもpipよりは限られています。 またaptとpipではインストールのされ方が異なってきます。まずaptではスーパーユーザーでインストールするため、システム領域にインストールされることになります。一方pipではユーザー環境にもインストールすることが出来ます。 それとPythonを仮想環境(venvなど)で動かす場合はpipは欠かせません。環境を分離するための仮想環境なので、必要なパッケージは個別にインストールする必要があり、それにはaptでのインストールは向いていないためです。　 さて、パッケージの数、インストールのされ方、仮想環境での使用について見てきましたが、ではaptとpipのどちらを使うのがいいのでしょうか？特にどちらかというのは気にしないで両方とも使って必要なものをその都度インストールしていく、というのは後々面倒を抱えることになってしまいます。インストールしたパッケージがどちらのパッケージ管理システムをちゃんと把握できていればいいのですが、適当にインストールしているとそのへんがおざなりになりがちです。 一見してpipでインストールした方がいいように思うのですが、aptではUbuntuのリポジトリからインストールされるのでそれはそれで安心感はあります。 個人的にはシステム側のPythonと分けるために仮想環境を構築して、そこでpip

こちらは某所で収穫したレッドカラント(フサスグリ)。 このままでも見た目には甘酸っぱいそうで美味しそうなのですが、実際食べてみると酸っぱさが強くてあまり甘くはありません。あと小さな種がいくつも入っていて食べる時に気になるし、やや渋い。まぁヨーグルトや料理のアクセントに数粒使う程度なら種も気にならないし、このままでも充分使えるでしょう。 さて、今回収穫した量はこれだけ。 量にして約1kgあります。料理のアクセントにちょっとずつ使うだけじゃ全然消費し切れません…。 (しかしパッと見でイクラの山盛りに見えてしまう…) 果物が大量に余ってる時はジャムにして保存するのが定番。なのでこのレッドカラントもジャムにしていきます。インターネットで検索するといくつもレシピが見つかりますし、作り方の動画も多くあるので参考になります。英語で「redcurrant recipe」で検索すると海外での調理方法も見つかります。レッドカラントは元がヨーロッパ原産とのことなので、海外ではジャム以外にもいろいろな調理方法があるようです。 調理 まず実を軸から外しゴミや傷んでいるのは除いてよく洗っておきます。 (上にある写真はすでに洗ってある状態) ジャム作りの話の途中で食欲の無くなる情報になりますが、今回の収穫ではクモやイモムシ、小さいカタツムリが混入していました。収穫量が多いと洗うのも面倒ですが、しっかりやっておきましょう。 次に実を鍋に入れて火にかけます。ジャム作りは果物の酸味の影響を受け難いホーローの鍋を使うといいらしいです。うちにはそんなものは無いので普通の鍋で煮ていきます。 (アルミ鍋は酸に弱いので避けた方がいいようです。他の金属鍋もやや酸で溶けてジャムの仕上がりの色が悪くなるそうです) 煮ているときはこんな感じ。新しい菜箸がピンクに染まりました。洗っても染まったまま…。 さて、ある程度煮てから網で種と皮を濾してやります。 (レシピによっては種も皮も全部ジャムにするものもあります) 実は去年もレッドカラントジャムを作っているのですが、そのときは種も皮も全部濾し取りました。それはそれでジャムが出来たのですが、やはりある程度実が残っていた方が食感が生きてくるでしょう。ということで、今回は濾す量は7割程度にしてある程度実を残すようにし

EmacsのOrg modeでどうにもTODOリストの取得がうまくいってないなぁ、と思って、Emacsの設定ファイル(init.el)を読んでみたら (setq org-agenda-files (list "~/org")) の設定はあるのだけど、その下のcustom-set-variablesの方で個別のファイルを指定するように書かれていた。たぶんそこで設定が上書きされて、初めに書かれた方は無視されていた模様…。 まぁ両方とも自分で設定したわけだけど、init.elはたまに見返してチェックしないとダメですね…。 もう使ってないような設定もいくつか残っているので、必要ないのはバッサリ削ってキレイにしておきたい。

Firefoxはバージョン57(2017年11月14日リリース)からFirefox Quantumと称されるようになり、Firefoxの大きな特徴でもあるアドオンも刷新されました。刷新されたといってもそれ以前から新しいアドオンへの移行が進められていたので、いきなり切り替わったというわけではないです。しかし新しいアドオンの仕組みでは旧来の仕組みを完全にカバーしてはいなく、それもあってか移行されずにそこで更新がストップしたアドオンもいくつもあります。 その中でタブグループ機能を提供していたアドオンも、新しい仕組みでは機能が揃っていなかったためそこでストップしたものが多かったです。一応、Quantumでも使えるタブグループのアドオンも登場していたのですが、動作は旧来のものと同様ではなく擬似的に再現したもののようでした。 いくつか試して使ってみましたが、違うグループに移動すると元のグループで開いていたタブは一度閉じられてしまうようでした。つまり元のグループに戻ってタブで開いていたページを確認しようとしても、そこで一度タブのページの読み込みが発生してしまう。これが頻繁にグループ移動をしようとすると操作的にはかなり煩わしさを感じました。そのため、個人的にはタブグループのアドオンを使うのは止めて、ブックマーク機能などで置き換えて使用するようにしていました。 そしてしばらくが過ぎたところで、Firefox59から実験的にアドオンの機能として tabs .hide() APIが使えるようになりました。 Extensions in Firefox 59 | Mozilla Add-ons Blog これは開いているタブを見かけ上表示しないようにする機能のようで、どうやらこの機能によりタブグループ機能が再び以前と同じように使えるようになるだろう、という話が出ていました。この時はまだ実験的な提供であったため、このAPIを利用するにはFirefoxの設定から機能を有効化する必要がありました。 そしてまたしばらくして、Firefox61でそのAPIが標準で利用出来るようになりました。 Extensions in Firefox 61 | Mozilla Add-ons Blog ただAPIが利用出来るといっても、一般ユーザーとしてはタブグループを実現したアドオンの登場を

自分でもなぜかは分かりませんが、ふとした拍子に「モヘンジョダロ」という地名が頭に思い浮かんだので、せっかくなので少し調べてみることにしました。 モヘンジョダロと言えばインダス文明の遺跡の一つ。 Wikipediaの記事によると紀元前2500年〜紀元前1800年に栄えた都市だそうで、現在ではユネスコ世界遺産にもなっています。 モヘンジョダロ - Wikipedia Google Mapで衛星写真も見れます。こうして見るとなかなか興味深い遺跡ですね。発掘すればまだまだいろいろ出て来そうな印象も受けます。

科学関係の記事を読んでると Pauli bloking という用語が出て来たのですが、検索してもヒットはするけど意味を指し示す解説がなかなか見つかりませんでした。 で、いくつかのサイトを参考にして意味を類推してみました。 分野としては物性物理や材料系の用語で、固体電子系のバンド理論でのある種の効果のことを言うようです。その効果は固体の光励起において照射する光の強度が大きくなると出てくる模様です。 解説すると、 まず価電子帯の電子が光励起され伝導帯に上がり、伝導帯に励起された電子が溜まっていくと空いている電子状態が埋まっていきます。励起される先の電子状態が埋まると、電子はフェルミ粒子なのでパウリの排他原理により入れるところがなく励起出来ません。そのため照射する光の強度を増やしていっても、ある一定以上の強度で励起される電子の量が打ち止めになってしまいます。 と自己流で解釈するとそんな感じになりました。実際には論文とかちゃんと当たって調べるできなので、上に書いた説明で当たっているかどうかは保障しません (:p)