SELinux 有効時の Samba 設定


久しぶりに Samba をインストールしてLinux-Windows間ファイル共有をしようとしたら、ユーザーホームが表示されるものの中にアクセスできないという症状に遭遇しました。

横着して? SElinux をそのまま有効状態にしていたのが原因でしたが、
せっかくなので無効化せずに、見えるように設定してみました。

root 権限で以下のコマンドを実行します。


VisualStudio 2015 で Linux アプリの開発&デバッグ


VisualStudio 2015 で別PCで動いている Linux 環境でのアプリ開発およびデバッグということができるかを試してみました。

必要なものは以下の通りです。

  • Linux環境の別ターゲット
  • VisualStudio 2015 を ”Visual C++ Android 開発”付きでインストール

ここでは VisualStudio 2015 Professional, Windows10 Pro (x64) で確認しています。
vs2015-target-linux-11

セットアップ

最低限の必要なものは準備が終わっているものとして、環境構築の説明をしていきます。

Linux側の準備

ここでは少し古いですが CentOS 6.5 の環境があったのでこれで説明します。
Samba を用いて Linux-Windows のファイル共有ができるように設定しておきます。
またコードのコンパイルを Linux で行うために、コンパイラなどのツールチェインをインストールしておきます。

Windows側の準備

Visual Studio GDB Debugger 」という拡張プラグインをインストールします。
これは以下のページからダウンロードすることができます。
https://visualstudiogallery.msdn.microsoft.com/35dbae07-8c1a-4f9d-94b7-bac16cad9c01
VisualStudioGDB.vsix というファイルがダウンロードされるので、ダブルクリックでインストールを行います。
(本プラグインは Microsoft のデジタル署名がついているようでした)

このプラグインが Plink を使うようなので、Putty のページからファイルを取得してきます。
Putty のページ: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

インストールしてしまっても良さそうですが、開発環境に tortoise Git も入っており、こちらが標準で使っている TortoisePlink でないものを設定済みだったりするとかち合うため、安全を考えて zip アーカイブを取得することにします。

そして、これを適当なところに展開します。ここでは C:\tools\putty に展開しました

続きを読む


Windows10 で EP-802A


Windows10 に更新したら普段使いの EP-802A プリンタの問題に出遭いました。
ドライバ等を更新してみても、印刷はできるもののインク残量が見えないという症状で苦戦させられました。これらはネットワーク使用でつかっています。
SymantecやWindows Firewall などの無効化を試してみても問題は解決しませんでした。

機種としてはずいぶん前のものなので正しく Windows10 対応できていなくても仕方なく、これは買い換えも覚悟していたのですが、なんとか対処することができたので一安心です。

検索してみると同じように悩んでいる人もいそうだったので、自分の解決法を公開しておきたいと思います。

やったこと

ドライバをメーカーのページからダウンロードしてインストール

  • プリンタドライバ
  • スキャナドライバ
  • EPSON プリンターウィンドウ3 (ネットワークモジュール)

これらを最新版で試したのですが、前述の通りインク残量が確認できませんでした。
ファイアウォールの設定を無効化してみても改善しなかったのであきらめかけていました。

このとき、プリンタの接続ポートの情報が、 WSDポート に接続されたものでした。
EPSON のネットワークプリンタ設定だと、 EpsonNet Print Port に設定されるという情報を元に、こちらを使うように変更を試みたところうまくいきました。

そのようにする手順は簡単で、メーカーのドライバ類のダウンロードのページで、
「EpsonNet Print」という別の印刷ユーティリティソフトをダウンロードしてインストールを行います。

これをインストールした後で、プリンタのプロパティでポートの追加を選んで、
この EpsonNet Print を選択して切り替えてあげれば、無事にインク残量を確認できるようになりました。

まとめ

最近の EP シリーズは小型になったようですし、ぼちぼちと買い直ししたほうが、トラブル少なくて済むのかなと思いました。
意外と同症状で困っている人が多いみたいなので、この記事で解決できるようでしたら幸いです。


Ubuntu で DirectFB が試せないかテストしてみました。


DirectFB なるものの存在を今更知ったので動くか確認してみました。(ほんとに今更・・・)

必要なもののインストール

設定

.directfbrc という設定ファイルに以下の内容を記述します. こうしないとエラーが起こってしまいました。
こうしておくと X11 の上で動作させることが出来ました。

サンプルコード

StackOverflow かどこかで公開されていたコードを試してみました。 続きを読む



Git LFS を使ってみる


Git はソースコードの管理ツールのため、巨大なバイナリファイルの扱いが苦手でした。これに対応すべく開発されたのが LFS: Large file storage という機能です。
今回はこれをインストール&触ってみたいと思います。なお環境はすでに git for windows がインストールされた環境で行っています。

ちなみにこの記事の内容は Git for windows 2.7.2, git-lfs 1.1.1 を用いての内容となってます。バージョンが異なる場合、以下の内容とは変更になっている可能性があるのでご注意ください。

GIT LFSについて

扱いとしては git のエクステンションという形になってます。
提供する機能は、指定されたファイルタイプの場合に特殊な処理を行うようになります。
この処理というのが、バイナリファイルを指し示すリンクをソースコードの場合と同じように保持するようにして、バイナリファイル自体はそのリポジトリとは別の場所に管理させる、というようなものです。

このLFSですが、前身になるようなものとして、git-media, git-fat などがありました。これらを使用していた人は同じようなものだと考えてもらってよいと思います。
LFSのメリットはすでにGitHub や、ほかのホスティングサービスも対応を始めているため、バイナリファイルの扱いに対して準標準を得られるのでは、というところもあるかと思います。

git lfs のインストール

https://git-lfs.github.com/ からインストーラーをダウンロードします。
この記事を書いているときには、 git-lfs-windows-1.1.1.exe でした。
このインストーラーをダブルクリックで起動してインストールを行っていきます。

インストールする場所ですが、 Git for windows をインストールしたフォルダで、
mingw64/bin 以下になるようにします。以下の図では標準の場所を指していますが、Git for Windows を別の場所にインストールしている場合ではここを修正する必要があります。
(現時点ではすでにインストールされているgit のインストールパスは探索されない模様)

インストールが終わって Git Bash を開き、以下のコマンドを実行します。

このように表示されればOKです。 git lfs init というコマンドもあったようですが、廃止扱いになっており、今は git lfs install が正しいようです。

動作を確認してみる

まずは適当な git リポジトリを用意して、動作を確認していきたいと思います。

Git lfs では LFS として管理させるファイルタイプを選択、設定します。
ここでは、よく使う画像ファイルを登録したいと思います。
この登録は以下のようなコマンドによって行います。

これらの情報は .gitattributes に格納されます。上記の実行結果で以下のようになっていました。

この .gitattributes ファイルを開かずとも、 git lfs track コマンドで確認することもできます。

さて登録したタイプにあうような適当なファイルをコミットしてみます。
ここでは png のファイルを追加・コミットしてみます。
以下のように行いましたが、これは通常の git のファイル追加・コミットと変わらないです。

これが LFS の管理になっているかどうかを確認するのに以下のコマンドを実行します。

正常に機能していれば上記のように、ファイル名とその何らかのハッシュ値が表示されます。

リモートリポジトリとのアクセス

ローカルでの機能確認ができたら、リモートとのアクセスを試してみたいと思います。
現時点では GitHub は、 1GB までは無料でLFSが使えるようなのでこちらを利用したいと思います。

GitHub で新規のリポジトリを作成し、そのリポジトリをリモートするように今回のリポジトリを設定しておきます。

そして普通に git push origin master を実行してみます。

というように普通に成功しました。
(ほかの設定も必要なのではと思っていましたので意外でした)

さて、正常にあがったところでこのリポジトリを別の場所で clone してみたいと思います。新規に取得してみることが目的なので、別PCでやってもかまいません。

内部的には追加したバイナリファイルは単なるテキストファイルに変わっています。
しかし、clone,pull などのコマンド実行の際には、LFSがうまく実行され、バイナリファイルが復元されます。

などと表示されている行がまさにバイナリファイルを取得している状態を示しています。

まとめ・感想など

準公式での巨大バイナリデータに対する対策が入ったことは大きいと思います。
最低限の LFS の動作を確認してきましたが、Git をコマンドで扱っている人にとってはすでに実用になるかなと思います。

tortoisegitとの組み合わせについて

1.8.16.0 のバージョンを使っている場合での話になりますが、ちょっとまずい点がありそうです。
「 TortoiseGit commit with git-lfs files, show me a error: “.git/index.lock” file exist」
というエラーがあるようで、これが 1.8.16.4 かそれ以降のバージョンで修正されるようです。

バイナリ状態がちょっと怪しい挙動

バイナリファイルを含むリポジトリを clone した際にバイナリファイルが復元されないケースがありました。このときファイルを試しにテキストエディタで開いたら以下のようになっていました。

このときバイナリデータの復元はどうするかというと、以下のコマンドによって復元(再取得)が行えます。

これによりデータが元のバイナリデータとして復元されます。

このような状態に陥っているときには、バイナリファイル復元した状態がすでに変更状態と見なされてしまうようで、最低限のデータ取り出しを行ったら、新規にリポジトリを作成・取得し直しといったことを行った方がよさそうでした。

対応プロトコルについて

Git LFSは大容量ファイルに対するサブのリポジトリを作ってそこにデータを放り込みます。このときの通信は http となるようで、前身の git-media のほうが対応種類が多くて状況によって適切に使い分けができた気がします。LFSもまた対応が広がってくれるとうれしいのですが。

LFSによる前提の崩壊?

従来からの使用者の感覚としては、ソースコードと大容量ファイル、それぞれ別管理という印象が強いですが、この機能が標準になってさえしまえば、これらをまとめた単位がリモートのリポジトリという1つのまとまりという認識に変わりそうです。
1つ気になった点としては、LFSリポジトリ(別の置き場を今はこう呼んでおきます)ができて、ここから必要なデータだけを復元するやり方によって、
開発者全員が全てのリポジトリデータのクローンを持つわけではなくなったと考えられます。
そのため、少々強引な表現ではありましたが「分散リポジトリだから開発者全員が同じリポジトリデータを持つ」は崩れてしまった前提になるのではないかなと感じます。
(そもそも公開されていないブランチもあるでしょうから、全員が同じリポジトリデータを持つわけではなく、単に公開されているものにおいては同じ、くらいなのですが)

LFSリポジトリデータ自体のクローンは行われないわけなので、ここにたまっているデータをきちんとバックアップしてあげる仕組みがないとトラブル時にバイナリを失ってしまうということになるのではと心配が残ります。

試しに適当な場所にリポジトリをcloneした後で、リモートリポジトリを削除し、ブランチの移動やら任意コミットへのcheckout を実行したところ、バイナリファイルの復元に失敗してしまうようでした。


X-Window なしで OpenGL ES2 を使う その3


Ubuntu で NVIDIA のボード&ドライバを使って試してみました。

NVIDIA のプロプライエタリドライバをインストール

今回使用したのが NVIDIA の Geforce 750 Ti だったのですが、
Ubuntu 15.10 の標準インストールで使える nouveau ドライバでは通常の描画からして異常で使い物になりませんでした。
そこでプロプライエタリドライバをインストールするに至りました。

ドライバのインストールは以下のようにして行いました。

このドライバをインストールしてもうまく動かないようならば、
最初の描画不正の点も相まってボード故障も疑うところでした。
実際のところ、ドライバのインストール後の再起動したあとからは正常に描画できるようになりました。

コマンドでインストールしましたが、GUIからもインストールは可能だと思います。
(Additinal Drivers 関連かSoftwareセンターからできるかと思われます)

プログラムの実行

X-WindowなしでのOpenGLなプログラムを実行してみました。
そもそもこのドライバ使用でも /dev/dri/card0 が出現していたので、
KMS有効であると考えて、先日のプログラムは動くのではないかと思った次第です。

しかし結果は drmOpen で失敗してしまうようで、動作確認に至りませんでした。
NVIDIA のプロプライエタリドライバでも/dev/dri/card0 へのアクセス可能なようでしたが、 drmModeGetResources で失敗してしまうようでした。もう一歩でうまくいきそうな感じがするだけに、残念です。

追記

どうやら KMS サポートしているという見え方がダミーだったようです。
/dev/dri/card0 あたりがすでにダミーデバイスノードとの情報を見つけました。
そのせいもあって、 weston も動作しないという情報もあるようです。

http://wayland-bugs.freedesktop.narkive.com/4zE7PwYd/bug-90323-weston-launch-drmmodegetresources-failed


TortoiseGit で git add -p 相当できた


git には部分コミットを行う機能があります。これがコマンドでは git add -p ですが、 TortoiseGit からもこれと同じことが実現できることがわかったので記録しておきます。

まずは以下のように題材となるデータを用意してみました。
ある要求に対応するコードを実装したものの、途中で発見したバグを同時に直してしまったというケースです。このような場合にはバグ修正と機能追加といったように2つのコミットに分割するのが正しいです。

git-add-1

続きを読む


Ubuntu で Vulkan を試す (成功編)


ようやく Ubuntu で Vulkan のアプリケーション動作をさせてみることができたので、そこまでの方法をまとめておきます。若干強引な作業をしていたり、そもそもベータドライバだったりするので、試す際には自己責任でお願いします。

ubuntu-vulkan-sample-particle

以降の作業は Ubuntu 14.04.4 AMD64 版で、Geforce GTX 750 Ti が刺さっている環境の話でとなります。
また、Ubuntu はクリーンインストールした直後から始めている想定です。

この状態で nouveau ドライバがロードされているため、まずはこれを無効化します。
続きを読む


ようやくUbuntu で Vulkan 確認できた


Ubuntu で NVIDIA の Vulkan ドライバを入れて動作させようとがんばっていたわけですが、ようやく動作させることに成功しました。
ドライバのインストールを強行してなんとかなっているだけなので、綱渡り状態での動作です。サンプルのビルドにもちょっと手間がかかりましたが、以下のように動作させることには成功しました。

結局 Ubuntu 14.04, NVIDIA Geforce GTX 750 Ti という状態でここまでこれたので、正しく導入する方法をこれから探っていきたいと思います。

ubuntu-vulkan-sample-particle