ラベル Linux の投稿を表示しています。 すべての投稿を表示
ラベル Linux の投稿を表示しています。 すべての投稿を表示

2022年6月20日月曜日

C++で常微分方程式を解く方法

私はラグランジュ方程式による二重振り子の計算(たぶん)という常微分方程式をPythonのscipyのsolve_ivpやodeintで解いていましたが、もう少し速度がほしいと考えました。

 

そのため、コンパイル型の言語で常微分方程式を解くことができるライブラリを探していました。

 

そこでC++でBoostのOdeintを用いました。

しかしながら、BoostのOdeintではダメでした。

そこで、ODE-Solverを探したところ、「heyoka」に出会いました。


heyoka


 テイラー展開を手法としては用いているようで、一般的に聞く、オイラーやルンゲクッタ法ではないようです。


このライブラリを使うのに個人的には苦労したので、インストールから実際にプログラムを書くまでを記しておこうかと思います。


  1. インストール

    実行環境は以下の通りとなります。
    • Linux:Pop!_OS 22.04LTS(Debian系Ubuntu派生ディストリビューション)
    • gcc:11.2.0
    • Boost:1.74
    • {fmt}:8.1.1
    • LLVM:12~14
    • spdlog:1.9.2
    • TBB:2021.5.0-7

    これらのインストールは
    「apt install libfmt-dev libspdlog-dev libtbb-dev libboost-serialization-dev clang-13 lldb-13 lld-13」
    としておけば、問題ないかと思われます。
    その後、「git clone https://github.com/bluescarni/heyoka.git」 を実行し、githubからリポジトリをクローンしましょう。
    そして、そのリポジトリのディレクトリに移動し、「cmake .」 を実行し、cmakeの準備をしましょう。
    そして、ライブラリとしてインストールするならば、「cmake --build . --target install」と実行しましょう。

  2. プログラムの実行

    適当にプログラムを書きましょう。
    以下は公式にあるサンプルです。(As a simple example, consider the ODE system corresponding to the pendulum)
    single_pendulum.cppと命名。

    #include <iostream>
    
    #include <heyoka/heyoka.hpp>
    
    using namespace heyoka;
    
    int main()
    {
        // Create the symbolic variables x and v.
        auto [x, v] = make_vars("x", "v");
    
        // Create the integrator object
        // in double precision.
        auto ta = taylor_adaptive <double> {// Definition of the ODE system:
                                          // x' = v
                                          // v' = -9.8 * sin(x)
                                          {prime(x) = v, prime(v) = -9.8 * sin(x)},
                                          // Initial conditions
                                          // for x and v.
                                          {0.05, 0.025}};
    
        // Integrate for 10 time units.
        ta.propagate_for(10.);
    
        // Print the state vector.
        std::cout << "x(10) = " << ta.get_state()[0] << '\n';
        std::cout << "v(10) = " << ta.get_state()[1] << '\n';
    }
      

    これを
    g++ simple_pendulum.cpp -o single_pendulum.out -lheyoka
    と実行。
    こうすると実行ファイルが生成されます。
     

    まとめ

    今日触ってみた限りでは、あまり高速だとは感じませんでしたし、Pythonとくらべても0.07sしか差がありませんでした。
    しかしながら、バッチ化やもっと正しい時間の進め方があるようなので、もっと高速になるかと思います。
    また、Boostのライブラリでは得られなかった正しい解を得ることができたので、満足です。

2022年1月22日土曜日

ZFSで沼にはまって、データ移行の際にデータをロスト仕掛けた話

こんにちは、白虎21です。

皆さんは ファイルサーバを立てているでしょうか?

ご自身の手でファイルサーバを建てるなら、OSの候補に上がるのがLinuxかBSDだと思います。

その中で私はdebianを選択しました。


1.ファイルシステムとRAIDシステムの選定

それではファイルシステム(FS)は何が良いでしょうか?

Linuxだとext2,3,4やXFS,BtrFS,etc...たくさんあります。

ファイルサーバとなるとRAID組みたくなりますよね?

ただ、RAIDと聞くと、私の中では、構築が難しそうだったり、復旧が難しそうだったりと思う点がありました。そして、システムに一貫性がないと感じました。

細かいRAIDの話はArchLinuxのwikiに任せるのが一番だと思いますので、おいておきます→RAID - ArchWiki


上の憂慮した点を解消してくれるのがBtrFSとZFSでした。

私がファイルサーバを構築した際にBtrFSは当時事情があり、

「ZFSはライセンスが扱いにくいが、個人が使う分には大きく気にしなくてもよいだろう、それよりもBtrFSの技術的に問題がある方が問題である」と感じ、ZFSを選定しました。

 

2.ZFSのメリット

ZFSは簡単にストレージ(?)を作れます。

ZFSではストレージプールといいます。

これは作るのが非常に簡単です。

例えばHDD1,HDD2をつないだとします。

そうすると、

sudo zpool create tank HDD1 HDD2

でRAID 0のプールが作成されます。

もしも、RAID 1で作成したいのであれば、

sudo zpool create tank mirror HDD1 HDD2

でRAID 1のプールが作成されます。

ただ、要注意すべき点として、 HDD1やHDD2の表記に/dev/sdaなどのSATA指した順で変わるような指定の仕方はマウントの失敗などを招くため推奨されません。

/dev/disk/by-id/ata-*などのデバイスIDでの指定をおすすめします。

その他知りたい情報があれば、ArchLinuxのwikiに任せるのが一番だと思いますので、おいておきます→ZFS -ArchWiki

 

また、snapshotを取ることができます。

その他のメリットとして、Oracleと富士通の資料が充実しています。普通に扱う分には困らないでしょう()→ OracleのZFSの資料

 

3.ZFSの落とし穴

ZFSをLinuxで使うにはzfs-fuseとzfsutils-linuxがあります。

ubuntuなどで後者を使いましょう。

zfs-fuseで書かれている資料を私は見た記憶がありません。

debianは安定性を重視するので、後述するOpenIndianaやubuntuにバージョンで遅れを取っています。

特にzfs-fuseは0.70と大きく遅れを取っています。

zfsutils-linuxはdebianでも最低限2.0になっています。

システム的に今後はzfsutils-linuxしか更新されないと思うので、こちらを今後は使うようにしましょう。

 

4.ZFSでのデータ移行の失敗

私は安直に既存のプールに新しいHDDをmirrorでattachしました。

これはRAID0に当たります。

私の環境下では、つけたものは外せません。

その次に、ゴニョゴニョいじって、新しいHDDだけにして、zpoolをcreateして、古いプールからimportしました。

もとのプールにはアクセスできなくなりました。古いHDDには前のzpoolの情報が残っています。

 

mirror -

    4TBのやつ

    4TBのやつ

mirror - 

    8TBのやつ

    8TBのやつ


という情報が。

このプールの状況が

mirror -     UNAVAIL

    4TBのやつ    ONLINE

    4TBのやつ    UNAVAIL

mirror -     UNAVAIL

    8TBのやつ    UNAVAIL

    8TBのやつ    UNAVAIL


でした。

debianの環境では詰みました。

高っかいリカバリソフトは諦めました。


5.どのように復旧したか

極論、ググりました。

このサイトを参考にしました→ Turbocharging ZFS Data Recovery

ググった結果、ZFSの大元であるOracleのSolarisのOSS版のOpenSolarisの後継のOpenIndianaを用いて、最新のZFSが使える環境にして、ZFSが読み込めるか確かめました。

以下のコマンドはubuntuでは不可能でした、OpenIndianaを用いました。

zdb -dep /files -G datapool

→このコマンドで最後が「LOADED」になればOKです。

zpool import -f -d /files -o readonly=on datapool

→このコマンドで読み取りのみが可能になります。

 

 6.ZFSの移行方法

私が次、HDDの増設に失敗しないためのメモです。

ドキュメントから生成されているので必ずしも成功するとは限りません。

バックアップは取っておきましょう。

今回はnewHDD1とnewHDD2のRAID1へ移行します。

まず、新しいプールを作成します。

zpool create New_Pool mirror newHDD1 newHDD2

その後、そのプールにsend&receiveします。

zfs send Old_Pool|zfs recv New_Pool

その後、古いプールをepoxrtし、新しいものを好きな名前に変えます。

zpool export Old_Pool

zfs rename New_Pool What_You_Like_Name_Pool

 

7.その他参考資料

https://chibiegg.gitbooks.io/how-to-zfs/content/

https://ostanin.org/2013/06/14/importing-a-freebsd-zfs-pool-in-illumos/ 

2021年2月7日日曜日

Pine64のGPIO系の備忘録

まず、初めにPine64はRasberryPiと同じGPIOピンを持ったシングルボードコンピュータです。 

つまり、RasberryPiの互換品です。 

そのため、次のようなファイルのピンアサインをされています。

pine64ピンアサイン 

 

ピンアサインなどの細かい情報は次のサイトを参考にしました。

PINE64のGPIOでLEDを点灯させる 


私の場合、リレースイッチを使いたかったため以下のような配線とシェルスクリプトを書きました。

 


#!/bin/sh

cd /sys/class/gpio
echo 32 > export
cd gpio32
pwd
sleep 3
echo "out" > direction
echo Wake on Lan.
sleep 0.5
echo "in" > direction


リレーの参考にしたサイトは次のサイトです。

SODIALの送料込み143円の激安リレーユニットをRaspberry Piで利用成功(2016年の物欲その36)

 

2020年1月25日土曜日

Linuxでgoogle chrome remote desktop serviceを利用する備忘録

一言、私自身Linuxとwindowsを用いて開発を行うのですが、VNC入れるのはめんどくさいとかsshとかipをstaticにしてないからめんどいとかでchromeのリモートデスクトップを選びました、一部環境はうまく行かないと思います。

本題 

Compute Engine での Chrome リモート デスクトップのセットアップ

おわり

 

 では、忘れそうなので、詳細。
まず、google chromeをインストール。
地味に、googleのchromeでなければならない。
google以外のchromeってなんなのと言われると、おおよそは元のchromium。
chromiumはaptやsnap、zypperでインストールできるOSSのブラウザ。
以前インストールしたときはブラウザ単体の機能としては動くが、リモートデスクトップは駄目でした。
windowsで昔したときも同じく駄目でした、32bitしかない時代だったからかもしれない。
今は知らない。知りたい方は試してみてください。

google chromeはググれば出る。Google Chrome
しかしながら、全てターミナルから可能であり、Debianで行う際は
wget -c https://dl.google.com/linux/direct/chrome-remote-desktop_current_amd64.deb

curl  -O 

https://dl.google.com/linux/direct/chrome-remote-desktop_current_amd64.deb
とターミナルに打ち込み、カレントディレクトリにダウンロードする。
apt install ./
chrome-remote-desktop_current_amd64.deb &&
apt update
とchromeのインストールとアップデートを行う。
この際エラーが出たときは権限がないため、aptの前にsudoをつける、rootになるなど権限を与える。
依存関係によるエラーでは
apt install -f
 と入力する、同上に権限が必須。

chromeのインストールが終われば、ほぼおしまいです。
後はこのサイトにアクセスして、手順を進めるだけです。

注意としては.chrome-remote-desktopはあえて作らないほうが良いかもしれません。
また、Debian 10 LXQT環境下では表示のバグが有るため、xfceやcinnamon、mateが好ましいかと思います。

他にも記事が多くありましたが、私の環境下では駄目でした。

2019年9月23日月曜日

コンピュータのセキュリティとサポート

Windows7サポート終了でどうなるのウソ、継続利用、使い続ける
https://www.gwtcenter.com/end-of-windows7-support-lies

話題になった話です、危険極まりない、素人に誤解させるのは駄目。

最初に
NECとPC工房、マイクロソフトのを見たほうが反論としては速いかと思います。
https://www.nec-nexs.com/sl/security/it/18.html
https://www.pc-koubou.jp/magazine/17303
https://support.microsoft.com/ja-jp/help/4057281

本文について、順に個人的に思ったことを書いていこうかと思います。

1. 何が危険になるのかの原理説明が無い
2.危険性を煽るギョーカイの試み
後で言うので、パス。ただ、メーカの言いなりになるのは嫌いなのはわかる。
個人的に日本のPCはボッタクリですし、リース品でクソみたいなものを使っているの見たことあって信用はないといえばないとも言えます。

3. 業務用パソコンは全く危険ではない
まず、サポートが切れたOSのマシンはかなり危険。
ネットに繋がなければウイルスが侵入しないなんてことはない。
外部記憶媒体、USBやHDDから、自動で起動するやつとかで入り込めますし、wordなどのマクロにも仕込めます。
これに関しては、最近ではセキュリティの見直しで、あまり見ないものかと多分思いますが、何かしらのセキュリティホールを誰かが見つけてやるでしょう。
その際にサポート切れのものは基本何もしてくれません。
有名なWannaCryは普通にセキュリティ対策していれば防げたはずなのです。
SMBv1の無効化、サポート中のマシンは更新で対策されました。
そして、ネットに繋がなかればという前提で、LANにつなぐな。

4.ネットに接続しても全く危険ではない
いやだから、ネットに繋ぐなって。
その話は一度おいておいて、FireFoxはXP,Vistaのサポートを2018年にサポートを切って、セキュリティアップデートを終えました。
FireFoxは優しいと思われる団体でXPの終了4年後まで対応しました。
基本的にブラウザの脆弱性のアタックか自身のミスによるウイルスのダウンロードかと思いますが。
jpgとかに偽装してますからね。

5.ダウンロードしても全く危険ではない
基本的に実行を自動で阻止してくれますけど、大手は見切っているので、後手後手の対処になるかと思います。

6. ただし、標的型攻撃は、サポートがあろうがなかろうが無関係
よほどのものでない限りはアンチウイルスソフトやWindowsの更新で防げます。
大体は何かしらの脆弱性をついてますので。
大企業では別だと思いますので、元の投稿者さんという通り、「見知らぬ人からのメールを開いてそのプログラムを実行したりしないこと」。


7.まとめ
流石に買い替えていかないと、機械にはボロが出ます。
使い続けられるかもしれないですけど、快適ではないでしょう。
5年で買い換えるのが個人的にはベストかと思います。
そうでなくても、HDDからSSDへ変える。DRAMを多く(4GB以上)積む、wifiカードを変えるなどしたほうが良いです。
Sandy世代から買換えで快適に、最新 vs 旧型ガチンコ勝負 マザーボード編

「sandyおじさん」でググると面白い記事がでましたw
url貼り付けるのもブログ先では連絡欲しいみたいな感じですたので貼り付けませんが、なかなかに面白い内容でした。

8.最後に
製造業などで旧式のwindowsを使っている方は特殊な機器でドライバなどに問題が発生する可能性があると思います。
独自のソフトウェアで動くかどうか怪しい場合は評価版でトライしてみてはいいかと思います。最大で270日は使えるはずですし。
ドライバなどの問題が実際に発生した場合はエンドポイントでネットに繋がないという選択肢(つまりCD-Rで特殊な機器とつないでいるマシンとデータをやり取りし、使い終わったらそのCD-Rは廃棄など)かドライバを新しいものに書き換えるように頼むかLinux向けに安定して動くようにするかくらいですね。

そして、個人的にPCを新たに買い替えたくないという方はLinuxという選択肢を提示します。
XPのときも話題になりましたね。
あのときはubuntuがお勧めされていましたが、私はあまりおすすめしません、もっさり感が強い。
企業さんが一括で使うのであれば、openSUSEかとおもいます。
癖のあるものだと思いますが、細かい設定さえ詳しい人がすれば、windowsよりも使いやすいかもしれません。
個人で使うのであれば、7でもちょっと重い方であればDebianDogなどの軽いものが良いかもしれません。ubuntuは地味に重い記憶
windowsライクなものであればZorinOSかChaletOS、Linux Mintあたりが良いかもしれません。
おすすめとしてはdebian派生やubuntu派生というのがおすすめです。


PCに詳しいけど、windows10は面白みがないなぁという方はArchLinuxが良いかと思います。

2019年5月18日土曜日

dockerにてsteamを動かす方法のメモ

タイトル通り、メモ的なところであって、正しく動くとは限りません
また、今回のミソというべきところはDockerFileというよりもdockerを起動するためのコマンドラインかもしれません。
This is a memorandum running steam on docker,so may not run correctly.
And this article is treated command line to run docker option mainly,not DockerFile.

まず、基本となるDockerFile
FROM ubuntu:18.04
RUN cat /etc/resolv.conf
RUN sed -i.bak -e "s%http://archive.ubuntu.com/ubuntu/%http://ftp.jaist.ac.jp/pub/Linux/ubuntu/%g" /etc/apt/sources.list
RUN cat /etc/apt/sources.list
RUN apt-get update && apt-get install -y zenity wget
# add the sources.list stuff that steam will at first start
RUN wget http://repo.steamstatic.com/steam/archive/precise/steam_latest.deb
RUN apt install -y python-minimal curl xterm gnome-terminal konsole python-apt
RUN dpkg -i *.deb
RUN dpkg --add-architecture i386
# let's head off a few of the things steam will want to install immediately
RUN apt-get update && \
apt-get install -yq \
libgl1-mesa-dri:i386 \
libgl1-mesa-glx:i386 \
libc6:i386
# steam itself needs to be able to install things, and it uses "sudo" for that
RUN apt-get install -yq sudo
RUN echo 'steam ALL = NOPASSWD: ALL' > /etc/sudoers.d/steam && chmod 0440 /etc/sudoers.d/steam
RUN adduser --disabled-password --gecos 'Steam' steam && \
adduser steam video
USER steam
ENV HOME /home/steam
VOLUME /home/steam
CMD /bin/bash

イメージを作るコマンドライン
docker build -t steam .
コンテナを作るコマンドライン
docker run --name steam --privileged -e DISPLAY=${DISPLAY} -v /tmp/.X11-unix:/tmp/.X11-unix -it steam bash
コンテナを起動し入るコマンドライン
docker start steam && docker exec --privileged -e DISPLAY=${DISPLAY} -it steam bash

ずら~っと並べましたが、DockerFile はtianon氏のを参考にしました。
ぶっちゃけよくよく見ると他のが必要になっているというオチでした。
dockerhubにたくさん上がってますが、個人的な備忘録なので、クオリティはお察しです。

んで、具体的に何しているのか何に応用できるのかという話が、大事だと思います。

DockerFileでは
まず、imageを決めています、ここは有名なubuntu、:以降はlatestでも何でもお好きに。
そして、謎のパッケージダウンロードができないエラーを修正、。クソ、ネイティブな構築でも遭遇する。
aptで更新と必要なものを入れます。zenityはGUIとCLIの架け橋らしいです。
wgetにてsteamのdebをゲット。
steamに必要らしいものをインストール。
steamをインストール。
ドライバ関係とsudoをインストール。
これ以降はuserを追加しているものになります。
最後の部分が違うのは何かしらのエラー対策です。

一部足りないものが(たぶん)あってprotonは走りません、根本的な問題かも知れません。

コマンドラインは、コンテナを作る部分だけ注意してください。
x11の共有をしていないときちんと動きません。

応用に対しては何かしらのGUIやGLを用いたいけど、環境を汚したくないときに役に立ちます。 
古いものを入れたりだとか大量にいろいろあって競合が怖いときに役に立ちます。

2018年10月26日金曜日

「Ray Tracing in One Weekend」をやってみて

最近レイトレやc++、OpenGLなどを触り始めました。
今回はPeter Shirley氏のRay Tracing in One Weekendについて書いていこうかと思います。
日本語訳はここ
githubはここ
pdfをココ最近配布されたのですが、url忘れました。
*2019/3/10追記
pdfは ここ

技術的な解説は他の方がたくさんされていらっしゃって、非常にわかりやすいので、
レイトレ自体の解説は省き、環境構築、注意事項についてのお話です。

 

環境構築について

私はDebianで開発しています。
理由は以下のとおりです。
1.Linuxは開発環境としてぶっ壊しと再生が楽
2.VisualStudioが重すぎてヤダ
3.他の開発を考えるとクソ楽
の3つです。

1と3は似たような感じなのでまとめますが、私はEmacsをプログラミングをする際に使っています。また、freeglutやglfwを触ったりもしています。そして、gitを頻繁に使っています。
Windows環境下ですとソフトウェアのダウンロードがめんどくさいからです。
今回では特別なライブラリが必要ではないのですが、最低必要なエディタにコンパイラ、gitをインストールするはめになります。

2ですが、私の環境におけるEmacs、g++、gdbなどなどその他諸々を制覇した素晴らしいIDEです。ですが、その分重い。後、Windowsでしか起動できないはず。
叩いて3sくらいで開かないとやる気なくしてしまうところがあるからです。
*2019/3/10追記
ウィンドウにツリーとか表示して邪魔。
自動で{}を縮めてくれるのはいいんですけど。
コード一気にみたい。

注意事項

私自身あるあるでググったら出てくるオチなのですが、 Chapter8でsphere.hのclassにmaterial *mat_ptrを入れなければなりません。
後、MAXFLOATでダメならば、FLT_MAXにすると走ります。

感想

多分ほぼ初めてc++とレイトレを触ったのに近い感じの私ですが、レイトレはどのように実装されて、c++でどのように書かれているのか少しわかりました。
この一冊では球体しか出すことができませんが、レイトレの基礎を触りだけ簡単に理解できる気がします。
CGの基礎をきちんと実装も含めて書いてあるので気になるなぁというお方はエディタとコンパイラさえあればできるのでされてみるのはいかがかなぁと思います。
macOSやLinuxをお使いの方は何もせずできると言っても過言ではないくらい依存ライブラリがありません。
今現在、私は床井教授が出されているOpenGLのをしているので先になると思うのですが、この次のものもチャレンジしてみようかと思うところです。

2018年1月28日日曜日

PINE64を買いまして。


まずはじめに、

今回はCG関係ありません。

ググってここに来たら、だいたい購入希望か困ったときの対処かと思います。

悩んだら 参考にしていただけると嬉しいですが、アドバイスは出来ません。

購入は こちら

購入を考えている方

・Android Stickなどで十分かどうか。
・目的が本当にそれで良いのか。(Raspberry PiやTinkerBoardなど他にもあります。)
・十分にトライできる根性と知識があるのか。
がこれを購入するにあたってどのマシンにするかの鍵ではないかと思います。

私の用途

・メインやサブが処理ぎりぎりになった場合のネットブラウザマシン
・環境をぶっつぶせる環境勉強用のマシンとして


結論から言うと「Arch Linux Debian ArchLinux入れるわ」です。(2018/1/28 31 2/28現在) 

何故かと言うと、ネットをするにあたって色々当たりましたが、オチがこれです。。
何故にそんなOSを選んだのかというと、勉強のためと普通にどれくらいできるのか知りたかったからです、めちゃくちゃ勉強になった気がしました()

外見は


という感じで約縦14cm、横7cmとミンティアサイズにまで押し込められたRaspberry Piと比べると少々大きいです。

スペックはARM Cortex-A53、Mali 400、DDR3、GbitEth、Raspberry Pi互換のGPIOピン(公式:PINE64.org)です。

んで、お値段は
PINE64 1GB本体 ¥2980
5V3A microUSB出力アダプター ¥700
microSDカード 16GB ¥1150
ワイヤレスキーボード&マウス ¥1822
Wifiアダプター (家にあった旧世代) ¥0
送料 ¥500
計 ¥7152でした。

なので、購入する用途が

・自宅へのVPNやSamba、CUPS、NginXなどを用いた常時起動でありつつも低パフォーマンスでもよいサーバ
・Linuxの練習機
・IoTのなんか(詳しくない)
・子供向けのマシン
・安くでTVに繋げれるマシン
といった点かと思います。
ですが、扱いが難しいので、本当の初心者はRaspberry Piの方がいいです。

ロボットなどの組み込みにおけるPINE64は

・ボード自体の大きさの問題
・積んでいるGPUが 画像処理に適していない問題
・wifiなどの無線規格が違法または合法のものは搭載すると大きくなる可能性がある問題
があるため普通にRaspberryPiを買うことをおすすめします。
コスパで画像処理以外の性能がほしいのであればありかもしれません。
ですが、基本aarch64というほぼサポートされていないCPUということをお忘れなく。

それ以外で

・本当に最低限で良くて、sshからでいいし、パワーそんなにいらない場合はNanoPi
・パワーが欲しいし、USB3.0ホストも欲しい、多少の不便は眼をつぶる場合はRock64
・安いx86_64の場合はLattepanda
かと思います。

私がこれについて困った点

まず、何故かddコマンドで出来ないという点です。
Debian Stretchという私の環境だけかもしれませんが 、ddもアクセサリにあるDiskからも出来ませんでした。
諦めて公式らしい焼くツール使いました→PINE64 Installer

そして、OpenSUSEを焼きました。
CLIから始まりました、GUIを入れようと画策します。
ググって「zypper in patterns-xfce」とか入れようとします。
ダメでした。
何度もググりまして、「pine64_config.sh」 で入れれることがわかりました。
「Problem occured during or after installation or removal of packages:
 Installation aborted by user.」って出ました。
これは「同じ名前のものがあるけど良いの~?」って聞いて自動でインストしている為勝手にNoと言ってキャンセルされるからです。
取り敢えず、viとかemacsとかでshの中身見て、必要なコマンドだけ持ってくる。
これで全部yesって答えて、ちゃんとコマンドが打てていればreboot後、GUIが出ます。

その後、wifiの有効化を図ろうとしましたが、デバイスマネージャーはないですし、ネットブラウザはない。おまけになんかzypperのGUIツールが動かない。

諦めました☆

ArchLinuxを焼きました、OpenSUSEが嘘かと思うほど全部そこそこすんなり行きました、GUIもwifiも 。
ですが、Firefoxを開くだけでも非常に固まる雰囲気がしましたし、タブちょっと開くだけですぐ1GBのRAMを使ってしまいました。
軽いoperaもaach64なのでダメでした。
また、ソフトウェアのインストールにあたってpacmanでインストールできるものとAURでインストールするものに分かれます。
そして、AURでインストールする場合はrootユーザではダメです。
普通はrootでしますからね、コメント読んでませんでした。



ここで諦めのDebianさんを使います。
使用してみるとあまり変わらない気がしました。RAMもCPUも全く使っていないのですが、フリーズする感じでした。
あまりうまく日本語環境が整っていないことを考えるとArchのほうが安定性があるように思います。
システムの容量を増やしたり、セキュリティを高めたりするためにwikiに書いてあるコマンドを忘れずに。

続いて、Androidも試しました。
起動の遅さとwifiアダプタのドライバがない(ググるとBeagleBoardで試した方のブログがありました、コンパイルすると行けるっぽいです)こと、物理ボタンとターミナルの都合によりシャットダウンが出来ないことにより断念。
以前x86_64マシンや仮想マシンでも試したことがあるのですが、 起動の遅さは全部同じです、スマフォのような常時起動をメインにしているためと考えます。

同じAndroid系列であるものの開発が終了しているRemixOSも試しました。
起動は遅くなく、シャットダウンがきちんと出来、Androidと違い、操作性は非常に良いです。
ですが、wifiが同じように対応していませんでした。
同じ使用目的で対応しているネットワークを使用するのであればありかと思います。
サポートはありませんが。

どうにでもなれとRaspberryPi向けのOSを焼こうかと思ったりしています。
Raspberry Pi3とはGPUの差以外は見受けにくいかと思います。

最後に

今回は制約上あまり良い印象ではありませんでしたが、どのOSも性能のあるマシンだと色々出来ますので、ありだと思います。
また、お遊びであったり組み込みであったりするとデバイスの仕様上、色々良いことが多いかと思います。
そして、今回は目的と合わなかったために使用しなかったOSがありますが、目的を考えるとx84_64では多分見かけないOSがあります。
FalconGateとか何それと思いましたが、 サイバーセキュリティ向けのOSでハッカーやマルウェアからデバイスを保護するものなんてありました。
1万円以下で構築できるコンピュータなので、興味があればお財布に手を突っ込んでみてはいかがかと思います。