Core i7 クラスのCPUや16GB以上のワーキングメモリ、SSD ストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。

Android Appレイヤーを中心に運用したいと考えてるならばx86_64機は非効率

Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。

1つの IDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。

しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。

ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。

Android Appレイヤー

macOSのiOS レイヤーよりAndroid App数は多いし操作性は良い

Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。

Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。

GPSは事実上ほぼ機能しない

ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPS モジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPS レシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。

USB over MIDIが使える

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はスリープする

ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。

まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroid スマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。

ICT 教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。

Linux レイヤー

実体はLXC/LXD

LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？

デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。

IMはLinux レイヤー側で用意する必要がある

ChromeOSで動作するGoogle日本語入力とは別に Linux レイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。

USB Pass Throughが使えない

ChromeOSへマウントされたUSB 機器、というかシリアル接続された機器はLinux レイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。

つまり Linux レイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linux レイヤーでゲームやろうと思ってもUSB ゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。

それぞれが独立しているLinux レイヤーとAndroid Appレイヤーは相互に認識しない

言うなれば Android Appレイヤーでスクリーンキャプチャ系のアプリによってLinux レイヤーで動くGUI アプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。

ChromeOSがホストでLinux レイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。

Linux レイヤーにDockerを構築するのはやめておけ

LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲスト OS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲスト OSの制限はKVMも引き継ぐ。

ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。

Web開発であれば必要十分

CLI ツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWeb デザイナーは悲しい思いをするかも知れない。

GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？

Chrome OS向けAndroid Studioが存在する

Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。

3DCG ゲームを作りたいのであればGodot

UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。

3Dのほか2D ゲームもいける上に、最近のIDE よろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。

総評

浅い部分は気軽だが深い部分は非常に難解、それがChromebook

浅い部分を触っているうちは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という新しい沼へギークの皆さんをご案内しているに過ぎないのだ。

Permalink | 記事への反応(10) | 15:50

■anond:20220508012028

ゲーマーを代表する人間とかあんまり出て欲しく無いかな開発者とかなら応援する気になるけど

Permalink | 記事への反応(0) | 01:22

2022-05-07

■従業員50人ほどの中小 IT 企業のFLOSS活用事例 n = 1

弊社ではその設立当初、というよりも創業者(＝私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。

従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。

社内文書はODF

弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。

社内文書として用いられる文書フォーマットはODF 形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。

えんたぁぷらいず……

ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているものの日本国内でLibreOffice Enterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね？
社内では「むしろウチがやったら？」なんて声もチラホラ聞こえますが……。

ちなみに社内デファクトスタンダードのフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています。

OSの縛りを設けていない

弊社ではFLOSSを活用しているせいもあって特に OSの縛りを設けていません。何なら経理担当はChromebook使ってます。
社内のOS シェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。

気になるであろう開発環境についてですが、Dockerを用いて開発環境の統一化を計っており、その時々に応じてDocker コンテナを切り替えて開発しています。
Dockerを用いているせいもありLinuxディストリビューションの社内OS シェアが高くなっているのです。
プライベートで従業員は様々なOSを選択しているようです。ゲームとかVRが趣味であるならばWindows しか選択肢ないでしょうしね。

ちなみに業務用のPCはBYODで購入補助あります。
結局は従業員の現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ？」とは助言してます。
会社はまとまったお金を出しているに過ぎないのでメリットとデメリットがありますよね。

GNUプロジェクト下ソフトウェアは無申請で利用可

いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクト下ソフトウェアは無申請で利用可としています。
ただし制限は公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます。

本番環境のホスト先は色々

どこの会社もそうでしょうけれどもAWSやAzure、GCPなどたいてい大手に置いてますね、予算の都合もあるけれど。

デザイナーは主にWindowsを使っている

これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員がWindows ユーザであったので惰性のままWindowsとなっているだけであり、中にはMacで仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります。

Linux 環境では苦手なIllustratorのAI 形式などはSVGやラスター画像に落とし込んでもらって開発者が適用するという運用になっています。
社内では特定の環境へ依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。

みんなGitが使える

開発者から経理、デザイナーに至るまで弊社従業員はみんなGitが使えます。
ただし使えると言っても全員がCLI からコマンドを打てるわけでなくGUI クライアント上からの操作しか出来ない者も居ます。
主に使われているGitのGUI クライアントはGitKrakenです。

入社時の受け入れ教育でLibreOfficeやGitの指導をすることになっており、全従業員が浅くともGitとは何ぞや？を理解している状態にあります。
ちなみにGit リポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます。

社内にセルフホストしているGitLabサーバもありますが、こっちは従業員が個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時のバックアップと思われるものがちょこちょこありますが。

プロジェクト 管理ツールはopenproject.org

プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります。
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmineと操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。

社内チャットは主にElement(Matrix)

他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています。
これは当時インターン生だった弊社の現従業員が若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます。

ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。

会計はFreee

会計はFreeeです。特にこだわりはありません。たまたま Webブラウザから使えたのでFreeeとなってます。

弊社は95%リモートワーク

残り5%は主に私が出社しているからｗ
社内にサーバがあるので私以外も出社してくることはありますが基本的にコロナ禍以降は全従業員がリモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね？週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目に時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろｗ

結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます。
オフィスの処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも？

1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在は新規募集を停止中です。いやホント申し訳ない。
事業が軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。