洗濯機用の排水管にトラップを付ける
うちの洗濯乾燥機で乾燥運転を行うと，湿気を含んだ空気が部屋に漏れてきて，気温が低い日には，設置場所である洗面所が思いっきり結露してしまう問題で困っておりました。
ところで，衣類乾燥機は，乾燥に伴って発生する多量の湿気をどこかしらに捨てる必要があります。いちばん確実なのは屋外に排気してしまうことですが，これをやるためにはダクト工事が必要となってしまい，家庭用としてはあまり現実的ではありません。かといって屋内にそのまま排気しようものなら，濛々とわき出す湿気で大変なことになってしまいます。このため，家庭用の洗濯乾燥機には，排気を何らかの方法で冷却して湿気を凝縮し，液相で排水する仕掛けが備わっています。
いちばんオーソドックスな方法は排気を水道水で冷却する水冷式で，確実なのですが，乾燥運転時にも，無視できない量の水を使ってしまう欠点があります。そのせいか，うちの洗濯機では空冷式が標準となっており，能書きによれば，これは排気をある程度まで空冷したあと，そのまま排水管に吹き込んでしまう方法なのだそうです。そりゃすげえやと思いながら，ふと排水口を見ると……
どう見てもガバガバ。洗濯機の排水ホースにつながるエルボが，ものすごく適当に挿し込んであるだけであるだけで，この隙間から湿気が逆流しているのは明らかです。いままで気にもしてなかった部分ですが，これはいけません。
この排水口がどうなっているかというと，床下から床面まで立ち上がってきたVU管の端面に，銀色の化粧フランジが嵌めてあるだけで，いかにもやる気のない作りです。トラップも存在せず，顔を近づけると，それほどひどくはありませんが，うっすらと下水臭も漂ってきます。単純に，隙間をパテで埋めてしまうことも考えましたが，どうせやるなら，もう少しちゃんとやりたいところ。
そんなわけで見つけたのがこれです。いろいろ探したら，VU50の立ち上がりにそのまま嵌めこめるトラップがありました。ついでに密閉構造になるので，本来の目的であるところの，乾燥運転時の湿気漏れ対策にもなります。
現物がこちら。エルボが出ているフランジが床面に当たる部分で，下の切れ込みが入っているパイプが，VU管に落とし込むトラップ部分です。
最初に，既設の化粧フランジが邪魔なので撤去します。VU管に接着されていたようで，やむを得ずかなり強引にこじり取りました。そしたらパイプが少し欠けちゃったけど，まあいいや。
上から見るとこんな感じ。真下に横引き管が見え，ほんとに「ただの穴」です。
トラップを取り付ける前に，床材と管の間に隙間があいていること自体がよろしくないので，シリコーンをどっぷりと塗ってコーキングします。
次に，トラップを設置するためのフランジを設置して，ねじで固定します。密閉性を高めるため，裏面にもシリコーンを少し塗っておきました。
そしてその上から，トラップを落とし込み，化粧カバーと，ゴムのエルボを設置して完成。ほとんど「ただの穴」だった従前と比べれば，天と地の差です。
最後に洗濯機の排水ホースをつなぎ，漏れがないことを確認して作業終了。ホースバンドが，いまひとつ合わなかったのでビニテで巻きました。エルボと，ホースのニップルみたいな部品にはテーパーがついているのに，添付ホースバンドは真っ直ぐなんだもの……
まだ乾燥運転はやっていませんが，この構造なら大丈夫でしょう。
青森～鹿児島2000km
青森から鹿児島まで，高速道路でつながっているか？
答えはYesで，2000kmあまりあります。しかし，そのルートの一部として「磐越自動車道」の名が浮かんだ人は，プロドライバーでなければ，相当な道路オタクでしょう。
1995年，日本列島を縦に貫くように整備が進められてきた高速自動車国道網は，最後の未開通区間として残っていた九州自動車道の人吉～えびのIC間が開通したことによって，北は青森から，南は鹿児島まで，なんとなく一本で結ばれたのです。
しかし，青森から鹿児島まで一枚の通行券で通し走行できるようになるまでには，少し待たなければなりません。よくよく考えると，東京付近では，放射状に伸びる各高速道路間は直接つながっていません。たとえば青森から東北道を東京まで走行して，さらに東名で西へ向かうには，途中でいったん首都高速道路などを通る必要があります。このとき，東北道から流出し，改めて東名に入った扱いとなるため，東京を通るルートでは，通しで走行という条件は満たすことができません。
これが可能となるのは，1997年に，福島県のいわきJCTと，新潟県の新潟中央JCTを結ぶ磐越自動車道が全線開通してからです。磐越道の開通によって，東北道の途中，郡山から磐越道でいったん新潟へ向かい，北陸道で米原まで西進したあと，名神でさらに西へ向かうことがルートが形成されました。途中，東京を強引にバイパスする経路ができたことにより，ようやく青森から鹿児島までが一枚の通行券でつながりました。
そして2015年10月31日，圏央道の延伸開通よって，東北道と東名が結ばれたことで，この間のルートに新たな選択肢が生まれ，わざわざ日本海側まで迂回しなくても，東京を通らずして青森から鹿児島まで行けるようになりました。しかし，興味深いことに，圏央道は必ずしも距離の短縮にはなっていません。青森から鹿児島までの距離は，圏央道経由よりも磐越道経由の方が少し短いのです。
日本地図を見ればわかるとおり，東北地方と近畿地方との間は，海に張り出している太平洋側を通るよりも，直線的な日本海側を通った方が近いことは明らかなのが，郡山から，わざわざ新潟まで向かうという無駄を含めてもまだ短いというのは，少し意外な感じがします。圏央道が首都圏を大きく迂回していることや，東名が浜松あたりを海沿いにカーブしていることが要因なのでしょう。
ちなみに，この地形のせいで，鉄道では，日本海側が物流の大動脈となっています。北海道や東北から近畿以西へと向かう貨物列車のほとんどは，最短ルートとなる日本海側の奥羽本線や羽越本線，信越本線，北陸本線を経由し，琵琶湖の西側を通る湖西線で京都にやってきます（逆もしかり）。札幌と福岡を往復する，日本最長とされる貨物列車も，日本海側を通ります。ここ，新幹線の開業によって，細切れに第三セクター化されちゃってますが，大丈夫なんですかね？
スイッチ交換
築31年の家に住んでいますと，細かい不具合には，しょっちゅう出くわします。
ある日の夜，自宅の廊下を歩いていると「ジ～～～～」という微かな異音が聞こえてきました。どこで鳴っているのか，耳を澄ませて発信源を探ってみると，トイレの照明スイッチが人知れず鳴き声を上げておりました。
松下電工の埋込ほたるスイッチ（WN5051かな）でありますが，内蔵のネオンランプは経年でとっくに不点灯。しかもトイレの照明用ですから，数あるスイッチの中でも開閉回数は特に多いはずで，30年あまりも使えば，まあ寿命でしょう。
外してみると，芯線が見えてるとか，雑な施工ですね（まあよくあるけど）。余長が十分にあるので，元から剥いてあった部分は切り落として，ちゃんと正しい長さで剥きます。
フルカラーからコスモワイド21へアップグレードすることにしました。ほたる片切の1回路だと，ワンセットで850円くらいです。フルカラーだと半値以下なので，やっぱりちょっと高い。
仮止めしたあと，ちゃんと水平をキメます。
そしてカバーを取り付けて完了。綺麗になりました。
SORACOM Air で VoIP を通す
SORACOM Airは，株式会社ソラコムが提供を開始したIoT向けのモバイルデータ通信サービスです。SORACOM Airの最大の特徴は，IoTという，従来のオペレータが注力してきた分野とはまったく異なるニーズをターゲットとしていることでしょう。一つの象徴的な特性として取り上げるならば，SORACOM Airで提供される速度クラスは，最小32kbpsから，最大でも2Mbpsまでしかなく，しかも課金は従量制。データ通信サービスといえば「安くて速くて定額です」が当然の謳い文句となっている世の趨勢に逆らい，なにやらただならぬ，しかしながら「どうせ1日10バイトしか流さないから1GBとかいらないんだよねえ」的な世界に暮らす我々にとっては，とてもありがたい異彩を放っているのが，このSORACOM Airというわけです。
SORACOM Airで音声を通してみたい
SORACOM AirはのSIMはデータ通信専用であり，いまのところ，回線交換による音声通話機能は提供されていません。しかし，音声をIP化してデータとして伝送するVoIPならば，原理的には通すことができると考えられます。これ自体は，SkypeやLINEなどですでに実現できていることですが，SORACOM Airは，一般的なSIMと比べると伝送帯域が控えめなサービスです。そこで，そもそも音声のようなストリーミングデータでも流せるのか，また，どのような品質になるのかを，実際に検証してみることにしました。
検証環境
この検証のために，下図のような環境を用意しました。
事前準備として，自宅にAsteriskサーバおよび対向となるSIP電話機を設置し，SIPによる音声通話ができる状態としておきます。これらのホストは，NATの内側にありますので，The Internetからは直接は接続できません。そこで，L2TP/IPSecによるVPNトンネルを経由して，自宅外からもセキュアに接続できるようにしておきます。
この検証では，3G/LTE網を経由でSIP通話を行う必要がありますので，通話検証用として手持ちのSIMフリーなAndroidスマホ（ASUS Zenfone）を使用しました。Androidで使用できるSIP通話アプリとしては，Androidネイティブの実装のほか，いくつかの選択肢が存在します。今回は，オープンソースのCSipSimpleというアプリを利用しました。
SORACOM Airは，必ずしもスマホでの利用を念頭に置いた通信サービスではありませんが，使えないわけではありません。ZenfoneにSIMを挿し，PDPコンテクストの設定を行えば，問題なく接続することができました。VPN接続は，Androidのネイティブ機能で行うことができ，これによりSORACOM Airから自宅までの経路が開かれます。
音声を通すために必要な伝送帯域
次に，VoIP通話に必要な伝送帯域を検討します。
一つの基準として，固定電話の音声は，8kHzサンプリング，8bitの対数PCM（日本ではμ-law）で符号化することが標準であり，64kbpsのストリームとして伝送されます。VoIPにおいても，特に商用IP電話サービスでは，固定電話に準じてμ-lawを無圧縮のまま伝送することが一般的です。
音声を，非可逆なコーデックで圧縮すると，必要な帯域をぐっと小さくすることができます。一例として，3Gの回線交換では12.6kbpsのAMRコーデックが標準として使われており，かつて輻輳が激しかった第２世代携帯電話時代には，その約半分の5.6kbpsまで圧縮するコーデックも運用されていました。当時，まるでロボットが話しているかのような，ひどい音質に辟易とされた方もいることでしょうが，音質劣化を許容すれば，音声は意外と小さな伝送帯域でも送れるのです。
実際には，これにUDPや，IP，RTPなどのパケットヘッダによるオーバヘッドが加わります。VoIPでは，遅延を小さくするため短いパケットを大量に送信するので，ヘッダも無視できない要素となります。たとえば，64kbpsのμ-lawでは，ヘッダも加味すると90～100kbps程度のストリームとなるため，これを安定して伝送できる必要があります。
候補は s1.minimum か s1.slow
SORACOM Airでは，目的とする通信の特性に応じて，速度クラスをユーザが選択することができ，最小の s1.minimum が32kbps，その上の s1.slow が128kbpsというラインアップになっています。s1.minimum でも，圧縮さえすれば音声がなんとか通りそうな太さですから，今回の検証の対象とします。s1.slow では，128kbpsもありますから，μ-lawのままでも通ってしまいそうです。
上記を踏まえ，s1.slow と s1.minimum で試してみることにします。なお，s1.minimum では，64kbpsのμ-lawが通らないことは自明なので，Asteriskで使えて，13kbpsまで圧縮されるGSMコーデックを用いることにしました。
s1.slow（128kbps）ではまったく問題ない
前置きが長くなりましたが，実際に通話テストを行ってみます。
最初の検証として，SIMを s1.slow に設定し，自宅内で電話をかけてみます。このとき，μ-law，GSM，いずれのコーデックでも，あっさりとつながりました。音の途切れや乱れはなく，ごく普通に通話できています。s1.slow なら，64kbpsのμ-lawでさえ問題なく通せるようです。
特筆すべきは，音声の伝送遅延が，思った以上に小さいことです。そもそもLTEでは，音声通話はVoIPとして実装する（いわゆるVoLTE）前提となっており，移動体通信網としては，かつてない水準の低い伝送遅延を実現しています。自宅ルータに対するpingのRTTが40ms前後であり，この程度の遅延ならば，ヒトは違和感をまず感じません。本物のVoLTEと，今回のような「勝手にVoIP」では，網上ではQoS制御上の扱いに差はあるものの，勝手にVoIPでも，それなりに実用になることがわかります。
端末の接続先を3G網に固定した場合でも，LTEと同様に音声通話は問題なく行えました。このとき，pingによるRTT測定で80ms前後で，聴感上も若干遅延が増えた印象がありました。
s1.minimum（32kbps）では無理だった
次に，SIMを s1.minimum に設定し，GSMコーデックで同様の通話テストを行ってみました。その結果，呼は通るものの，音声パケットのロスが30%以上もあり，通話として成立する品質にはなりませんでした。
前述のとおり，音声パケットはヘッダによるオーバーヘッドが大きく，音声を圧縮すればするほど，ヘッダのデータ量が支配的となってきます。今回の検証では，VPNのオーバヘッドも加わっているため，32kbps の帯域を超えてしまっているようでした。もう少し工夫してオーバヘッドを小さくすれば，ギリギリで通せるかもしれません。
移動も検証してみる
移動やハンドオーバーの影響も検証するため，通話状態にしたまま，自宅がある東京都八王子市周辺を車で走行してみました。データ通信では，移動による通信状態の乱れや基地局間のハンドオーバーを意識することはあまりありませんが，リアルタイムストリーミングの音声通話では，パケットロスには敏感です。短い時間の途絶であっても，人は気づいてしまうからです。
SIMの設定は s1.slow とし，コーデックは μ-law としました。運転上の安全を考え，この検証では対向から音楽を一方的に流し，これをハンズフリーのスピーカーで聴取して評価する方法をとりました。
ところが，走っても走ってもぜんぜん途切れないのです。
ここは，延長約1.8kmの浅川トンネルから外へ出るポイント。圏央道高尾山インターの近くです。トンネル内はエリア化されていますが，前後の坑口付近で確実にハンドオーバーします。それでも音声の乱れは特に感じませんでした。
だいぶん走り回って，ようやく見つけた途切れポイントは，坑内がエリア化されていないこの短いトンネルでした。といっても，トンネルに入ってしばらくすると音声が1秒ほど途切れただけで，出口付近すぐに復帰しました。
車や電車で移動しながら試験してみると，エリア外となっているトンネルような例外を除いて，パケットロス率は数パーセントというレベルでした。この程度ですと，聴感上も途切れた感じはほぼわかりません。LTEのハンドオーバーは思った以上に高性能だというのが，やってみた印象です。
高トラヒックエリア
10月16日に，渋谷で SORACOM Developers Conferenece #0 が開催され，そこで本件についてLTを行う機会がありました。渋谷はとにかく人が多いため，モバイル通信の世界では，世界有数の高トラヒックエリアとして知られています。高トラヒックエリアでは，みんなが無線リソースを奪い合いってますから，八王子のような郊外よりも厳しい条件にあります。
LT中で行ったのは，その場で，自宅にいる妻に電話をかけるというデモです。
このときも，問題なく接続することができ，会場で妻と会話することができました。ただし，上り方向でパケットロスが多少出ていたようです。帰宅してから妻に具合を聞いた（≒非礼をお詫びした）ところ，プチプチ音が少し出ていたとのことでした。
料金
SORACOM Airの料金は，従量制です。VoIPのようなストリーミングでデータをジャンジャン流すと料金が気になるところですが，s1.small を使った場合で，3分2円です。
計算根拠は，以下のとおりです。100kbpsのストリームが上下対称で流れるとして，3分間あたりのデータ量は 12.5 kBytes/s × 180秒 ＝ 2.25 MBytes となります。これに，上りの単価 @0.22円/MB および下りの単価 @0.70円/MB をそれぞれ乗算すると，上り 0.5円，下り 1.5円となり，おおよそ2円になります。検証のためにだいぶん使った気がしたものの，実際の請求額も数十円でした。
※ この記事は，SORACOM リリース記念リレーブログの10月19日分として書きました。
FreeBSD を read-only で起動
Raspberry Pi がそうであるように，SDメモリカードや，USBメモリなど，FlashデバイスでLinuxなどのOSを運用するケースが多くなってきました。これで，一つ気になるのは，頻繁な書き換えに伴うFlashメモリの劣化です。Flashメモリは，消去と書き込みによって劣化が起きるため，信頼性をもって行える回数には上限があります。ちゃんとしたSSDだと，書き換えが特定のメモリブロックに集中しないようウェアレベリングを行っていたりしますが，SDやUSBメモリがどこまでの対応をしているのかは，よくわかりません（やってない？）。
わたし自身は壊した経験はありませんが，Raspberry Pi に MySQL を入れて INSERT や UPDATE が定期的に起きる運用を続けていたら，半年くらいでSDカードが怪しくなってきたという話を知人から聞きました。たまたまかもしれませんが，好ましい使い方でないことは確かだと思います。
そんなわけで，長期にわたって運用する場合は，書き換え回数をなるべく減らすことが吉です。いちばん手っ取り早くて確実なのは，システムが完成して運用フェーズに入ったら，OSのルートファイルシステムを read-only でマウントしてしまい，/var や /tmp はRAMディスクとして用意することです。副次的に，すべてのファイルシステムが read-only なら，なんの罪悪感もなく電源をぶち切りできるシステムなります。
FreeBSDの場合
FreeBSD だと，picobsd や nanobsd みたいな選択肢もあり得ますが，わたしは普通の FreeBSD を read-only で実際に運用しているので，やり方を紹介します。
/ を read-only に
まず，/ を read-only にする方法。/etc/fstab の / について，Options を rw から ro 書き換えるだけです。
# Device Mountpoint FStype Options Dump Pass#
/dev/da0p2 / ufs ro 1 1
/dev/da0p3 /persistent ufs rw 1 1
このシステムでは，ディスクを2パーティションに分割し，/ のほかに /persistent を作って read-write でマウントしてあります。これは必須ではありませんが，後述するように，/var をRAMディスクとすると再起動するごとに内容が消えてしまうので，消えて欲しくないデータを置くところとして使います。あと，swap したら負けなので，swap パーティションはそもそも作りすらしません。
RAMディスクを作る
次に，RAMディスクの設定。/etc/rc.conf に以下の行を追加するだけで，勝手に作ってくれます。サイズは調整可能です。
tmpmfs="YES" tmpsize="20m" varmfs="YES" varsize="32m
これで，起動時に 20BMの /tmp と 32MBの /var がRAM上に作られ，newfs とマウントに加え，中身の作成まで勝手にやってくれます（fstabに追記する必要はありません）。
確認
上記の設定を行って再起動し，mount コマンドで確認しましょう。以下のように / が read-only でマウントされ，/var と /tmp がRAMディスクになっていたらOKです。
/dev/da0p2 on / (ufs, local, read-only) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /persistent (ufs, local, soft-updates) /dev/md0 on /var (ufs, local) /dev/md1 on /tmp (ufs, local)
一時的に read-only と read-write を行き来する
mount -o ro / と mount -o rw / でできます。read-write から read-only に戻すとき，オープンされているファイルがあるとエラーになるので注意してください（それでもなお強制的に戻す場合は -f を付ける）。
/var の中身はどうやって作られているのか
RAMディスク上に置いた /var は，起動するごとに新たに作られます。この時点では /var は空っぽのはずですが，起動が完了した時点では，なぜかちゃんとした /var のディレクトリツリーができあがっており，/var/log や /var/mail などが存在しています。
これは，/etc/rc.d/var というスクリプトが，うまくやってくれているためです。/var が空っぽであった場合は，/var に新たなディレクトリツリーを作る処理が入っています。何をどう作るかの定義は，/etc/mtree/BSD.var.dist および /etc/mtree/BSD.sendmail.dist （sendmailを使う場合のみ）に書かれています。中身を見ると，少し取っつきにくいファイルですが，/var の構造が定義されていることがわかります。
作られた /var 以下に独自のディレクトリが欲しい場合は，/etc/mtree/BSD.var.dist に定義を追記すると作ってくれます。
/var に起動時からファイルを置きたい
/etc/mtree/BSD.var.dist では，/var に作るディレクトリしか定義できません。したがって，この定義から，ファイルを作らせることはできません。しかし，/var になんらかのファイルを置きたい場合もあります。いちばんあり得るのは，crontab でしょう。crontab は /var/cron/tabs に保存されますが，/var は毎回まっさらになるので，このままでは cron が使えません。
いちばん綺麗な解決策は，なるべく /var に期待しない方法を考えることです。cron の場合であれば，/var/cron/tabs を使わず，すべて /etc/crontab に書いてしまえば解決します。そのほかにも，プログラム側で使用するディレクトリを指定できる場合は，/var 以外のどこかに指定します。こういったときに，前述した /persistent が生きてきます。
もう一つは，消えないところにひな形を用意しておき，/etc/rc が実行されるタイミングで，必要なファイルをコピーしたり，シンボリックリンクを作るスクリプトを用意しておくことです。
消えては困るファイルの扱い
RAMディスク上の /var は，再起動で綺麗さっぱり消えてしまいます。しかし，記録として重要なログや，再起動をまたいだ継続性が必要なステートを記録しているファイルなどは，消えてしまうと困ります。こういうときのために，わたしは /persistent を使うようにしています。
たいていのアプリケーションは，自らが書き出すファイルのパスを設定することができるので，必要に応じて /persistent に向けておきます。それで対処ができない場合は，/var から /persistent へシンボリックリンクを張ってもかまいません。
大事なのは，劣化防止を目的として read-only にしたのですから， /persistent にどうでもいいようなものをゴチャゴチャと置かないことです。真に必要なものだけに絞りましょう。
お行儀の悪いプログラムとの付き合い方
/ とか /usr が read-only で大丈夫なの？という疑問がわくかもしれませんが，通常運用時には，/ や /usr に書き込む必要はないので，ほぼ大丈夫です。問題は，どうしてもそういうところに書き込みたがる，お行儀の悪いプログラムがある場合です。
そういうものに出くわしたときは，まず，できるだけ設定で /var あたりに持って行けないか検討します。ただし，それではどうしてもダメなものもあります。代表的なものとしては，resolv.conf を /etc に書き出す必要がある dhclient などがあります。
この手のものは，個別に対処するしかありません。特定のファイルだけ /var あたりへのシンボリックリンクとしたりとか。
LIVA MINI PC KITをヘッドレス起動
ECS - LIVA MINI PC KIT は，ヘッドレス（ディスプレイを接続していない状態）では起動してくれません。BIOSの設定を見てもそれらしい項目がなく，いろいろいじってみたものの，どうやっても無理だったので，そういう仕様なのだと判断しました。
この子をサーバのような用途で使うときは，ヘッドレスで起動しないようでは大いに困ります。最初に構築するときにはディスプレイをつなげて作業するとしても，抜いてしまうと，遠隔で再起動したような場合に，起動しないということになりかねません。
対策として，75Ωくらいの抵抗（E12系列で近いのは68Ωか82Ω）でVGA端子のRGB出力を終端し，ディスプレイが接続されているものと誤認させると，無事にヘッドレスで起動できるようになります。
わたしは，以下のようなものを作りました。リードを折り返してあるのは，そのままではガバガバだったっためです。
これを，VGAのRGB出力とGND間にそれぞれ差し込んでおきます。ちなみに，USB端子にささっているのは，前の記事でFreeBSDをインストールしたUSBメモリです。
これで無事にヘッドレス起動できるようになりました。同様の原理のものは「VGAダミープラグ」とか「HDMIダミープラグ」みたいな名称で販売されていますが，抵抗の方が遙かに安価です。
LIVA MINI PC KITとFreeBSD
少し前のことですが，ECS - LIVA MINI PC KITを購入してみました。
筐体の大きさは，直感的には「お豆腐半丁分」程度。Intel BayTrail-M SoC と，DDR3L 2GBと，32GBまたは64GBのeMMCストレージがオンボードで搭載され，外部インタフェースとしては，GbEとWi-Fi，USB，HDMI，VGAなどが出ています。
DC5V単電源で動作し，消費電力はTypicalでたぶん10ワットもいかない。ファンレスながらも，稼働中はヒートシンクがほんのりと暖まる程度です。
しかしクセがある
スペックだけを見ると，自宅でちょっと動かしておきたいサーバや，実験用環境として使うには最適なものに思えてきます。しかし，一般論として，この手の低価格ミニPCには，ハードウェア的な「クセ」が多かれ少なかれあり，好きなOSを入れて運用したいという向きは注意が必要です。公式にサポートされているOSならば何の問題もなく動作しても，Linuxを入れるとか，少しでも道を外れたことに手を出そうとすると，とたんに「クセ」が顕在化するのです。
そもそも，低価格ミニPCは，フルサイズのPCとは少し違った構成になっています。BIOSではなくUEFI起動が必要だったり，eMMCストレージや，Wi-Fiモジュールなど，普通のPCではあまり採用されないようなデバイスが，ふんだんに使われていたりします。こと，UEFIがらみの話は根が深いようで，以下の記事が興味深いです。
Why cheap systems run 32-bit UEFI on x64 processors - Intel Software and Services
LIVAに話を戻しましょう。この子も，ご多分に漏れずクセがあるため，ここで気づいたことをまとめておきたいと思います。
Ubuntuはわりと動く
LIVAにおいて，公式にサポートされているOSはWindows 8.1 64bit版のみです。それ以外では，Ubuntu Desktopが比較的素直に動作し，Ubuntu Serverも少し無理をすればインストールできます。Ubuntu Serverのインストールに一工夫必要なのは，eMMCのドライバがないためです。
第323回 1週（2週？）遅れのGW特別企画！・ECS LIVAでUbuntuを使う：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社
ECSのLIVA-B3-2G-32Gにubuntu-server14.04 を今度こそインストール — eelsden
FreeBSDを動かしたい
Ubuntuは動いたので，FreeBSDも動かしたくなりました。インストール時点での最新版，FreeBSD 10.2-Release amd64-uefiのインストールイメージをUSBメモリに書き込み，以下の記事を参考に，インストーラを起動することができました。ブートローダーで mode 2 と打ってビデオモードを切り替えないと，なぜかカーネルがPanicします。
LIVA C0-2G-64G-WでFreeBSDを動かす カール・ミッチーのなんでも日記/ウェブリブログ
残念ながら，FreeBSDは内蔵eMMCを認識してくれません。また，Wi-Fiモジュールも認識してくれません。Wi-Fiはまあいいとして，eMMCを認識しないとインストール先が存在しないことになります。
そこで，インストールイメージとは別のUSBメモリをあらかじめ接続しておき，そこへインストールすることにします。FreeBSDは，これをSCSIドライブとして認識するので，手順は，普通のディスクにインストールするのと変わりません。
なお，USBメモリへのインストールはものすごく時間がかかります。ソースコードやportsまで入れると何時間もかかるので，必要最小限の構成でインストールすることをおすすめします。
FreeBSDは，入れてしまえば安定動作
インストールさえすれば，FreeBSDはUSBメモリから起動し，安定して動作します。Wi-Fiは使用できませんが，GbEは使えますので，ネットワークにも接続できます。ディスクアクセスは，所詮はUSBメモリなので決して速くありませんが，インストールが異様なまでに遅いこととは対照的に，実運用では，まあまあ実用的なレベルです。ただし，連続して書き込みを行うと，どうしても時間がかかるようです。
USBメモリのパーティション構成
gpart show コマンドで見られます。
=> 34 30529469 da0 GPT (15G)
34 1600 1 efi (800K)
1634 16777216 2 freebsd-ufs (8.0G)
16778850 13750653 3 freebsd-ufs (6.6G)
このとおり，先頭にefiパーティションがあることがわかります。残りのパーティションは，2つに分割しました。/ を read-only として，read-write 可能な別パーティションを設けるためです。
以上，とりとめもなく書きましたが，参考になれば幸いです。
