  |
はてなキーワード: aptとは
ここの結論を先にいうと，神奈川県公立高等学校入学者選抜インターネット出願システムなんだからドメインは shutugan.pref.kanagawa.jp か shutugan.pref.kanagawa.lg.jp などの地域型JPドメインか属性型JPドメインを使う設定をするべきであった．
これは最近問題になっているいわゆる行政サイト使い捨てドメイン問題とも関連あるし，（１次ソースにするには怪しいとしても総合的にみると載っている情報は正しそうな）カナガク https://kanagaku.com/archives/69495 によれば，なんと shutsugankanagawa.jp shutsugan-kanagawa.jp nyuushi-kanagawa.jp の三つとも本番環境として使われているようなのであり( nyushi-kanagawa.jp は違う)，その状況だけ見ても本物に混じって偽物がスパムやフィッシングを行っていてもほぼ見分けが付かないのである．
Google から見ても，取得が容易なjpドメインで最近取得したドメイン，似たようなドメイン，似たようなメール，が送られてくるのである．ユーザの受信ボックス・迷惑メール・ゴミ箱に大量に届く懸念がある以上，ブロックするのが定石である．
仮にブロックせず受信ボックス・迷惑メール・ゴミ箱に届けた場合，大量送信によってユーザの使用量を圧迫し 15 GB 到達すると，そのユーザは新規のメールを受信できなくなり本当に必要なメールを取りこぼす可能性がでてきてしまう（容量空ければ受信できなかったメールを受信し始めるわけではない）．
なので，大量送信 SPAM 判定したメールはできる限りブロックする選択が，Gmail にとってある意味最善手なのである．
なお，神奈川県は令和 4 年度までは @pref.kanagawa.jp をメールで使っていたが令和 4 年度以降から @pref.kanagawa.lg.jp に切り替えているので，ベストは shutugan.pref.kanagawa.lg.jp であったと思われる．
サブドメイン毎にドメインレピュレーションが分かれているためあまり深い意味はないが，少なくとも pref.kanagawa.lg.jp は 2007/04/16 に登録され有効なドメインなので，新規登録に比べて信頼性が高いと判断される．
なお，kanagawa.jp と kanagawa.lg.jp の切り替えもいろいろと謎はあるが，それはまた別の問題．
※webページは kanagawa.jp の方だし他方 e-kanagawa.lg.jp なんてのもあり……ちなみに e-kanagawa.jp は 株式会社つくばマルチメディア 登録ドメインで行政は関係ない．
少なくとも動き始めには DKIM / DMARC が設定されておらず，問題になってから設定し始めてもそれはSPAMを頑張る業者と行動様式が似るので無駄なあがきとなっている可能性が高い．
SPF は 2006年，DKIM は 2011年，DMARC は 2016年に出てきた対 SPAM 技術である．DNS 弄ったりメールサーバー建てるような人でないならこれらの設定方法は知らなくてもしかたない．
だがそれらを生業としている側の人間なら， 2024 年現在， 13 年前に提案された DKIM すらちゃんと設定できないというのは，iPhone 4 や Internet Explorer 9 向けの開発しかわかりませんとか，スマホアプリで LINE 聞いたことないというのを 2024年に言っているのと同じレベルなのである．
そのぐらい前の時代に提案された迷惑メール対策・認証系の機能を未実装で本番環境動かすというのは，語弊のある誇張表現をするなら Windows Update や apt upgrade を 13年間しないで通信を試みるようなもので，自殺行為に等しい．
もちろん，その通信を受ける側はこいつヤバいやつだってすぐわかるので，かなり辛口で評価することになり，ちょっとでも SPAM の雰囲気出してきたらブロックするのは定石．
そしてブロックされた SPAM 側はあの手この手でおかまいなしに SPAM 送ろうとするので似たような内容やドメインでしつこく送ろうとするので，似たようなものもどんどんブロックするのである．
なので初手でヤバいやつ認定されないのが極めて重要にもかかわらず，そこを怠っていたのである．
実際に，2024 年 1 月 12 日時点の mail.shutsugankanagawa.jp はどうなっていたかというと DKIM 設定がないまま本番環境を動かしていたようである． https://archive.md/qykwX
ここで実際いろいろ正常化しても，それは SPAM 業者があの手この手でなんとしてでも SPAM 送り届けようと頑張っている様子と一緒なので，ある意味無駄なあがきなのであるどころか，SPAM認定を加速させた可能性も否定できない．
Gmail も SPAM対 策は馬鹿じゃないので，送信ドメインを変えても文面があまり変わっていないなら SPAM とするし，送信元の IP とかも見て SPAM とするので， Amazon SES 使いつづけたり新 IP で何回も試行するとうまくいかないし，送信元信頼性の高い送信サーバーサービス経由で送れたりするようになっても，SPAM扱いされることもよくある．
ちょっと送信に成功しだしてまたいっぱい送り出して SPAM 業者扱いされるのはやっていることが SPAM 業者と同じことというか，その辺の今時の SPAM 業者より SPAM 業者っぽい挙動をしているのである．
今でもたまに Google anti-SPAM/phishing 網をくぐり抜けてくる えきねっと のフィッシングメールもびっくりするほどであろう．
Gmail ユーザーへの送信ガイドラインみたいな文章は，最近の DMARC 騒動で見る人が多いこのページが一番詳しい https://support.google.com/a/answer/81126?hl=ja .今はその騒動に応じてかなり加筆されているが，このページは開発中はどうであったのだろうか．
まず開発スケジュールについては，この開発は神奈川県の調達情報によると，調達案件番号 0001450060020230089R 業務名『神奈川県公立高等学校入学者選抜統合型WEB出願システム構築及び運用・保守業務委託』で間違いないと思われ，開札日が令和5年3月31日だからプロジェクトの始動はその後だろう．
※税金使途への意識高い県民はご存じの通り，ここから誰でも調べられる https://nyusatsu-joho.e-kanagawa.lg.jp/DENTYO/P6515_10
ちょうどその頃の Web Archive がたまたまあって 2023/03/07 時点ではこうなっていた https://web.archive.org/web/20230307005024/https://support.google.com/a/answer/81126?hl=ja
冒頭では
重要: 2022 年 11 月より、Google Gmail アカウントにメールを送信する新規の送信者は SPF または DKIM の設定が必須になりました。
とさらっと メールを送信する新規の送信者は SPF 「または」 DKIM の設定が必須 である一方，『ドメインのメール認証を設定する（必須）』の重要のところをよく読むと，
重要: 2022 年 11 月より、個人用 Gmail アカウントにメールを送信する新規の送信者は、SPF または DKIM を設定する必要があります。Google では、新規の送信者から個人用 Gmail アカウント宛てのメールをランダムにチェックして、認証されたメールであることを確認します。認証方法が一つも設定されていないメールは拒否されるか、迷惑メールに分類されます。この要件は、すでに送信者である場合は適用されません。ただし、組織のメールを保護し、今後の認証要件をサポートするために、必ず SPF と DKIM を設定することをおすすめします。
のようになっていて，「今後の認証要件をサポートするために、必ず SPF と DKIM を設定することをおすすめ」など，やんわりと新規の送信者は認証しっかり 必ず SPF と DKIM を設定することをおすすめ しているのである．
こういう書かれ方しても，個人のメールサーバーとかなら SPF か DKIM どっちかで運用してみてドメインを駄目にしても笑い話になるけど，自治体で運用するシステムであえて，博打に挑戦する必要あるのだろうか．
まぁ本来発注側の要件定義書とかにちゃんと SPF / DKIM を設定することなどと書いておくべき案件だったかなとは思う（たぶん書かれていなかったんだろう）．
とにかく今は全世界の3割弱が Gmail と言われている中で，本当に Gmail が謎仕様のブラックボックスで届かないことが多発していたら国内外もっと騒ぎになるので Gmail 側に今回の件で大きな瑕疵があったとはいいがたい．
設定不備およびその後の作業内容で地雷原を突き進んで自爆しているのだろう．
アホらしいけどアホに一番わかりやすくいえば Google Workspace / Gmail 同士では IP メールサーバーのレピュテーションと無縁になれて，世界中の他の宛先にもだいたい問題なく送れるので，SPF / DKIM / DMARC の設定だけ気にすればよく，かなりシンプルなのである．
Amazon SES 使えていたんだから Google Workspace も不可ではないはず（ISMAPに Google Workspace もいるので，あとは要件しだいだけど）．
今日は花金で午後暇になったのでざっと調べて書き出したけど，去年（おそらく最小限の修正などで運用するための発注） 3,600,000円 だったシステムを，今年は全面刷新して 138,600,000 円かけたわけだけど，ちょっとさすがに値段の割にお粗末な印象がある．
まぁ入札調書の開札日付が「平成」のままになっていたりしているの見ると教育委員会側も事務方スタッフが発注前から既に疲れてるんだろうなとも思うなど，ただそういう大人の事情はともかく受験生の心情を考えると，本来あるはずのない余計なストレスを掛ける結果に，大人の一員として恐縮してしまう．
一つ思うのはこれ「一般競争入札（技術審査型）」だけど本当にちゃんと技術審査したのかね？する能力あった？安い方に安易に決めてないだろうな？？と，突っ込んでいった方が今後の神奈川県の教育環境のために遠からずなるかなと思ったけど，よく考えたら私は神奈川県民じゃなかったわ
ノートPCなのに個人ユーザじゃなくて共通ユーザにしている会社はマジで滅びてくれ
「その人がいなくなってもログインできるようにしておきたい」
だったら共通ユーザを追加した上で普段は個人ユーザをちゃんと使え
今時MicrosoftだろうがAppleだろうが小規模から大規模にいたるまでユーザー管理の方法を提供してくれてて
そのユーザー管理に基づいていろんなソフトウェアが準備されてあるんだから
それをちゃんとおとなしく使ってくれ
まぁノートパソコンを事務員が使う場合は「知識がない」という理由で仕方がない部分はある
一番最悪なのはサーバー系でそれをやってるアホはマジで滅びてくれ
EC2やAzureでサーバー建てて、初期に作られるroot権限持ちのユーザーをそのまま使い続けてて
おまけに10人とかでその秘密鍵を共有してるアホは今すぐPCを返却して無人島で暮らしてくれ
もしくはちゃんとしたところでちゃんとしたサーバー運用を学んで来てくれ
ユーザー管理をしっかりしてないサーバーは運用から何からめちゃくちゃで手が付けられん
yumやaptでupgradeしようとするとエラーになって、そのエラーがなんなのか分からないのでずーっとアップグレードされてなかったり
コンフィグファイルがぐっちゃぐちゃで誰も何が起きてるのか把握できてなかったり
共通ユーザのホームディレクトリはもちろんめちゃくちゃで、/etcや/varに至ってもゴミファイルが大量に放置されてたり
最近、IT系の不祥事が多発してるけど多分この手のゴミ屋敷が時限爆弾みたいになって発火してるのが大半だと思う
これやってるやつはすぐにPC返却してくれ
会社設立にあたり業務用回線を新たにeSIMで契約したが謎エラーで引っかかったのでメモがてら投稿。
Androidの設定マニュアルは当然端末毎ではなく、別のメーカーの画面で説明されているので良く分からん。
色々ググってみるとSIM追加の操作(今はまだ出来ない)をするとエラー画面にリンクが付いているので、そこから見に行くことが出来るらしい。分かりづら！
郵送された手順書にQRコードが付いており、それを読み取ればeSIMダウンロード完了になるのだが、「ネットワークが無効です。電話番号の有効化中にエラーが発生しました」とメッセージが表示されエラーになる。
ちょっと時間置いてもエラー、入ってたSIMカード抜いてみてもエラー、何度試してもエラー。と全く解決の糸口が見えない。
ほかのメニュー触ってみても関係ありそうな設定とかはないし、完全に行き詰った。設定回り色々触ってて、たまたまAndroidのシステムアップデートの通知が来てたのでそれを実行。
再起動した後に再度QRコードを読み取ると、今度は成功。これか原因！？これが原因だとしたらサポートに連絡しても絶対に解決しない気がする。
通話とメッセージの動確もバッチリOK。デュアルSIMにするとモバイルの電波マーク2つ並んでて初めての光景にちょっと感動。あと、電話アプリの履歴やメッセージアプリに通信会社が表示されるようになった。
調べたけどできなかった。だけどこんなのあるんだ。ありがとう
結局ubuntuを再インストールして、apt install emacs-mozc-bin のインストールにしたらOKだった
snapでインストールしたemacsと、aptでインストールしたemacsがある
もともとは snap版のみを使っていたが、apt install emacs-mozc をしたら、なぜか/usr/bin/emacs が呼ばれるようになって、おそらくこのemacsはaptでインストールされたものだと思う。
優先度は/usr/bin > /snap/bin なので、普通に $emacs と呼ぶと、aptのemacsが使われる。
[解決策1]
alias emacs='/snap/bin/emacs' とする。
ただし、which emacsとしたとき、/usr/bin/emacs と出るので、この設定のことを忘れたときにはまりそう。
[解決していない策]
ただ、これをしても/usr/bin/emacsが消えない。なんでだろう
CoreKeeper側で apt に依存しているっぽいので、Ubuntu でやった方が楽だと思います。
Ubuntu 20 TLS でやる場合、/home/steam/Steam/ が /home/steam/.steam/ になってたと思うので、環境に合わせて読み替えてください。
dpkg --add-architecture i386 add-apt-repository multiverse apt-get update apt-get dist-upgrade reboot
useradd -m steam passwd steam gpasswd -a steam sudo
sudo -u steam -s cd sudo apt install steamcmd ln -s /usr/games/steamcmd steamcmd ./steamcmd +login anonymous +app_update 1007 +app_update 1963720 +quit
cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/ ./_launch.sh
Press Ctrl + C for Stop Core Keeper Dedicated Server
mkmir -p -m 775 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds chown steam:steam /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
Copy old world file (0.world.gzip) to
/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
Copy old setting file (*.json) to
/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/
chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/*.json
vi /etc/cron.hourly/corekeeper_backup #!/bin/bash cp -a /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip /home/steam/worldbackup/0.world.gzip.`date '+%Y%m%d%H%M%S'` cp -a /home/steam/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt /home/steam/worldbackup/CoreKeeperServerLog.txt.`date '+%Y%m%d%H%M%S'` chmod 777 /etc/cron.hourly/corekeeper_backup sudo -u steam -s cd mkdir worldbackup
sudo -u steam -s cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/ nohup ./_launch.sh tail -f ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt
利用者の問題か、サーバーの問題かわかりませんが人数が10人超えると CPU4コア/メモリ4G/100Mbps で結構ラグかったです。
今は CPU6コア/メモリ8G/1000Mbps で動かしています。
６-８人以上で２-３時間サーバー動かしてると、Unityのライブラリがsegfault起こして、Core Keeper Dedicated Server が落ちます。
ログ取れたのでバグレポしましたが、改善するまでは不特定多数が好き勝手するサーバーみたいなのを長期運用するのは厳しいかなと思います。タイミングによってはアイテムロストしてしまうので。
dockerでubuntu:20.04でchromeDriverにchromium-browserとか入れればいいんだろ？
誰か「chromium-browser？ それなら apt-get install lsb-release libappindicator3-1 の次に
wget https：//dl.goo略/_amd64.deb して dpkg でインスコや」
ってか、これじゃchromeDriverが動かない。chromium-browser も無いし、インスコ出来てなくない？
別の誰か「ちゃうちゃう、apt-get install chromium-browser がシンプルでええやん」
まあ、そうやろな。インスコしとくれ。
ターミナル「色々DLしとるが、どっかの https：//archve.略/foobar で Bad Request が返ってきたでｗ」
何やそれ・・1回くらい自動でリトライしてくれていいんやない？自分でリトライしたら通ったで。
しかしこれも動かない。
別の誰か「apt-get install default-jre いるみたいやで。ドキュメントどこにも書かれてないけど」
何やそれ？なんでJREが出てくるの。
まあJRE入れれば、確かにchromedriverの出すエラーは変わった。
「chromium-browserのプロセスが居なくなったし、クラッシュしたんじゃね？」と。
何やそれ。。。
chromium-browser --version をやってみると
ターミナル「snap install chromium でsnap版入れてくれｗ」
まあよく知らんが、やったるか。snap install chromium っと
ターミナル「あかん、http：//localhost/v2/snaps/chromium に繋げられんのやがｗ」
なんでlocalhostに繋げようとしてんの。
いまだにLinuxくんと仲良くできない。
追記。
なるほど、Ubuntu 20.04 からはsnappyに移行しとるんだと。しかしWSL2ではsystemdが動いてないんでsnapdも動いてない。だからアカン。
わいが仲良くできていないのは、LinuxくんではなくWSL2くんと言うべきなのか？
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
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という新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
当エントリはある程度の情報技術リテラシーが必須であり、一部の情報はPC初心者および初級者に推奨できるものではない。
しかしPC初心者および初級者はシステムを壊す、大事なデータを失うなどの手痛い失敗をして成長するのもまた事実であり、もしもプログラミングなどに興味のあるPC初心者および初級者がこの情報を活用する場合はシステムを壊す、大事なデータを失うことを覚悟して実行するように。
チュートリアルに指示通りに進めれば大きな問題はほぼ発生しません。
Chrome OSは初期状態のデフォルトで「ノーマルモード」と呼ばれる一般ユーザーモードですが開発者向けに「デベロッパーモード」が用意されています。
ノーマルモードはChrome OSの様々な制限があり、デベロッパーモードによって制限の解除が可能です。
しかしノーマルモードからデベロッパーモードへ移行するとPowerwash(初期化)されてしまい、システムやユーザー領域へ追加された情報はすべて削除されます。
もしデベロッパーモードが必要な場合はデベロッパーモードの詳細を調べ、現在の情報は削除されてしまうことを念頭に実行しましょう。
ちなみにProject CrostiniのLinuxレイヤーへDebianリポジトリからパッケージを導入するなどにはデベロッパーモードは必要ありませんので多くの場合はノーマルモードのままの運用で十分でしょう。
Android OSアプリやChrome OSアプリを開発したい場合は最初からデベロッパーモードにしたほうが後悔が少ないです。
Chrome OSでは一部のキーがほかのOSでは見慣れないものが並んでいます。
迷いがちなので一番最初に覚えるべきキーボードショートカットは「Ctrl+Alt+?」です。
「Ctrl+Alt+?」でいつでもキーボードショートカットを確認できることだけは覚えておきましょう。
多くのChrome OSデバイスはGoogle Play Storeへ対応しており、Google Play Store経由でAndroid OSアプリ導入が可能です。
しかしながらGoogle Play Storeへ公開されているAndroid OSアプリが必ずしもChrome OSへ最適化しているのか？と言えばそうではなく、Android OSアプリの開発環境であるAndroid StudioがデフォルトでChrome OSでの実行を許可していることもあり開発者が意図せずChrome OSへインストールできてしまうことが大半です。
したがってChrome OSへ導入するAndoirdアプリの動作へ何らかの不具合があったとしても脊髄反射で酷評せず、やんわりと丁寧に博愛精神をもってChrome OSではこうだとアプリ開発者へ情報共有することをオススメします。
多くのAndroidスマートフォンやタブレットはARMアーキテクチャーと呼ばれるものを採用していますが、現在のChrome OSデバイスは高性能な製品になるほどx86(x86_64)アーキテクチャーを採用している傾向があります。
本来コンピューターアプリケーションというものはアーキテクチャーが異なると実行起動動作が不可能ですが、Android OSアプリは異なるアーキテクチャー間でもアプリの実行起動動作が極力可能となるように互換性をだいたい確保しています。
しかしながら例えばARMアーキテクチャー向けのAndoird OSアプリをx86アーキテクチャーなデバイスで実行するとアプリ動作のパフォーマンスが著しく落ることが多いです。
これは高度なグラフィックス機能を必要とするゲームなどで顕著に現れる傾向にあり、Chrome OSでは期待したほどAndroid OSアプリが軽快に動かない可能性を理解しておく必要があるのです。
コロナ禍によって多くのChrome OSデバイスを販売することが出来ましたが、それによってChrome OSデバイス間の性能差が問題視される機会も増えました。
具体的には「インターネット上でChrome OSでの動作報告がなされているAndroidアプリが自身のChrome OSデバイスではインストールできない」といった報告です。
これは一部のAndroidアプリ開発者がデバイス性能によってインストールの許可不許可を決めているために起こることで解決方法は基本的にありませんので諦めましょう。
これから導入するAndroidアプリのためにChrome OSを購入する際は価格につられて低性能すぎるデバイスを購入してしまうと失敗する確率が高まりますので注意が必要です。
ただし、Googleが提供するアプリなどは基本的にそのようなことは無いようです。
設定から「Linux（ベータ版）」で「オンにする」とLinuxのインストールが開始されます。
現在のChrome OS v90ではLinuxレイヤーを実現するProject CrostiniではデフォルトでGPUによる支援機能を実行できません。
Chrome Webブラウザを起動し、URL欄へ「chrome:flags」と入力しアクセスして「Crostini GPU Support」を「Enabled」とし再起動してください。
この変更で動作に不具合を確認した際は設定を元に戻してください。
LinuxにもGoogle Play Storeのような簡単にLinuxアプリを導入できる環境が存在します。
GUIパッケージマネージャーを導入する場合は「ターミナル」を起動し下記を実行してください。
sudo apt install synaptic gnome-software
Chrome OSとLinuxレイヤーではパッケージの導入先がデフォルトで海外のサーバーになっており少々遅いです。
日本国内のサーバーへ変更することで速度を改善できる可能性があります。その際は「ターミナル」を起動し下記を実行してください。
現在のChrome OS v90ではChrome OSとLinuxレイヤーを実現するProject Crostiniで日本語入力を共有できず、キーボード入力しても英字しか印字されません。
日本語入力をするには別途に日本語インプットメソッドと日本語フォントが必要です。
日本語インプットメソッドと日本語フォントを導入する場合は「ターミナル」を起動し下記を実行してください。
Linuxへ詳しい方はfcitx5のほうが何かと問題が少ないでしょう。
しかし一部のfcitx5向けパッケージがDebian公式リポジトリに存在しない可能性があるのでご注意ください。
KVMやLXC、Dockerなどの仮想環境を幾度か試しましたが、仮想環境を構築したProject CrostiniのLinuxレイヤーを再起動するなどによってProject CrostiniのLinuxレイヤーシステムへ致命的な破壊が起きることがあるのを何度か確認しています。
Project CrostiniのLinuxレイヤー自体が仮想環境のため、Chrome OSのシステムが破壊されるわけではないですが業務利用時にLinuxレイヤーシステムの破壊が起きてしまうと困ってしまうので仮想環境構築は推奨できません。
仮想環境によって開発環境の統一を計っている現場では開発デバイスとしてChrome OSデバイスは利用しないほうが良いでしょう。
ただし、Chrome OSデバイスは実質的にAndroid OSデバイス、タッチスクリーンデバイス、キーボード付きデバイス、タブレットデバイス、ノートPCデバイス、コンバーチブルデバイス(いわゆる2in1)、マルチタスクデバイス、ウィンドウ可変デバイス、タッチスタイラスペン付きデバイスとして機能する可能性を秘めていますので実機デバッグ用デバイスとしては非常に価値があります。
昨今はアスペクト比が16:9でないどころかリアルタイムに可変してしまうデバイスが物凄く増えていますのでスマートデバイス向けアプリを開発する現場ではデバッグ用として1台持っていても全く損しないデバイスかと思われます。
さらに言えばティーン層はGIGAスクール構想によりChrome OSでプログラミング学習をしているわけですからティーン層取り込みのためのUI開発にも使えるのではないかと考えます。
