Lightweight Jabber Client Apps for Android

Oh, the irony. The Hangouts app for Android got a whole lot better recently when it integrated the Google Voice service into itself — mostly good news except for old, slow Android devices which can no longer bear the burden of this now-bloated software. So I set out to find an alternative, specifically for my old Sony Ericsson X10 Mini E10i, so I can at least send and receive Hangouts/Google Talk messages on it.

Simple XMPP Client has a very small footprint (622KB), which I liked, but the features are too limited. You cannot even have it auto start. Plus it does not support multiple accounts.

yaxim – XMPP/Jabber client also has a relatively small footprint (1.2MB) and also does not support multiple accounts, but at least it auto starts as the device is turned on. Incoming messages are not shown in the notification area, which is a little inconvenient, but is still usable. Okay, I will use this one for now.

Xabber is definitely rich in features but heavy (2.5MB) also. It supports multiple accounts so if I should one day feel like being constantly annoyed by messages on Facebook Chat too (yeah, right), I might switch to this one.

SMS@Email: Another SMS-Email Gateway App for Android Devices

This is a followup article to “SMS-Email Gateway on Android Devices“.

In that, I stated that Relay Me was the app that met my needs; however, there was a problem. I am going to elaborate on it later in this article, but I have found an alternative: SMS@Email (on Google Play). It is quite similar in the feature set, and all the features come for free, unlike Relay Me’s case.

Unfortunately, it does not function the way it should on my Sony Ericsson Xperia X10 Mini (E10i/Robyn) running MiniCM 7.2.2. But it seems to be because X10 Mini keeps killing the service because of lack of memory.


Relay Me’s problem is that it does not correctly MIME-encode the email messages it sends out and because of that, some MUAs, such as Thunderbird, cannot display the messages correctly.

This seems to be due to a misunderstanding on the author’s side about what Gmail’s “UTF-8 encoding” means. It means Gmail will encode the message with its body text represented in the UTF-8 character set. This encoding uses the MIME encoding scheme, just as it should. But this happens only when you compose your message in the Gmail Web app or the Gmail Android app.

However, if you are using Gmail’s SMTP server, i.e., if you are using Gmail as MTA, this encoding process is not done on Gmail’s side; it’s the MUA’s responsibility. You cannot just throw raw UTF-8 text to Gmail’s SMTP server. You have to properly MIME encode it before you do so.

This appears to be the root cause, given the messages Relay Me sends lack anything MIME-related entirely. Given that you’d have to MIME-decode incoming emails to be able to forward them as SMSes, if Relay Me is missing MIME-en/decoding facilities, it’d be fair to think it is not capable of forwarding properly-MIME-encoded incoming emails as SMSes — although I cannot actually test this hypothesis; this feature comes with its paid version and I do not have it.

To the author’s credit, he has already listed this issue as something that needs to be resolved.

Power over Ethernet (PoE)に関する大いなる誤解

屋外用IP監視カメラを新設しようと考えていてどの機種にしようかといろいろ悩んだのだが、その過程で自分がPower over EthernetことPoEに関して大いに誤解していたことが、多大なる時間を浪費する結果を引き起こしてしまった。最初に、一度でもきちんと英語版WikipediaのPoEの項を最初から最後まで目を通していれば回避できた誤解だったが(全般的に日本語版は情報が不十分)、流し読みしかしなかったため、なかなか気づかなかった。

PoEイジェクタを使ってIPカメラに電源を供給するの図---*誤りあり*

PoEイジェクタを使ってIPカメラに電源を供給するの図—誤りあり

以下、HikvisionのDS-2CD2532-ISWを前提に説明する。

直接カメラに電源を供給する際はDC 12Vが要求されているので、PoEインジェクタに供給すべき電圧もDC 12Vだと思い込んでしまった。右の図は交渉していたAliexpress.comのセラーに自分の言いたいことを伝えるために描いた図であるが、ここでも誤ってPoEインジェクタに供給すべき電圧がDC 12Vだとしてしまっている(図右下)。

しかし、PoEの規格IEEE 802.3afで要求しているのは(典型的には)48Vなのである。なので、図にあるようなDC 12V出力のAC/DCアダプタから電源を供給しても、PoEとしては動作しない…いや、正確にはIEEE 802.3afの規格には準拠せず、それを期待するPD (Powered Device)を駆動することはできない。HikvisionのDS-2CD2532-ISWはそういうPDなので、こういう形でUTPケーブル経由で電源を供給したところで、駆動できない。

問題の根源は、自分が「PoE=IEEE802.3afないしIEEE802.3at準拠」だと思い込んでいたところにある。これは誤りで、”PoE”製品と謳っていても、IEEE802.3afにもIEEE802.3atにも準拠していない製品がある。これになかなか気付かなかった。

英語版WikipediaのPoEのページには、”Non-Standard Implementations“という項があり、いくつか種類が列挙されているが、その中で我々非業界人が一番目にしそうなのはpassiveと形容されている製品群だろう。IEEE802.3af/IEEE802.3at準拠のPSE (Power Source Equipment)PD (Powered Device)間では、power-up時にネゴシエーションが行われ、誤って非PoE対応のPDが繋がれてしまった場合の保護であるとか、供給電力の制限などが行われる。”Passive”デバイス間ではこのようなネゴシエーションは行われず、入力された電力がそのままUTPケーブルに流される。したがって、PDの仕様に合わない電流が流された結果PDが壊れる可能性はある。

新設予定の屋外用IP監視カメラに対する要件“で、「スプリッターとインジェクターがペアになったものが数米ドルで手に入るようだから」と書いたが、実はこれらはその”passive”デバイスに当たる。これらPoE injector/splitterをペアで使う限り、injectorに入力された電力がそのままsplitter側に出力されるので、仮にそれが48Vでなくても、splitter側で使いたい電圧・電流が得られるようにしていれば、これはこれで使いようがある。上の自分の図の場合でも、DS-2CD2532-ISWは12VDCの入力端子もあるので、injectorだけではなく、splitterも併用し、splitterで得られる12V電力をカメラに供給してやれば原理的にはカメラを動作させることができるはずだ(ただし、UTPケーブルで電送する間に電力が損失することは考慮しないといけない)。

こういった話を理解するのに役に立ったのが”different POE voltages, how does POE work?“だった。自分同様混乱した人に対する解説がある。中でも以下の投稿が端的に説明している:

What is confusing are devices that spec  “12v dc, 24vac, PoE” – this means the camera uses 12v when powered from a transformer, and 48v when powered via Ethernet.   Putting 12v via Passive POE will not work – but 48v via Passive POE does work.

わかったところで、ではどうするかだが、以下の3通りが考えられた:

  1. きちんとしたIEEE802.3afないしIEEE802.3at準拠のPoEスイッチを使う。
  2. Passive PoE injector/splitterと12V AC/DCアダプタを組み合わせる。
  3. 48VDC出力のpassive PoE injectorを使う。

機器の保護の観点からは1.が理想的ではあるが、何せ高くつく。2. と 3.はコスト的には大差ない。ただ、今回カメラは屋外に設置するので、コネクタ部は防水加工しなくてはならない。2.ではそれが3箇所になるのに対して、3.では1箇所で済むので、3.で行くことにした。

結局Free Shipping Black 48V 0.5A 500mA POE Power over Ethernet Power Supply US EU Plug lan port Power Injector with LED-in AC/DC Adapters from Electrical Equipment & Supplies on Aliexpress.com | Alibaba Groupを送料込みの$8.46で購入。

以下、上記結論に至るまでに考慮した製品。


Amazon.co.jp: NEEWER 自動レンジ調節/スイッチング 48V-0.5A アダプター POE インジェクター IP 電話/ 監視IPカメラ 対応: パソコン・周辺機器

Free Shipping Black 48V 0.5A 500mA POE Power over Ethernet Power Supply US EU Plug lan port Power Injector with LED-in AC/DC Adapters from Electrical Equipment & Supplies on Aliexpress.com | Alibaba Group

SUNHANS POE injector 48V 1000mA Power Over Ethernet Switch 100Mbps 802.3af 802.11G Freeshipping-in Switching Power Supply from Electrical Equipment & Supplies on Aliexpress.com | Alibaba Group

48V POE injector Power over Ethernet Switch Adapter 0.5A DC Power Supply With EU US Plug Free Shipping-in AC/DC Adapters from Electrical Equipment & Supplies on Aliexpress.com | Alibaba Group

PBXes.comでのAudioBypassの実現

これも古い古い、書きかけてほってしまってた記事。その後状況が変わって、もうPBXes.comを自分の電話システムのメインとして使うことはないと思うので、突き詰めることなくこのまま公開してしまおう。


PBXes.com

私は、ブラステルやFusion IP-Phone Smartをこれに収容する形で、これらサービスから付与された050番号宛電話をこのPBXでルーティングし、自分のSIPクライアントで内線電話として受けるようにしています。若干遅延があるかもしれませんが、気になるほどではありません。ただし、内線の設定としてaudio bypassを指定しています。つまり、SIPで2点間の接続が成立した後のメディア通信はPBXを介さず2点間で直接行うようになっているはずです。これが私の考えているように実際起こっているのであれば、一旦繋がればそれ以降直接ブラステル等にSIPクライントで接続する場合と差はないはずです。

Asterisk sip canreinvite Asteriskでring groupにコールとrouteしていると、Asteriskがずっと介在するから。確かに、自分はring groupにrouteしていた!といわけで一内線単独にrouteするようにすることで、media bypassができるようになった(Wiresharkでパケットキャプチャして確認)。 FreeSWITCH

受信に関しては、NATがらみのICE, STUNのあるなしに関わらず、Fusionならmedia bypassが起こり、ブラステルでは起こらない。

発信に関しては、ブラステルしか試していないがmedia bypassは起こらない。ところが、テスト用の通話を終えた後、ブラステルから発信元にINVITEが来ることがある。これはひょっとすると、media bypassのためのものがひどく遅れてきているのではないだろうか?

PBXesでは、以前は同じ内線に複数のSIPクライアントが登録でき、その内線宛の通話を受信した際には、全ての端末が鳴動していたように記憶しているが、少なくとも今は最後のクライアントのみが鳴動するようになったようだ。そういう動作仕様ならring groupが有用な状況はあるかと思うが、自分の現状ではさしあたって必要ないのでこれでよしとする。

OpenWrtにSleekXMPPをインストール

Finding An XMPP/Jabber Client or Library That Can Be Used in Scripts“で自分の要件に合致するXMPP/JabberのライブラリはSleekXMPPぐらいしかない、ということがわかったので、OpenWrtルーターにインストールしてみることにした。

ちなみに、SleekXMPPはPythonライブラリであるが、自分にはPythonの知識・経験がないに等しい。

Pipなるシステムを利用してあっさりインストールできるようなのだが、そのPipのインストールからはじめなければならない。”Installation — pip 1.5.6 documentation“を参照。

既にちょっと記憶が曖昧なのだが、以下の問題にぶち当たって、そこにある解決方法で回避した…ように思う。”Does curl have a –no-check-certificate option like wget? – Unix & Linux Stack Exchange

$ echo insecure >> ~/.curlrc

ところがインストールの最中に落ちてしまう。”#12629 (“opkg list” prints “Killed” after “opkg update”) – OpenWrt“にあるように、噂には聞いていたOOM killerが発動してしまった模様。

USBメモリでswapを追加してなんとか乗り切った。

パッケージlibpyexpatもOpenWrtのopkgで別途インストールしなくてはならなかったように思う。

Androidアプリからの通知を自分好みにカスタマイズする

Androidアプリからの通知を自分好みにカスタマイズしたい。通知方法は基本的にアプリに任されていて、アプリ内でカスタマイズができるようになっていることがあるが、全てのアプリでそうなっているわけではないし、用意されているカスタマイズ方法が自分のニーズにマッチしていないことがある。

具体的に想定しているのはSMS受信。これを画面がロックされている状態でも、はっきりポップアップ・ウィンドウで内容まで表示して欲しい。

その手のアプリはいろいろあるが、「画面がロックされている状態でも通知」という条件を満たすものがなかなかない。Popup Notifier Freeはその要件を満たす。アクセシビリティ・サービスを利用して動作するので、SMS以外の一般アプリにも対応できる。何か他のことにも利用できるかも。

ただ、例えばSMS受信であれば、特定の送信者のものだけをポップアップ通知する、といった細かい指定はできない。同じ著者によるPopup Notifier (有償版)NotifierPro(二者の関係はわからない)でもそれはできない模様。

Taskerでもアクセシビリティ・サービスから通知を受けることができるようだから、例えば特定の発信者からのメッセージ/SMSのみポップアップさせたいのなら、頑張れば実現できるだろう。想定しているSMSの内容は、電話番号なのだが、どうせTaskerを使うのであれば、単にそれをそのまま表示するのではなく、住所録を引いてマッチがあれば、その番号の持ち主の名前も合わせて表示することもできるであろう。

ただ、画面がロックされている状態でもできるのかはわからない。ただ、以下のビデオを見る限り可能なようだ。Androidのバージョンによってはできない、というのもどこかで読んだが、自分のメイン端末のAndroidのバージョンはICSで、Jelly BeanでもKitKatでもLollipopでもないので、その問題はないと期待したい。

EZCastの設置を試みた

例によってこの記事は三ヶ月以上前に書きかけてたままになっていたもの。そのため内容は最新ではないのでご注意を。

ちなみに、内容的にこの記事の前編となる”EZCastが届いた“は、コンスタントにこのブログで最も読まれている記事となっている。EZCastって密かに人気があるのかしら。


Micro USB延長ケーブルを使った配線

Micro USB延長ケーブルを使った配線

EZCastというChromecastもどきに興味を持って、注文してみた。自宅でテストしてみた後、本来想定していた設置場所に行って設置してみた。

が、液晶テレビがあまりに大きいため、付属のUSBケーブルでは直接USB ACアダプタとEZCastデバイスを繋げられない。そこで、たまたま立ち寄ったセリアという百均ショップで売っていた「micro USB延長ケーブル」を間に挟んでみた。

写真にあるようにパッケージには全くそのようなことは書かれていないが、これは充電用のようだ。短い充電ケーブルを長く使いやすく Micro USB 延長ケーブル (長さ約1m)と同じもののよう。データ通信には対応していないため、EZCastは動作しなかった。EZCastデバイスに付属の二股USBケーブルはwifiアンテナも兼ねているため、これら間にはデータ通信ができる必要がある。

Micro USB延長ケーブルパッケージ(表)

Micro USB延長ケーブルパッケージ(表)

Micro USB延長ケーブルパッケージ(裏)

Micro USB延長ケーブルパッケージ(裏)

仕切り直しで改めて対応策を考えたが、(データ通信に対応している)micro USBの延長ケーブルを使う、あるいは、HDMI延長ケーブルを使う、の二通りの方法が考えられる。

EZCastデバイス本体が結構熱を持つので、本来はHDMIケーブルを使ってEZCastデバイスは液晶テレビ筐体の外にでるようにして冷却に配慮するほうが正解だろう(後継モデルでは筐体に排熱孔がつけられた)。だが、一般人にとってはそういう性能上の配慮より、見目の方が大事だったりする。

EZCastにmicro USB延長ケーブルを挿してみる

EZCastにmicro USB延長ケーブルを挿してみる

なので、カモン 【(COMON)製】USB2.0(MicroB)延長ケーブル(オス←→メス)/黒/1m【MBE-10】を購入し、これを利用することにした。右の写真はTVの背面カバーを外した状態を示す。激しくわかりづらいと思うが、黄色の線に沿ってあるのがmicro USB延長ケーブル。それに繋がって下に垂れているのが、EZCastデバイスに付属の二股USBケーブル。一端は台の上にある個別スイッチ付きUSBハブに繋がっており、もう一端のwifiアンテナはだらんとぶら下がっている(赤線で囲ってある)。青矢印の先にあるのは、本題とは関係ないが、TVの音声を離れたBluetoothスピーカーに飛ばすためのBluetooth送信機。

EZCastが届いた」の初出時、「ただ、それでもwifiのAPを替えなければならない、というのはいただけない」と書いていたが、これは自分の誤解で、iOSデバイスとAirPlayを介して利用する際には、最初のセットアップ時以外直接iOSデバイスからEZCastにwifi接続する必要はない。それぞれがルーターにwifi接続し、ルーターを介して間接的に接続する形態で利用できる。

iOS上のGoogle謹製YouTubeアプリでは以前はAirPlay機能を利用してEZCastデバイスで動画を表示できたのだが、なぜか今はできない。”Bad URI request”のようなエラーがEZCast側では表示される。

考えられる理由はEZCastのファームウェア・アップグレードか、YouTubeアプリのアップデートによる非互換性の発生。前者については、後で入手した多数のEZCastデバイスにインストールされていた古いファームウェア(ただし最初の1台でうまくいったときのバージョンと同じかどうかは不明)でも同じ症状が出ることで原因とは考えにくい。一方、サードパーティーによるYouTube閲覧アプリ、例えばTubePlayerというアプリ、では、自分がテストできる範囲でのEZCastのファームウェアのバージョンに関係なく、問題なくAirPlay再生が可能であることから、Google謹製YouTubeアプリのアップデートによる非互換性の発生が原因と思われる。ただ、EZCastのフォーラムでも同じ症状を訴えていると思われる人達がいるのだが、これがYouTubeアプリの最新のアップデートより古い時点の話もあるようなので、そこは理解できない。同じように見える別の問題かもしれない。いずれにせよフォーラムでこの問題を報告しておいた。早く解決が図られることを望みたい。

設定画面が出ている状態ではAirPlayやDLNAの通信は全く受け付けない模様。

AndroidのEZCastアプリでは、何の設定もせずにEZCastデバイスに接続できてしまう。これはつまりSSIDから何らかの計算式でそのwifiパスワードを得ることができる、ということを示しているように思う。パスワードをEZCastデバイス側で変更できたように思うのだが、確信がない。

AirPlayで複数デバイスから同じEZCastデバイスにメディア再生を指示した場合、最初のリクエストだけが通り、後のものは無視されるか、ブロックされる模様。


↑を書いたのはかなり前なので、その後のファームウェア、アプリの更新によって仕様や機能が変わっていることにご注意を。

Finding An XMPP/Jabber Client or Library That Can Be Used in Scripts

I have been trying to find a command-line XMPP/Jabber client for the Linux platform that can be called from scripts. More specifically, I want to run it on OpenWrt, which poses a unique challenge; unless its pre-compiled binary is provided from its repository, it is hard to build it on your own because you will have to cross-compile it on a Linux box.

My primary objective is to use it so I can exchange information with my OpenWrt router by way of Google Hangouts. One requirement is that it support embedded images. This seems to mean in the XMPP world that the extension “XEP-0231: Bits of Binary” is supported.

I know Xmpp client written in bash / ash (openwrt). It’s only dependency is ncat (or similar) for the actual ssl connection doesn’t support XEP-0231, but I gave it a shot anyway. I thought even if it doesn’t support XEP-0231, I could get away with a simple approach described in “How can I send an image on the web in an XMPP (Jabber) message?

The system simply didn’t work on my OpenWrt router, unfortunately. I did not bother trying to investigate why it was not working, because it does not support XEP-0231 anyway.

Matthew Wild publishes his projects related to Lua and XMPP, which include the Verse XMPP library for Lua and the Riddim Verse-based bot framework. Verse unfortunately does not support XEP-0231. Perhaps you could implement it relatively easily, but I have no idea at this point.

SleekXMPP Python XMPP library is the only package that I found that supports XEP-0231. “Supported XEPs” says otherwise, but I confirmed that it is included in the stable 1.3.1 version. I have also found a sample code to send an image in a chat message with SleekXMPP. Installing SleekXMPP on my OpenWrt router was a lot of work, though.

Hangups is a very young Python library to access Google Hangouts.

By the way, I run Asterisk with its XMPP/Jabber support enabled. If there was an XMPP/Jabber equivalent of the SMSq command, I would have used it, but no such luck. You could access your Asterisk instance using its AMI or AGI interfaces and have it take care of your XMPP/Jabber needs. But I decided against it because working with the AMI or AGI interfaces seemed like an overkill; plus Asterisk would not be able to handle embedded images.

RDPを利用したリモート・デスクトップ

リモートデスクトップソフトウェアの選定“から外した、MicrosoftのRemote Desktop Protocolを利用したものをここにまとめる。といっても雑多な情報の寄せ集め。

Jump Desktop (RDP & VNC) – Android Apps on Google Play 1,020円の有償ソフトだが、Amazon.comのキャンペーンで無料で入手していた。RDPに関してaudio streamingをサポートしていると明示的に謳っている。

Microsoft Remote Desktop – Android Apps on Google Play

Remote Desktop Services – Wikipedia, the free encyclopedia

リモート デスクトップ接続のFAQによれば:

  • リモート デスクトップを使用して、すべてのエディションの Windows 7 から接続を開始できます。

ものの、

  • リモート デスクトップ接続を使用して、Windows 7 Starter、Windows 7 Home Basic、または Windows 7 Home Premium を実行しているコンピューターに接続することはできません。

なんだそうな。

リモート デスクトップ接続と Windows リモート アシスタンスの違いとは

How To Enable Remote Desktop On Windows 7 Home Premium – YouTube“は.dllを置き換えるように思われる。そのためアップデートによりそれが上書きされると駄目になる。出どころのはっきりしないものを使用するのはためらわれる。

Concurrent RDP Patcher Enables Remote Desktop in Windows 7 Home Premium • Raymond.CC” “Win7+Concurrent RDP PatchとUbuntu-Remmina(RDP Client): 白鳥は鳥にあらず Swan∩Bird=false 再開

Enable remote desktop on Windows 8 core / basic | Andrew Block .net” “RDP Wrapper Library by Stas’M (update 2014.07.26) – Программы – Каталог файлов – Stas’M Corp.” “RDP Wrapper works as A Layer Between Service Control Manager and Terminal Services, so the original TERMSRV. dll file remains untouched. Also this Method is very strong Against Windows Update” ソースファイルも同梱されている。RDP Patcherではパスワードを設定していないアカウントにログオンすることも可能にすることができるが、RDP Wrapper Libraryではそのようなオプションはない。

オーディオ再生できない。”Windows 7 でオーディオ録音リダイレクトを構成します。“で紹介されているレジストリをいじることでなんとかならないかと期待したがダメだった。

Windows7 gpedit 使い方 – NAVER まとめ

How to Enable “Group Policy Editor” (gpedit.msc) in Windows 7 Home Premium, Home Basic and Starter Editions? – AskVG

Allow Remote Desktop connections from outside your home network

 

FreeRDP – Wikipedia, the free encyclopediaFreeRDP RDPクライアント Remmina – The GTK+ Remote Desktop Client

xrdpのインストール後、LubuntuのGUI画面でログインできなくなった。”ubuntu – Can’t login to Lubuntu 13.10 – Stack Overflow

xrdpUsing Windows RDP to Access your Ubuntu Instance | Cloud Services” “xrdp pulseaudio sink and source“なんて記事があるところをみるとデフォルトでは音の送信はサポートされてない模様。”Get audio with your xrdp/x11rdp connections, LAN or Remote! Updated! Windows Clients! – Scarygliders” Windowsホスト側にPulseaudioをインストールして実現する方法。大変そう。

Allow Remote Desktop connections from outside your home network

 

リモートデスクトップソフトウェアの選定

これまた原稿を書いたのは随分昔。


リモートデスクトップソフトウェアの選定をした。要件は以下の通り:

  • Windows, Linux (具体的にはLubuntu)、Android OSの機器の間で。iOSがこの中に含まれていないことに注意。
  • 画面だけではなく音も。
  • 必須ではないがLAN内だけではなくWAN超えもできるのが望ましい。

いきなり結論だが、Team ViewerはWAN超えもでき、商用利用でなければ使用は無料。iOSデバイスを含むモバイルプラットフォームもサポートしており、音の遠隔再生にも対応。動画の再生なんかも用途として最初は想定していたのでそういう目的に最適化が行われているのを当初探したが、実際にはそういう用途に使うことはないということがわかり、欠点らしい欠点がないこれに決定。各種プラットフォームでこれ1つに統一できるのはありがたい。

フルバージョン以外に、Quick Supportといわれる亜種も用意してあり、これはインストールの手間が少ないようになっているため、何らかの理由で他人のデバイスを急にアクセスしなければいけないようなときには便利。そういう無料ヘルプデスクみたいなことはしたくないんだが実際にはやらなえればならないことがある。

Android版にはフルバージョン、Quick Supportがあるのに加え、デバイスモデルに応じたプラグインもあるので注意。

これで自分としてはもう「終了」なんだが、せっかく調べたことを以下に記す。

のっけからあれだが、MicrosoftのRemote Desktop Protocolを利用したものは別記事にまとめる

Ichigeki氏はリモートデスクトップのアプリケーション・ソフトウェアを各種公開しているが、WindowsとiOS以外のプラットフォームは現在サポートしてないようなので選から外れる。

VNCがスタンダードだが音がサポートされない。

(この段落内容が古いかも。ご注意を)Splashtop Personalはそもそも被アクセス側としてはMacとPCしかサポートしていないから選から外れる。 Linux版はそもそもベータ版という位置づけだが、Lubuntuの最新版の14.04に対応していない。古いUbuntu用をインストールしようとしたらlibx264-123という依存性が解決されないとしてインストールできなかった。Synapticによるとlibx264-142が最初からインストールされているのだが…。 Ubuntu App Storeなるところからもインストールできるとされているが、14.04用は存在しないようだった。

Mirror-DTC Home PageはUbuntu 14.04 LTSに対応していると明記している。

【レビュー】GUIに特化した独自コーデックを搭載。高速なリモートデスクトップツール「AnyDesk」 – 窓の杜