  |
はてなキーワード: 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という新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
