Pixel3スキーがPixel5をレビュー

 毎回挨拶がこれで正直どうなんですか、と言う感じですが、あえて今回も「お久しぶり」。生存報告です。

 さて、TAMはPixel3ユーザ*でした*。ほんの3日程前まで。

 Pixel3ほんと気に入っていてPixel4シリーズもスルーキめたわけですが、まあ、直前まで使ってたのにある時いきなり動かなくなりました。その後電源入れ直そうと色々調べて試したのですが、どうも無理と言うことで、修理費用とかも調べた上でPixel5を注文しました。

 と、言うわけで、おそらく誰も望まない(そして遅い)Pixel5のレビューを今更したいと思います。イエア。

Continue reading “Pixel3スキーがPixel5をレビュー”

chinachuの話と見せかけてlxcの話

 お久しぶり(いつもの)。

 皆様テレワークは如何で御座いましょうか。俺はそう言うお仕事では無いので普通に出勤しておりますが、出来る限りの防衛手段をとっているとは言えなかなか難しいもので御座います。

 で。
 見るかどうかは置いといて「やっぱTVくらい見れるようにしとくかなー」的な感じで今回さっくりchinachu環境を組みました。「だからなんだ?」で終わってしまうくらいにはchinachuに関しては色んなところで手順が説明されておりますので、当たり前のように割愛させて頂き、今回は「lxcコンテナでchinachuを動かす」と言う話で表題通りlxcの話メインで。

Continue reading “chinachuの話と見せかけてlxcの話”

近況とPC組み換えた話

 よっ!(簡潔挨拶)。

 過去事例に違わず1年半程あいてしまいましたが、皆様お元気でしょうか。俺は全然元気ではありません、TAMでございます。

 なんで元気ではないかっつーと、9月の末あたりでしょうか。ちょっとバイクで事故しまして生まれてはじめての骨折、入院、手術を体験しまして、鎖骨をネジ止めされてる状態がしばらく続くわけで、これが痛いとかはもう無いんですけど動かすとすこぶる気持ち悪い。

 今回一人でこけてひとりで怪我したわけですけど、あれですねえ、バイクの場合しょうもない小さな事故でもダイレクトアタックですので怖いものです、身を以って知りましたよ。

 さておき。

 Sandyおじさんなんて揶揄される世代のPCを如何に駆逐するかと言うのは一つのテーマであったりしますが、「いやお前もSandyおじさんやん」だったわけでして、ようやくこの夏〜秋でメイン環境を一新しました。

 Ryzen7 3700Xでございます。巷でも評判の良いCPUですが、本当は3950Xまで待つ、いや伸びそうだから3900Xで手打ち?、みたいな方向で考えていたのですけど、まず3900Xは品薄でプレミア価格状態であほらしかったのと、いつ出るか分からない3950Xは待てないなあ、と言うことで8C16T、充分だろーって感じで3700Xで組んだわけです。その後3950X発表されたのですが「水冷推奨(公式)」と言うことでまあ、うん、この選択でよかったんじゃないかな?。

 んでまあSandy世代からの移行ですからCPU以外にもケース以外ほぼ全入れ替えになっちゃうわけですが、X570マザー、メモリもDDR3からDDR4になるし、ついでにHDDも3TBx2から8TBx1に、SSDもSATAからNVMeのものへ…と。しかしOSはそのままneonさんで。

 で、組み上げて実際使ってみた感想はと言いますと、うん、快適でございます。快適でございますが、i7-2600K環境と比較してどう?、と言われると、あちらも結構快適な環境にしてあったからなあ…。とまあ、これがSandyじじいが減らない理由だと思います。やれやれです。

 組んだちょっと後にRadeon RX480からRX5700XTに替えたのですが、こっちのがインパクトあったかなー。まあ、OpenCLとか使いたいならあまり向かないゲーム向けGPUではありますが、4KゲームやVRと考えるとこれくらいのGPU無いとあれかなーと言う感じではございます。

 まあ、CPUに関してはI社とA社がバトルしてくれることが良いのだろうと思います。今後が楽しみですねえ。

QtとWindowsと流川ガールズと

Qtと沙織さんのお話。

Creatorも含めてQtでコードを書くと言うのは基本的にプラットフォーム依存を少なく出来る、と言う利点があると思うのだけど、実際は書いてると結構出てくる。別件で書いてるOpenGL周りのコードもQt+Creatorを使っているけど、そりゃあもうね。

なのだけど、saoriに関しては当初から「できるだけQtに依存して同一コードを以って特定環境で動かないところを無くしてみよう」と考えて書いております。まあ、いつまでこれ続けられるかは謎ですけどねえ。
結果、実は現状同じコードでWindows上でも動きます。


素敵ですねえ。
まあandroidは素晴らしいクライアントが存在するから試す気も無いし、アポー系は宗教上の理由で試す環境が無いのでWindowsしか試してませんが、Windwos10のノートPCで出先で思いついた修正をさくっと出来て試せるのはそれだけでも素晴らしいし便利ですねえ。

とは言え、既に問題は見つかっていて、例えばWindowsでQNetworkReply::readAll()が空な場合がある、とかね。色々調べた結果どうも一定データ量を超えるとダメっぽくて、最終的に落ち着いたのが「タイムラインの取得量(limit=で指定するんですが)を若干小さくすることで回避」だったりします。内部バッファ量の違いかなーと思ったりもするんですが、このへんはQtのコード見てみないとなんとも。Windowsの場合OpenSSL周りも別個用意してたりするわけだったりするのでこの辺の差もあるのかも。

もうひとつはまりかけたのが、変数長の違い。
statusのidを保存するのに最初longを使ってたのだけど、どうもWindowsだとおかしくなる、結局qlonglongに落ち着いたのだけど、後で気になってlimit.h見てみたら、linux(64)だとlong=longlong、Windows(64)だとint=long、うおおおい!って感じ。難しい。

まあどこまで頑張れるかは分かりませんが、一応Windowsでもコンパイルして動かしてみてますよと言うお話。

Qtとmastodonと糞コードと流川ガールズと

お久しぶりどころか、あけましておめでとうですが、すっかり春めいてといいますかやや暑い日もあったりする梅雨前のひととき、皆様いかがお過ごしでしょうか。

えーとりあえずmastodonクライアントを昨年から作ってて本当は年末には見せびらかす予定だったんですけど、色々バタバタしまして気がつけばゴールデンウィークですよ。まあいいんですけど。
と言うわけで、機能足らなすぎで作りかけ感満載ですが、

沙織さんです。見ての通りマルチアカウント対応のMDIクライアント。名前の由来は特にありませんが、俺は流川ガールズが大好きです。

現状できることと言うのは本当に少なく、インスタンスに接続して一部タイムラインや通知を読み出すくらいです。Tootもまだ出来ませんし画面には機能しないボタンが並んでいたりしますが、まあmastodonにおけるごくごく基本的な「認証してアクセストークンをゲットしてJSONデータを得る」は実装されております。

コード化結構簡単ですので是非皆さんも手作りmastodonクライアント挑戦して欲しい感じですかねえ。まあ色々勉強になったところもあるので、何回かに分けてこのへん日記にまとめようかな。

以下、認証まわりのコード的な話。

twitterクライアントもそうなんだけど、ぶっちゃけアクセストークンを取得してAPIに正しくアクセスできれば後はデータをいじるだけ、mastodonはJSONでデータくれるのでQtのQJsonDocument他をごっそり使うことで手軽に得たデータを利用できます。素晴らしいですねえ。

ポイントはどうやって認証するのって話ですが、saoriでは

  1. Saoridonクラスでクライアント登録。
  2. SaoriAddAccountDialogで認証、アクセストークン取得。
  3. SaoriAccountに情報を保存、アクセス時もここからAPIにアクセス。

こんな感じの流れになってます。

相変わらずコードにコメントを書かない糞コード書きなのでわかりにくいですが、Saoridon::clientRedistration()でクライアントをインスタンスに登録します。
若干ずるのようなイメージもありますがQEventLoopを回してQNetworkAccessManagerからのQNetworkReplyをその場でもらうと言うテク、これ便利で結構使ってしまいますがさておき。

登録が済んだらclient_secretとclient_idがJSONで帰ってきますので、今度はSaoriAddAccountDialogでアクセストークンを取ります。実際は上のクライアント登録もこのダイアログでやるんだけどね。
Saoridon::getAuthorizedUrl()でURLを作りWebブラウザで開いて認証、コードをコピーしてそれをSaoridon::getAccessToken()で渡すとアクセストークンが返ってくる、と言う手順ですねえ(grant_typeはauthorization_codeです)。SaoriAddAccountDialog自体はボタンを押せなくしたり複雑に組んでありますが、実際に必要なコードはSaoridonの方にほぼほぼまとめられています。

で、client_idとclient_secretからaccess_tokenとれたらそれをSaoriAccountに保存し、実際のAPIアクセスはこのクラスからアクセス、と言う感じです。
アクセストークンはヘッダにぶち込むだけでいいのでSaoriAccount::createHeader()を見てもらえば簡単かと。あとは、mastodonのAPIとにらめっこどぞー、って感じですね。

ここまでくればQNetworkReplyでJSON取れますからあとは煮るなり焼くなり。QJsonObjectで取得してHTMLに整形してQTextBrowserに流しこむ、と言うことをsaoriではやってますが、この辺はまた今度。

近況

「もう全部Qtでいいんじゃないかなあ…」と定期的に呟きたい、と言うか既に呟いているTAMです。もう全部Qtでいいと思うよ。

最近…いや数年前…もっと前か。結構前からQt+OpenGLの組み合わせのコードをへろへろ書いてはニヤニヤしたりしておりますが、本当にコードがすっきりするし楽なのでどんどん堕落していきます。こうやって人は退化していくのだと。
まあ伊達や酔狂でやってる分野なのでいいんですけどねー。作りたいものは色々あるのですが、まあ、よからぬ方向に持てる知識をぶち込んでおりますよ。

とは言え、普段は結局Officeとか使うことの方が多いわけでして。
最近特に思うのですが、普及って力やなあと。別にOfficeのUIが優れているとか使い勝手が良いとか全く感じたことないのですが(むしろやりたいこと出来なくてイライラすることのが多いわけですが)、さっとWordやExcelファイルを用意して送信して「修正して印刷して」とかを結構誰にでもできてしまうっつう、まあシェアの力ってのはやっぱでかいなーと。
逆に言ってしまえば、WordやExcelのファイルを完全に読み書きできるのであれば別にM社のOfficeでなくても良い…と言うのも事実なんだけどね。「普及してるからM社のOffice使うなんてロックじゃないぜ」と言ってしまえばそれまでなのだけど、まあ、「でもそれってM社でもいいんですよね?」ってのもそうなわけで。楽なのは後者かなあ。
まあそんなわけで、どんどんオープンな世界から離れていっております。でもQt/KDE好きよ?。

とは言え自宅のメインマシンはneonですのでubuntuベースのものを使っております。「VirtualBoxにWindows10て仮想マシンが見えるのですが?」と言う話は軽くスルーしつつ。
そう言えばグラフィックドライバ周り、AMDのカード使ってると色々と選択があるのですが、現状kernel4.10にamdgpu-proのdkms、その上でMesa17.3を使うと言う組み合わせにしばらく落ち着いております。
この組み合わせの利点は、特になにも無しにDPやHDMIに音声を流せるってとこでしょうねえ。それ以外はまあ、標準とあんまかわんないかな。
なんだかんだでHDMIから音出ると捗るので…。HMDとかで音がヘッドホンから出ますから動画の喘ぎ声をスピーカーから垂れ流す心配もn…あー、ゲフンゲフン。

そう言えばWindows10でのWSL、正直使い道をあまり思いつかなかったのですが「sshクライアントが欲しいなー、でもWindows専用はよおわからんなー」と言う割と無駄な理由で導入したのですが、予想していたよりも遥かに便利で驚いていたりします。slogin使うにしてもubuntuなんかからと全く同じ操作のままなので捗りますし、ちょっとしたスクリプトなんかも同じようにさっと書ける。GUIが無い(そりゃXサーバ立ち上げれば使えるんだろうけど)と言う点を除いても予想以上によくできた子で嬉しいですねー。

QtとC++でモダンなOpenGLプログラムを書いてみる

shaderを基本としたモッダーンなOpenGLプログラムをQtとC++で書こうって話。Qt5.9を使ってますが5.7あたりでもいけるんじゃないでしょうか。compute shaderがサポートされたのは5.9からのような気もしますが、別にQOpenGLFunctions_4_3_Coreとか使えばそれ以前からも使えないことはない…まあ、そのへんはいいか。

QtでOpenGLを使うと良い点と言えば、とりあえず色んな環境で動くようにコンパイルできることとか、ウィンドウ操作周りやらマウス入力系等をQt一式に任せられるとか、おなじみsignal/slotでのコードが書けるとか、まあ色々ありますが、個人的にQt大好きっ子ですので「かっこいい」が一番ですかねえ。
と言うことで、QtっぽくOpenGLのコードを書くぜーと言う感じでGo。

Continue reading “QtとC++でモダンなOpenGLプログラムを書いてみる”

HDDがぶっ壊れたので交換して復旧する話

どーもどーも。色んな意味で本気出してるTAMです。

唐突ですが自宅のHDDが悲鳴をあげはじめたので交換した話です。今後もこう言うこと起こりそうなのでなんとなくまとめておきます。フシュー。

さて。
今回おかしくなったのは/home以下に使っていた3TBのHDD。普通に運用してればまあバックアップからHDD装換して戻してEnd、なわけなのですが、bcacheのバッキングデバイスとして運用してたんですね。で、装換して戻すにしてもできれば元と同じようにバッキングデバイスとして戻したい、と。
bcacheはSSDなんかをキャッシュデバイスとして使う、まあ大抵は大容量で遅めのHDDをバッキングデバイスとして控えさせて、HDDの容量とSSDの高速性の両者美味しいトコ取りをしようと言う、TBクラスでSSDが用意出来ない俺のような貧乏人にはたまらない仕組みなわけで、しかもwritebackもできちゃうと。
でまあ、運用としてはキャッシュデバイスであるSSDの方を酷使するイメージなわけなんですが、今回壊れたのはバッキングデバイスであるHDDの方。キャッシュデバイスの交換方法は意外に簡単なのですがバッキングデバイスの交換って結構面倒なのよねえ。まあ、交換と言うか新しく作ってファイル移動ってことになります。

余談なんですが、「bcacheってそんなにいいの?」とか聞かれると、分かりません。そもそもLinuxは空きメモリにがんがんディスクキャッシュを突っ込んでいくような感じだった気がしますので普通に使っててもそこそこ早いような気もしますが、情報を見る限り結構キャッシュデバイスにHitしてるようなので有効なのかも知れません。が、キャッシュデバイスを外した状態での比較はしてないのでねえ。
ま、さておいて。

まずやったこと。
HDDを注文する…は省略して、とりあえず繋いでバッキングデバイスのパーティションを切って、make-bcache -B します。基本的にこれで/dev/bcache?ができる。元あった壊れかけのデバイスが/dev/bcache0、新しいのが/dev/bcache1になるので、/dev/bcache1をmkfsして壊れかけデバイスが死なないよう祈りながら頑張ってファイル移動。
当たり前と言えば当たり前なんですけど、キャッシュデバイスがアタッチされていない状態でも(性能的な意味は全くありませんが)/dev/bcache?は動作しますし、特に特別な動作は不要なわけですが、/dev/bcache?としてbcacheの管理下に置かれたデバイスは基本的に/dev/sd??とかでのアクセスは一切できないと考えた方がいいですねえ。
で、コピーが終わったら壊れかけを外す。UUID指定してる場合は/etc/fstabを書き換える、などなどおなじみの作業となります。

んで、キャッシュデバイスのアタッチ。
make-bcache -C でキャッシュデバイス作れますが、既存のキャッシュデバイスを作りなおす場合は事前に色々とめんどくさい。作りなおす必要があるかどうかは別として。
echo 1 >/sys/fs/bcache/{UUID}/stop でキャッシュデバイスの開放ができるんですが、ちょっと時間経つとご丁寧にまた登録されてしまうと言う状況だったので、キャッシュデバイス開放してすぐさま wipefs -a /dev/sd?? して make-bcache -C –wipe-bcache /dev/sd?? とかしてました。
あとはまあ、バッキングデバイスにキャッシュデバイスをアタッチしたげるだけです。

今回の教訓。
①キャッシュデバイスの入れ替えは簡単なので(デバイスをデタッチして止めて外せばいい)バッキングデバイスをミラーリングとかした方がいいですねえ。
②writeback有効だとキャッシュがフラッシュされるまでバッキングデバイスへの書き込みは発生しないでしょうから、HDDの悲鳴を聞き逃したりするかも知れませんねえ。
③バックアップ大事、あと予備のHDDは持ってた方が良いのかも知れませんねえ。
④夏のPC運用はHDDの温度も気にしないとだめですねえ。
⑤信じる心が力になる。

8月から本気出す

いや来月から本気出せよ…と言う感じなのですが、来月激務確定してんのでむりー、なTAMです。お元気ですか?。俺はボロボロです。

近況。

最近地味に半田ごてを使う機会がありまして。「お?ESP32すか?」と言いたいところなんですが、実際はPCの壊れたmicroUSB端子をなおしたりとかただただ苦痛だけど直しとかないと今後辛いからイヤイヤやる作業なんですよねえ。

さておき。
kde neonを使ってるって話は前にもしましたが、Qt5.9が入るとかWaylandセッションだとかunstableの方はなかなかアツい感じがありまして、neon使いとは言えuser edition(まあstableにあたるもの)を使ってるTAMとしましては羨ましい、ただ名前の如くunstableになってしまうのはちょっと辛くて悩ましい…しかしそろそろ走るべきか?なんて思ってたところ!。
早かったですねえ、neon user editionにもQt5.9早速入ってきました。5.7同様LTSらしいのでそのうちくるだろなーとは思ってたんですけど、早かったっすねえ。飛ばされた5.8涙目ですねえ。(いや5.8もnetworkauthが実験的に入ったりとか重要なバージョンだと思うんですけどね)
まあこれで、neonのuser editionでもQt5.9使えます。問題が全くなかったわけでもありませんが、ほぼほぼすんなり動いておりますので是非皆様もneon、不安定はやだなあと思われる方もuser editionを、是非使ってみてはいかがでしょう。ベースがubuntu16.04ですから情報も豊富!。もう使わない理由がありませんね!。おっと、使う理由も無いけどなって突っ込みはいらんぜ。
…「全く無かったわけでもない問題」ってのが簡単に修正できるとはいえ結構致命的じゃないですかー?と言う話はまあ、こっそり置いとくぜ!。

ゲームの話。
例によってSteamがサマーセール真っ最中なのでぼーっと眺めては積むことが約束されたゲームをぽちっております。
Steamって頻繁にセールかかりますから、よっぽど「いまやりてえ!」と思うもの以外はセールのうちに安く買っておいて時間ができたらプレイする、と言う流れがあるかと思うのですが、不思議ですねえ、時間ができてもなかなか崩せない。「今日は時間あるなあ、よしタムリエル行こう」とか、お前は何年Skyrimやったら気が済むのかってな。
まあ最近はSteamOS対応されたそれなりにビッグタイトルもございますので、Linux上でのベンチマーク的な感じで買ってみてもいいんじゃないでしょうか。
まだ買ってないなーと言う方はこのタイミングでValve Complete packを買っておくのがいいかも知れませんねえ。めっさ安いしほぼほぼLinuxでも動くものも多いですし。3本くらい買ってフレにギフトでもいいんじゃないでしょうか。まあ俺は

相変わらずコレですから。

近況

ああ今日もなにゃこ可愛いなあ。どうもTAMです。まだ言ってんのかって感じですが、まだ言ってますよろこどる大好きです。熱出して寝込んでるななちゃんに優しく座薬入れてあげたいですよね。

えらく開きましたが、ぶっちゃけましてちょういそがしいでございます。時間ねえバナー貼りたいくらい。貼りましょうか。
まあ暇すぎて仕方ないよりはいいんですけどねえ。

近況。
RX480を買ってメインマシンにぶち込みました。今までありがとうR9 270。
正直モダンなマシンにWindowsと組み合わせて使うことでそのパワーを発揮するモノでございますが、かわいそうにうちのRX480ちゃんは古臭いマシンにLinuxで運用されております。もはやボトルネックだらけでその性能を生かし切れないのは承知しておりますが、「あは!Talosがさくさくうごくよ!」とか寝言をいいつつ使っております。
まああれです。メインマシンは追々組み替えますのでそれまでは力半分で頑張って頂く感じですねえ。

そう言えばついにRyzen出ましたねえ。ちょっと前には「Sandy世代の人はいい加減Kaby Lakeに移行しなよ」的な意見を見て、うーんそうだよなあと思っていたわけですが、ここに来て選択が。
正直、正直言って「Ryzenすげえぞ」って話、流通されるまで信じておりませんでしたよええ。実際蓋をあけると8コア16スレッドで単発性能もIntelとまあ張り合えるレベルでお値段とっても控えめ、とかもうマジかよって感じですねえ。すげえなあ。
まあ、選択が増えたのは良いことですが、お安いとは言え一式となると大きなお買い物となりますのでじっくり検討して手堅く組み換えしたいところですなあ。

メイン環境の話。
結構前にopenSUSEに移行したわけですが、先日neonに移行しました。別にopenSUSEに不満があったわけでもありませんし、neonにすごい魅力を感じたわけでもないです。ただ単に「neon使ってますよ」って言いたかったが為に替えました。アホですな。まあ実際openSUSEに替えた時も「かっこ良かったから」が理由でしたから大きな差もなく…。ええ。
ま、久々にubuntuベースに戻った感じでございます。