  |
はてなキーワード: GIMPとは
夏休みあけ、久しぶりにパソコンを付けたら、最初のパスワードを入れる画面の、「今日は何の日か知っていますか？」みたいなところが□□□□□□□□□□□□？になっていた。
スタートボタンは無事だったけど、スタートの横にある「🔎検索」を押すと明らかに游ゴじゃないフォントで「□□□□検索」と出る。
メモ帳もWordもGIMP普通に開けるのに、研究室で買っている有料のグラフ描画ソフトは一瞬画面が開いてすぐ落ちる。これが問題で、このソフトがないとやっていけないので、先生に英語版を買ってもらって申し訳なかったし、いかんせん英語ができないので、ソフトの使いかたを人に教えてもらうときも押すボタンの名前じゃなくて上から何番目かで聞かなければいけないので地味に困った。毎回ソフト立ち上げてくれた同期先輩本当にありがとう。
ネットで調べて出てくる解決法は一通り試したけど効果なし。まあ卒業したらゲームにしか使わないし……と諦めていたけれど、それが！！今日！！！！！！直った！！！！！！！！！！
ことのいきさつは、メモ帳のフォントを見やすいものに変更したとき、ふと、Windowsのシステムフォントって今何なんだろうと思い立ち、游ゴシックだかYUGothicUIだか書いてあったが、もしかして、不具合は私がちまちま集めたフリーフォントが悪さをしているのではないか？と考えた。グラフ描画ソフトはノートパソコンでも開けなかったので。
それで今パソコンに入っているフォントを調べ、YUGothicUIと游ゴシックとごちゃっとなりそうな名前のフリーフォントを全部アンインストールした。５つくらいかな、気に入ってるのもあったので残念だったが全部消した。で、再起動したら、全部！文字が！ちゃんと表示されるようになったんだわ！！！すごい！！革命！！！！！！！！
もっと早く気づきたかったけどもういいわ！直ったし！！使いもしないフォントをばかすかインストールするのはもうやめます！！！！！
Twitterとの大きな違い、それは誰しもがActivityPubプロトコル互換の分散SNSサーバーを立ち上げられるという技術的な面以外にも文化的な大きな違いがあって、Twitterでは誰しもが受信者であり発信者であることが工程されるけれども、ActivityPubプロトコルネットワーク、通称Fediverseでは発信者の中でも特に面白いことを作り出す創造者が特に高く評価される傾向にある。
ActivityPubプロトコル互換分散SNSサーバーであるMastodonやMisskeyにはユーザー自身(正確にはサーバー管理者)が自由に投稿文中へ埋め込めるカスタム絵文字を設定できるし、更にMisskeyではカスタム絵文字によるSlackやDiscodeのようなリアクションへ対応し、MFM(Markup language For Misskey)と呼ばれる文字装飾に関するマークアップ環境が整えられておりユーザーはより自由度の高い自己表現投稿をすることが可能だ。
そんなFediverseに居る創造者たちはGIMPやInkscape、FFmpeg、Imagemagickなどを使いこなし、日々面白いカスタム絵文字やアニメーションGIFを生み出してはタイムライン上で笑いを誘い、そしてTwitterでは知られることのないネットミームを生み出しては、いつの間にかTwitterでも使われるようになるのは珍しくなくなっている。
そのノリはまるで世間を全く知らない男子中学生のようで、バイトを始める人が多くなる高校生にすら至らない子供じみた文化だと言える。
ここまで書いて思うのはActivityPub、プロトコル、分散SNS、サーバー、Fediverse、GIMP、Inkscape、FFmpeg、Imagemagick、etc...様々な単語を持ち出したが、これら単語へ即座に反応できる人こそが色々と問題や騒動が巻き起こっている現在のTwitterから別のマイクロブログ型SNSへ移住することができる素質を持つ人々だということだ。ポイントは「移住することができる」である。つまりTwitterには「できない」人が居るのだ。
男子中学生のような子供じみた文化についていけない以前に、明らかにFediverseでは実際に手を動かして五感を刺激する創造へ対する評価が妙に高い。例えば社会問題へ鋭い意見を単なる文字で"ツイート"するだけじゃFediverseでは評価されにくいのではないか？という疑念がある。
Twitterでもイラストやショート動画、面白いGIFは評価される。しかしユーザーの割合で言うと、そのような実際に手を動かして五感を刺激する創造を行える者は少ない。Fediverseではそれが当たり前だとでも言うかのように割合として創造者が多すぎる。
無産オタクなどという言葉が稀に見られるけれどもFediverseでは無産オタクであっても少なくともカスタム絵文字やマークアップで面白おかしく装飾できるようでないと居心地が悪く感じてしまうのだ。Fediverseで無産オタクは価値がないと誰も言わないが、創造者への評価が異常に高いので相対的に無産オタクの価値は低いという現状がある。
誰かが砂場で山を作る、そしてそれを面白がった誰かがトンネルを掘る、水を使えば更に面白い造形が出来て流れる水はスゴイのでは？と誰かが提案し実行する。
Fediverseでは砂場の周りで評論しても砂場の中で遊んでいる子供は決して砂場の外へ目を向けない。眼の前の砂の山をどうするかで頭が一杯なのだ。
選民意識に使うリソースなどFediverseの創造者たちは持っておらず砂の山しか見ておらず、砂場の周りで評論する自分たちのことなんか全く気にしていないからだ。
一部の情報技術者寄りのギークはPhotoshopやIllastratorは触ったこともなく使えないがGIMPとInkscapeは困らない程度には扱えるというデザイナーがツッコミ入れそうなおかしなスキルセットになっていることがある
あるあるで笑ったw
オレもFirefoxやLibreOfficeやBlenderとかはありがたく使わせてもらってるw
Macなので、画像をイジるのはSeashoreにお世話になってるやで。GIMPのコードベースに一部依存してるらしいGPLな画像編集ツールだ。たまに数日おきに立て続けにアップデートが出たりして、頑張ってる感があって頼もしいが少しウザいww
いやわかる、MS OfficeとかAdobeは業界標準だしファイル互換でインポートとかも楽だ。
ただまぁその万人へ必須か？と言われたら圧倒的にそれが必須じゃない仕事をしている人のほうが多い。
何なら仕事じゃなくて趣味レベルであるならばなおさらMS OfficeとかAdobeとか業界標準ソフトウェアじゃなくても良くなっちゃう。
ということで、ありきたりなシェアウェア代替オープンソースソフトウェアのリストを作ってみた。
ド定番中のド定番、オープンソースのオフィススイートだ。
MS Officeじゃなくて良い人はLibreofficeかGoogleのクラウドのヤツを使ってる。
やはり主に使われるのはワープロソフトのWriterと表計算ソフトのCalcとプレゼンテーションソフトのImpressだが、MS Accessの代替として挙げられるBaseは厳密な意味で代替とはならないためMS Accessの代替を無料でゲットしてやろうと考える人が陥りがちの罠だ。
まぁただデータベースのフロントエンドソフトとしてBaseはそこそこ使えるので、MS Accessの代替として捉えるのではなく別種のデータベースフロントエンドソフトとして割り切れば想定されることの大半ができる。
MS Visioの代替としてDrawも挙げられがちだがMS Accessの場合と同様にDrawもVisioの厳密な代替とはならないので注意が必要だ。
Adobe Illastratorの代替として挙げられがちなオープンソースのベクターグラフィックスソフトウェア。
高機能なのだがIllastratorと比較すると恐ろしいほど使いにくいUIを持っており、折角の高機能へアクセスするにはどうしたら良いのかわからないと挫折する人が多く出る。いやなんでホントこんなUIなんだ。
ただ、諦めずクソUIに付き合っていると不思議なもので人間は慣れてしまい結構自由度高くベクターグラフィックスを生成できるようになる。
Adobe Illastratorには無い長所としてSVG規格へ厳密に従うという方針で開発されているため、Illastratorで生成したSVGをWebでそのまま使うとWebブラウザで謎の描画バグにWeb屋は悩まされるがInkscapeではそれが無い。描画バグが起きるとき製作者が間違った設定を行っているか、Webブラウザ側が使っている設定に未対応な場合がほとんど。
将来的にサポートする気はあるらしいが現状はアニメーションSVGに弱いのも残念でならない。どうしてもアニメーションSVGをやりたいのであればInkscapeで生成された静止画SVGをアニメーションSVG化することを想定しているaniGenというWebベースのエディタがあるので調べてみると良い。
Adobe Photoshopの代替として挙げられがちだが、元来Web用の画像を製作するためのラスターグラフィックスソフトウェアなのでRAW現像や写真を加工するためのソフトじゃないが、本家すらその辺のことを忘れたふりをしている。
画像編集や加工で求められる基本的な機能はほぼ網羅されているが、RAW現像に関しては標準状態のままではできず、最近のAdobeが搭載している人工知能を用いた機能もないのでクラシカルなラスターグラフィックスソフトウェアと表現することもできる。
GIMPとInkscapeが使えると大半の画像製作は何とかなってしまうため一部の情報技術者寄りのギークはPhotoshopやIllastratorは触ったこともなく使えないがGIMPとInkscapeは困らない程度には扱えるというデザイナーがツッコミ入れそうなおかしなスキルセットになっていることがある。
Adobe Lightroomの代替として挙げられがちなオープンソースのRAW現像ソフトウェア。
実はdcrawというRAW現像のためのオープンソースのライブラリのフロントエンドであり、GIMPでRAW現像するために活用されるUFrawも同様にdcrawのフロントエンドであるため中身は同じだったりする。オープンソースのRAW現像ソフトウェアはdcraw使いがち。
オープンソースソフトウェアでRAW現像を賄っている人はGIMPでUFrawを活用してRAW現像するよりもUI的に使いやすいのでRaw TherapeeでRAW現像でTIFFを出力しGIMPで微調整するような使い方をしている人が多い。
オープンソースの2D CADで以前はQcadと呼ばれていた。
一部の読者はJw_cadのJWWファイルを扱うことが可能という特徴を持っているというだけで興味を惹かれてしまうのではないか。
Jw_cadとは違ってWindowsやmacOS、各種Linuxディストリビューションで動くので2D CADデータをネット上の友人知人などとやり取りしたいときに向くんじゃなかろうか？ニコニコ技術部的な遊びとか、最近流行りのルール無用JCJCタイムアタックとかで。
オープンソースの3D CADで、近年は3Dプリンターあたりの需要でよく目にするようになった。
Autodesk AutoCADやFusion 360、Dassault Systèmes SolidWorksよりも草の根では広まっており日本語でのハウツー記事もオープンソースソフトウェアとしては比較的多い印象。
シミュレーション機能はシェアウェアと比較すると弱い傾向があるものの草の根でそこまで必要か？と言われたら悩む。無料でシミュレーションやりたいならOpenFOAMにでも流し込め。
オープンソースのお絵描きに特化したラスターグラフィックスソフトウェア。
歴史的経緯ではLinux界隈でのGUIツールキットの2大巨塔にGTKとQtがあり、GTKはGIMPを作り上げるために生まれたこともありGTK側には高度なラスターグラフィックスソフトウェアが存在していたがQt側には存在していなかった。そこでGIMPの対抗としてQtを用いたKritaの開発が進められたが次第にGIMP的な画像編集ソフトウェアよりもお絵描きに特化していき現在のような性格を帯びるようになった。
SYSTEMAX ペイントツールSAIやセルシス CLIP STUDIO PAINTからの影響が強く現れており、オープンソース界隈のSAIやクリスタなどと呼ばれることがある。クリスタがそうであるようにスマートデバイスへの対応も計られAndorid OS版やChrome OS版が存在する。
ただ日本の需要を敏感に拾えるクリスタなどと比較して漫画作成機能に関してKritaは弱いと言われることがあるものの、GIMPと同様に無料とは思えない機能が充実しているのもまた事実である。
オープンソースの3DCGアニメーションソフトウェアで、非常に多機能のため何故かAdobe After Effectsの代替として挙げられることもある。
YoutubeがBlenderのYoutubeチャンネルへ広告を載せろと迫ってBlender公式がそれを拒否してYoutubeから撤退したり、庵野秀明が率いる株式会社カラーが出資したことなどオープンソース界隈でも異彩な存在感を放っており日本国内でも非常に注目されているプロジェクトだ。
ただ、初期状態では独特なUIによる使い勝手が非常に悪くユーザーが自分で使いやすい配置を模索する必要があったりタイムラインが使いにくかったりと何故オープンソースソフトウェアはUIがクソになりがちなのか？という問題にぶち当たる。
オープンソースの2DG/3DCG兼用プログラミングIDE。つまりはUnityとかみたいなやつ。
MIT Licenseでロイヤリティーフリー、開発言語はC#もしくはC++、そしてPythonライクなGDScriptで、Unityみたいにマウスでポチポチしてオブジェクトへ色んな設定を決められるので「Unityみたいのでゲーム作りたいけど運良くヒットしたときにライセンス料がなぁ」と懸念している人に役立つ。
ちなみにWiiとニンテンドーDS用向けにリリースされたSEGAゲームタイトルのソニックカラーズのSwitchやPS4などのマルチプラットフォーム移植版ソニックカラーズ アルティメットはGodotを用いて移植されているので商用でも耐えうることはSEGAが証明している。あのSEGAがソニックでだ。
オープンソースな動画編集ソフトウェア。
様々な部分で動画ライブラリのFFmpegへ依存しているためFFmepgのフロントエンドソフトとしての性格も持つ。
この手の無料の動画編集ソフトは国内だとAviUtlや近年ではBlackmagic Design DaVinci Resolveが人気だけれど、海外のオープンソース界隈ではShotcutは比較的知名度が高い。
カラーグレーディングに関して不足のない機能を有しているので高度なトランジションを用いるというよりも色を追い込むような使い方が合っているだろう。
ていうかFFｍpegのフロントエンドなのでFFmpegができることは理論上なんでもできる(理論上なので追加でコマンドを叩く必要があったりするけどね)。
オープンソースのレコーディングソフトウェア。旧名称はAudacityと言われるとご存じの方も多いハズ。プライバシー問題でAudacityからプロジェクトが分岐されTenacityとして再出発することとなった。
旧Audacityは開発の主な拠点がロシアを中心に行われていたという経緯があり、現在のウクライナ-ロシア戦争へ至る前の影響からか個人情報の収集をロシア企業が行うと発表され、それに反発したユーザーらによってプロジェクトが分岐しTenacityプロジェクトが立ち上がった。
Audacity自体はVSTプラグインが動作するなど非常に高機能なレコーディングソフトウェアであったがウクライナ-ロシアの騒動に巻き込まれたと言った感じだ。
Audacityから分岐したTenacityもそのまま高機能なレコーディングソフトウェアなのでこれからはTenacityを使ったほうが色々面倒が少ないだろう。
ProToolsの代替として挙げられがちなオープンソースのDAW。非常に高機能でDAWとして求められることの大半ができるものの、これもまた通例通り最近流行りの人工知能を用いた云々かんぬんは標準状態だとできない。
Ardourプロジェクトの立ち上げをし主要開発者であるポール・デービス氏はJACK Audio Connection Kitのプロジェクトの立ち上げをし主要開発者であるという事実を伝えると驚く人がいるかも知れない。LinuxとGitのリーナス・トーバルズ的な文脈だ。
オープンソース界のFL Studioと呼ばれることもあるDAW。ステップシーケンサーを中心に作曲するタイプのDAWで電子音楽が得意。LMMSという名称はLinux Multi Media Studioの略でLinuxに端を発してマルチプラットフォーム展開をしたDAW。
オープンソースのDAWにしては珍しく初期状態から多数のソフトウェアシンセサイザープラグインが用意されておりインストールした時点で遊び始めることができるものの、オープンソースの例に漏れずクソUIを持っており使いにくい。GIMPやBlenderもそうだが1990年代後半〜2000年代前半あたりに流行したMDI(Multiple Document Interface)を未だに引きずっているためクソUIになりがちなのだ。
ググると日本国内にも意外とユーザーは居て、DTMやりたいけど初期投資は低く抑えたいみたいなユーザーが選んでいる模様。そういう需要ならLMMSの他に基本無料で全機能が使えて一部のプリセットが有料のVitalっていうソフトウェアシンセサイザーも導入しておくと延々遊べるよ。
オープンソースなWebブラウザとして非常に有名な存在。
Google率いるChromium系Webブラウザに近年物凄く押されているものの独禁法を回避するためGoogleはMozillaへ出資しているという歪な構造を持つ。
Mozillaの運営が下手すぎて資金をドブに捨てることを繰り返しているためGekkoレンダリングエンジンに未来があるのかと一部の識者から不安がられている。
Firefoxは使いやすいのか？と言われたら、それはもう好みの問題としか返せないのだがカスタマイズ性は非常に高い。
MS OfficeやPhotoshopからデファクトを奪うレベルのオープンソースソフトが未だに出てこないのはどういうこと？
LibreOfficeにしろGIMPにしろ、いつまで経っても業務でまともに使えるレベルにならないし。
あとGUIも、オープンソースにおける決定版がこれまた待てど暮らせど出てこない。
てかOSSって、便利である以上に複雑怪奇なUIで、ユーザを苦しめるソフトばっかり作るよね。
(Perl、sendmail、bind、TeX、gnuplotなどなど挙げてったらキリがない)
なんでユーザの使い勝手というか、そこら辺のデザインがこうも蔑ろにされるのか意味がわからん。
結局、viとemacsどっちがいいかという、傍から見たらきのこたけのこ未満のしょーもないレベルで使い勝手を言い争っていた頃から、OSS界隈は何も変わっちゃいないと。
某北海道なんとか研究所で海賊版ソフト使用がバレて賠償金を支払ったとかなんとか。
昔勤めてた会社でPhotoshopが必要になったとき、試用版でやっとけ、とか言われたことがあったな。
マスターコレクションが30万とかの時代かな。CCはなかった。
GIMPとかPaint.NETではpsdのレイヤーが正しく開けなくてな。
ベンツを乗り回したり、オフィスをお洒落カフェみたいにする金で仕事道具を充実させられたはずだが。
最近はFigmaになって末端のPGは画面部品切り出しに画像ソフトのインストールは必要なくなった。
全く使ってないしそろそろCC解約するか。。今までいくら払ってきたのだろうか。
考えないでおこう。
オープンソースソフトウェア(OSS)は、ソフトウェア開発でも長い歴史を持ち、なおかつかなり個性的な特徴がある。
ざっと挙げるなら
こうしたコミュニティから生まれてきたソフトを最も多用しているのは、他ならぬWeb系だろう。
サーバサイドプログラミングが中心になることから、Linuxを触る機会も他の開発系に比べて格段に多いだろうし。
結果、「UNIXの哲学」とかGNUの歴史とか全く意識せずとも、こうした活動を通じていつの間にかOSSのエッセンスを身に着けた人が、Web系には少なからずいそう。
その意味では、OSSがどういうわけか今のWeb系の礎になってしまったという意味で、タイトルに書いた通りになっているのかなーと。
取引先が「ペーパーレス化への取り組みのためFAXをやめてPDFファイルでのやり取りに…」ってFAXしてきたから
「対応できます！是非！」って食い気味に返したんだけど、話をよく聞くとクラウドで共有リンクとかは検討すらされてなくて
結構な量のファイルをメール添付で送る話を検討してるっぽいのよね。多分PPAPだよなぁ……
専用のメールアドレスで受け取って、シス管がスタンドアロンで開いて…とかするくらいなら、
自動印刷しない複合機で受けてPDF形式でメール転送からのスクリプトでチャットツールに流して……のが楽なんでFAXでお願いしますってなっちゃうんだよなぁ
ただそうすると「照会依頼：該当するチェックボックスに✓を付けて返送してください」みたいな地獄のFAXが無くならないんだなぁ
ちなみにこの手のやつはGIMPでPDFを開いてテキストレイヤー重ねて印刷ダイアログからMicrosoft print to PDFで書き出してPCFAXすると有料ソフトなしで倒せる…が徒労感が凄まじい
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
当時、アイコラと呼ばれるものが問題になったころに、画像加工に興味を持った。
GIMPをダウンロードして作ってみるが、全く満足できるものが出来なかった。
どう見ても不自然なものが出来上がってオカズをどころではなかった。
しかし、当時は性欲の塊だったので、これならいけるかもしれないという淡い期待で一年中1日5枚くらい作っていた。
100枚越したあたりから、なんとなく自然に見えるコツが分かってきた。
500枚こえたあたりから、言語化できてパターン化できるようになった。
そして今もひたすらに試行錯誤を続けている。平均すると毎日3枚を10年間くらいやっている気がする。
だからなんなんだ、という話だが
これは仕方ない面もある話だけどSFMLはIME対応をバッサリやらないとフォーラムだったか作者だったか書いてたよなあ
でもGLFWのIME対応は日本人のプルリクが受け入れられてたはずで、今は日本語が普通に入力できる
アルファベット圏の人たちはほんと多言語対応をあんまりしたがらない
（まあ、最近はちょっと違うかもしれない。あとSFMLは余計なコードを入れずシンプルなままでいたいのだとは思う
なんだったかな、日本人がプルリク出したら却下されたんだけど、中国人が強気で出してやっと採用されたような話があったはず
コミュニケーション能力というか、ゴリ押しもコミュニケーションなんだよなあ
そう考えると、多人数によるプログラミングもコミュニケーションのウェイトが高くなりすぎて駄目になる可能性があるわけで、
当たり前だけど、だったら一人でとぼとぼ書いてる方が気持ちは楽なんだよな、気持ちは
集団やチームワークならではのパワーが発揮されなくなるけど
まあ、でもプログラミングの良い点としては分割されているというのがあると思うし、
論理的思考をしているならば正しく分割、単純化、抽象化されているはずなので、
例えば閉鎖的なコミュニティーとか人種差別とかそういうのが嫌でも、そのライブラリをとりあえず使えばまず最低限動かせる
次にそのモジュールを既存のコードに頼らずに再実装するとか迂回して、それにそげ変えればいい
どっちかというと、こういうのはライセンスの話が多いと思うのだけれど、こういう点がプログラミングの良い所だと思う
あと、GIMP昔はゼロから比較的楽にビルドできた気がするんだけど、今のGIMPは自分でビルドできそうにない
GEGLとかコンセプトはいいんだけど、なんか移行してたり移行してなかったりが混在してたり、ややこしくなった感がある
というか、ほんとBlenderは化けたよなあ
（BlenderはPythonで操作してモデリングできるぐらいPythonなんだけど、Pythonが言語として生き残ったというのもあるなあ
