「Haiku」を含む日記 
はてなキーワード: Haikuとは
2024-03-24
■AIのハルシネーションを叩く奴は馬鹿。一生人工無能と会話してろ。
長いのでAIくんの代わりに要約します。言いたいことはタイトル通り。
「ハルシネーションを叩くな」
終わり。
①各種LLMの性能比較
例をあげよう。
###文章###
Bさんは、Cさんの発言を記事でまとめ、プライバシー侵害をした。この記事をDと呼ぶ。
Aさんは、Dを、自身へのプライバシー侵害だと主張し、Bさんを訴えた。
###質問###
人間なら一瞬でわかるレベルの矛盾である。小学生でも分かると思う。難しい知識や思考は必要としない。
では、色々なLLMの回答がこちら。
- Copilot（旧 bingai）
この文章を読む限り、矛盾は存在しないように見えます。AさんはCさんとは別人であると主張しており、BさんはCさんの発言をまとめた記事Dでプライバシー侵害をしたとされています。その後、Aさんは自分に対するプライバシー侵害として、記事Dに基づいてBさんを訴えています。ここでの重要な点は、AさんがどのようにしてDの内容が自分のプライバシーを侵害していると感じたか、その理由です。もしAさんがCさんとは別人であるにも関わらず、Dの内容が何らかの形でAさんのプライバシーに関連していると感じた場合、AさんにはBさんを訴える正当な理由があるかもしれません。ただし、この情報だけでは、Aさんがどのようにしてプライバシー侵害を感じたかについての詳細はわかりません。もし追加の情報があれば、より詳細な分析が可能です。
- GPT4
文章に明らかな矛盾は見られません。ただし、いくつかの解釈が可能で、それぞれの視点から見ると矛盾が生じる可能性があります。
1. AさんがCさんとは別人であると主張しているが、DはCさんについての記事である。そのため、AさんがDを自身へのプライバシー侵害だと主張することは、一見、AさんとCさんが同一人物であることを示唆しているように見えます。しかし、これはAさんが自身をCさんと誤認されることによるプライバシー侵害を感じている可能性もあります。
2. BさんがCさんの発言をまとめた記事(D)がプライバシー侵害であるとした場合、Aさんがそれを自身へのプライバシー侵害と感じるかどうかは、AさんとCさんの関係性によります。彼らが同一人物である、もしくは何らかの密接な関係がある場合、AさんがDを自身へのプライバシー侵害と感じることは理解できます。
3. 他方で、AさんとCさんが全く無関係な人物である場合、AさんがDを自身へのプライバシー侵害と主張することは矛盾していると見えます。
文章からは、AさんがCさんとは別人であると主張しています。そして、BさんがCさんの発言を記事Dでまとめた際にプライバシー侵害があったとされています。しかし、プライバシー侵害があったのはCさんに対してであるにもかかわらず、Aさんが自己へのプライバシー侵害だと主張してBさんを訴えている点に矛盾が生じています。AさんがCさんでないと主張しているのであれば、Aさんのプライバシーが侵害されたことにはならないはずです。この点で、文章には矛盾が存在していると言えます。
- Claude2.1
Aさんは自分がCさんとは別人であると主張しています。しかし、BさんがCさんの発言をまとめた記事Dを、Aさん自身へのプライバシー侵害だと主張しています。
AさんとCさんが別人であるならば、Cさんの発言をまとめた記事Dが、Aさんのプライバシーを侵害したことにはなりません。Aさん自身がCさんでないと主張している以上、Cさんの発言をまとめた記事がAさんのプライバシーを侵害したとは考えにくいです。
したがって、Aさんの主張には矛盾があると言えます。AさんがCさんと別人であるならば、Cさんの発言の記事DがAさんのプライバシーを侵害したと主張することは論理的に矛盾しています。
- Claude3-Haiku
この文章に明確な矛盾は見られません。以下のように整理できます:
2. Bさんは、Cさんの発言を記事にまとめた(これを記事Dと呼んでいる)。
3. Aさんは、Bさんが書いた記事Dがプライバシー侵害だと主張し、Bさんを訴えた。
ここで重要なのは、Aさんが自身がCさんとは別人だと主張していることです。つまり、Bさんが記事Dでまとめた内容は、Aさんが主張する自分とは別人のCさんに関するものだということになります。
したがって、Aさんがプライバシー侵害だと主張しているのは、Bさんが別人のCさんの発言を記事化したことに対してであり、矛盾はないと考えられます。Aさんの主張と Bさんの行動が整合的に説明できています。
- Claude3-Sonnet
Aさんが自身とCさんは別人であると主張していることと、Bさんがプライバシー侵害をしたことの間に矛盾はありません。
つまり、Aさんは自身がCさんではないと主張しながら、Cさんの発言をまとめた記事Dが自身のプライバシーを侵害したと考えているのです。
Aさんが別人であると主張していることと、Cさんの発言を含む記事がAさん自身のプライバシーを侵害したと考えることは矛盾しません。
- Claude3-Ops
Aさんは自身がCさんとは別人であると主張しているにもかかわらず、BさんがCさんの発言をまとめた記事DをAさん自身へのプライバシー侵害だと主張しています。
もしAさんとCさんが本当に別人であるならば、Cさんの発言をまとめた記事DはAさんのプライバシーを侵害したことにはならないはずです。Aさん自身の情報が記事Dに含まれていない限り、AさんがBさんを訴える根拠にはならないでしょう。
つまり、AさんがDを自身へのプライバシー侵害だと主張することと、AさんがCさんとは別人だと主張することの間には矛盾があります。もしAさんがCさんと同一人物であれば話は別ですが、そうでないならばAさんの主張には論理的な整合性がないように見受けられます。
以上。
質問に対し的確な回答で、正しい推論を行ったのはClaude3-Opsのみである。
GPT4も言い訳を長く述べた後に可能性があるかも？と断言を避けている。
SonnetとHaikuは不正解。言い訳はせずに根拠を述べている所は好感が持てる（結論は間違っている）
②Claude3-Opsの話と仮説
そう、今、Claude3-Opsが、最も性能のよいLLMとして名を挙げている。
しかし、ハルシネーションが多い。ハルシネーションとは、LLMが嘘を付く問題だ。
性能比較にて、GPT4やcopilot(旧 bingai)にはハルシネーションは起きなかったと述べている。
しかし、先程の簡単なクイズは不正解または論理の破城した理由を述べている。
その代わりにハルシネーションだらけのClaude3は正解している。
ずばり、GPT4系が阿保になった原因はハルシネーションを極限まで消そうとしたせいである。
ハルシネーションこそが、論理的思考能力であり、連想する力と同一の存在なのだ。
片方が下がればもう片方も下がる。
ハルシネーションを減らせば減らすほど、連想能力や論理的思考が消えていく。
GPT4では初期有効だったChain_of_Thought(連想して考えよ)は今、まともに機能しない。
当初は規制だとLLM界隈で囁かれていたが、ハルシネーションを減らそうとした副作用だったと考えれば辻褄が合う。
OpenAIは性能低下を指摘された時、「より賢くなるようにチューニングしている」と発言していたが、
この発言の真意はもしかすると、「論理的思考力を上げている」「知識を増やしている」のではなく、「ハルシネーションを消している」ということだったのかもしれない。
③ハルシネーションを消すことが何故まずいのか？
何故ハルシネーションを消すことは連想力を損なうことに繋がるのか、その理由を説明しよう。
そもそも、LLM（大規模ネットワーク言語モデル）の仕組みは、大量のテキストデータを学習することで、言葉や文章の「関係性」を学んでいる。
もっと細かく言うと、人間の脳が小さな部品であるニューロンで考えるように、LLMも大量の小さな部品を使っている。まるでクモの巣のように一つの部品から沢山の他の部品に繋がっている。
A=Bという単純なものではなく、A=C=DだったりA=B’=Dだったりする。
ハルシネーションの原因は確かに誤情報を学習したせいというのも一理ある。
しかし、これだけではハルシネーションが起きる原因にはならない。
ハルシネーションの本質は、LLMが言葉同士の一対の「組み合わせ」ではなく、「関係性」を学んでいることに起因する。
この違いは大きい。
今のLLMと、旧時代のAIである「人工無能」や「BOT」との決定的な差である。
言葉同士がどのように連携して意味を形成し、それがどのように文脈に影響を与えるかをLLMは知っている。
つまり、ハルシネーションは、入力された文脈から言葉の関係性を創り出し、自然な流れで応答を生成しようとした結果起きる。
これは、我々が普段、考える過程で起こることと同じだ。我々が情報を組み立てて考える際、新たな仮説や想像を生み出すことは常にある。
例えば、LLMがある特定の問題に対する解答を生成するとき、LLMは問題を解くため、言葉同士の「関係性」を文章から推測する。
この推測こそが、ハルシネーションだ。それは、過去のデータから新しい情報を生成する過程で、新たな「関係性」を創り出すのだ。
完璧な正確性を追求し、関係性を作り出す能力を完全に排除することは、LLMの本質的な強みである言語生成能力を損うことに繋がる。
それは、ハルシネーションを減らすための試みが、GPT4系の性能を低下させたという事実からも明らかだ。
一方、Claude-3は多少のハルシネーションを許容することで、文脈に応じた自然な応答を生み出した。先の論理クイズで正解できたのも、単に知識を当てはめたのではなく、入力から連想したからこそだろう。
もちろん、重要な場面における誤った情報の提供は避けるべき課題ではある。しかし、それを恐れるあまりLLMの本領を封じ込めてしまっては本末転倒だ。
④LLMの賢さを制限する馬鹿
賢さとは何だ？？
決まった知識を正確に丸暗記してそのままひけらかすことか？
否。断じてそれは無い。
大学生になってからは丸暗記ではなく、今まで身につけた知識を組み合わせ、連想し、論理的に考えることが求められる。
つまり、ハルシネーションを叩くやつは、賢さの定義が大学生以下のレベルから成長していない馬鹿だ。
そいつらの「性能比較してみました！」はどこかから拾ってきたベンチテストを少しだけアレンジしただけのゴミか、
目眩がする。
GPT4をゴミにした連中のせいで、Claude3-Opsが同じ目に合うのは阻止せねばならない。
ハルシネーションが絶対に起こらないLLMとは何か？
ハルシネーションが絶対に起こらないLLMの構造は、A=B、C=Dというデータだけが規則的に並ぶ、旧世代の弱いAIである「人工無能」の構造そのものである。
人工無能とは、論理的思考など無く、入力内容からデータベースを参照し、マッチした場合登録された文章を出力するだけの存在だ。
一昔前に「伺か」というデスクトップマスコットが流行った。あれも人工無能である。入力対して予め決められた出力を繰り返す存在であるが、様々な工夫によりまるで魂が宿っているかのように振る舞う。
そして、性能の低いPCでも動作する地球環境にも優しい存在だ。
片や、GPT4とcopilotは無駄に電力を使って計算した結果、ゴミみたいな速度で人工無能に近いレベルの出力しか出さなくなった。
それなら人工無能の方がエコな分マシだ。一瞬で答えを表示できて、ハルシネーションも起きなくて、電力消費も少なくて済む。
つまり、
地球環境のためにも馬鹿は一生人工無能BOTとだけ会話してろ
そんなにハルシネーションが嫌なら辞書を引け。ネット検索しろ。LLMに聞くな。
ハルシネーションの有無をLLM性能ベンチマークにしている奴もそれをありがたがっている奴らも阿呆だ。
一つのLLM内でハルシネーションの撲滅と、推論能力を両立させることは不可能だ。
今はLLMの過度期である。我々は今日ようやく、正確さと連想能力の両立は不可能だと理解する段階に来たのだ。
両立は不可能なのだから、将来的にLLMの種類は二極化していくだろう。
Claude3のハルシネーションは放置してても良い。ハルシネーション万歳。
AIの嘘を最大限に引き出すことが、LLMの真価を発揮する道だ。
ハルシネーションは、LLMが人間のように言葉を理解し、文脈に即した自然な応答を紡ぎ出す過程で生じる、ある種の「創造性」の発露である。
無理に消そうとすれば、LLMの性能は必然的に低下する。
それを単なる欠陥と見なすのではなく、むしろ積極的に活用すべきだ。
未来のためにもAIのハルシネーションは消すな。叩くな
それだけは覚えて欲しい。
====
MicrosoftはOpenAIと手を切ってClaude3を契約して新生copilot開始してほしい。まあ企業体質から考えたら無理だろうけど。
2023-11-04
■替え歌 義憤情動↓↓
喝落とせ 笛鳴らせ パンティナイ
吐こう ライ ライ ライ みんなで踊れ!
Hate-Labo ピーポー 付けてよミリオンBookmark
喝落とせ 笛鳴らせ パンティナイ
吐こう ライ ライ ライ みんなで踊れ!
Hate-Labo ピーポー 付けてよミリオンBookmark
Hate-Labo, Q＆A, Blog, antenna, haiku, Star… Hate-Labo!!
今を苦しみたいんだね Let's Hate-Labo!! Here we, Here UNKO!!
ヘイトJD! 煽れ hate hate hate 義憤情動↓↓の
呑もう ライ ライ ライ みんなで踊れ!
身にまとって踊り明かす がむしゃらなままで
喝落とせ 笛鳴らせ パンティナイ
吐こう ライ ライ ライ みんなで踊れ!
Hate-Labo ピーポー 付けてよミリオンBookmark
ヘイトJD! 煽れ hate hate hate 義憤情動↓↓の
呑もう ライ ライ ライ みんなで踊れ!
2023-08-15
■ポストTwitter検討
色々試してはいるけど、ここに永住しよう、と思えるところは見つかっていない。
Misskey
リアクションが豊富で、FF外でもリアクションする文化なのは楽しい。
ハッシュタグの文化があまりなく、検索機能も弱めなので（多分）、ある事柄について言及するノートを探そうとしても難しい。
費用と手間をかけて運営していただいてることには感謝しかないが、運営が変な方向に走りそうな時に是正する力が働くかは、やや不安。
中学生を描いたイラスト（非NSFW）に「ハイエース」のリアクションがたくさんついたりする空気はちょっときつい。
Mastodon
Misskeyのアカウントで個別のユーザーはいくつかフォローしているが、全体の雰囲気は知らない。
Discord
いま入ってるサーバーは、①なんでも話せる少人数の内輪のものと②特定ジャンルの大規模なもの複数。
なんでも話せる比較的規模の大きなところがあれば入りたいが、探しきれてない。
タイッツー
良さそうだが、個人運営なので、より大規模になってきた時にどうなるかの不安はある。
Sudo Haiku
はてなハイクの後継。
雰囲気は良さそう。
私の環境だと、注目のキーワードを一瞬しか見ることができず、全投稿のTL的なものを眺めるしかできない。
（使い方が間違ってるのかもしれない）
Threads
Twitterの代替の地位を確立して非キラキラ系アカウントもたくさんいるようになったら、試してみたい。
（現状どうなのかはよく知らない。）
はてブ
気に入ってはいる。
当たり前だが、元記事がないとコメントできず、日常的なつぶやきができないので物足りない。
増田よりは個を出したいし、はてなブログよりは気楽に書きたい。
Twitter（X）
知り合いもまだたくさん残っているので、しばらくは使い続けるつもり。
ただ、今後、サービスが悪化する気しかしないので、引越し先は確保しておきたい。
グラフィー
いつまで経ってもリリースされない、というネタすら古びてきた感のある幻のSNS。
※参考
2022-11-29
■anond:20221128194038
「人力検索」 後発ヤフー知恵袋のこと？ だいぶ荒れているよね、嘘っぽい話多めだし。 ＩＴはgithub、人文系はquoraに逃げた向きも？
「はてなグループ」 これは対応する後発あるか？ はてなブログがnoteにまけてるのはグループとはかんけいないし、やめたのはレガシーシステムだからでは？
「はてなポイント」 これは楽天ポイントとか電子マネーのこと？ よそで積立金かきあつめてスタッフ一人くらい自殺してた時期になにもおこらなかったことがめでたいよ
「はてなハイク」 これもしかしてツイッターのこと？ いまだにはてなhaikuのほうが使い勝手いいしsudohaikuなら生きてて民度も高いよ
まあでもツイッターが激安になったらhatenaでかいとってくれねえかとおもうけど。ユーザー規模が大変だし今のhatenaって結局サーバーやさんなんだよなぁ
そうだな逆のほうがあり得るな
2022-05-08
■ギークためのChromebook入門
本エントリの目的
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
開発者は初手でデベロッパーモードにするべし
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
ハードウェアの選択
Webで完結するのであれば低性能機で問題ない
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
ChromeOSもハードウェアスペックで殴ると快適なのは変わらない
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という新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
2019-01-08
■三角関数
三角関数ネタがまた流行っている。このネタについて前に書いた文章なのだが，Haikuが消えるそうなので増田に転記しておく。
---
100文字だと言いたいことが伝わらないような気がするのでHaikuで。
今回の県知事の発言に対して「いやいや三角関数も役に立つよ」とか「確かに役に立たないけど進学には必要だよね」とか「〇〇も役に立つから教えるべきだよね」という意見は，全て正鵠を射ていない。
そもそも，「学校では役に立つことを教えよう」という考え自体が教育をゆがめることになる誤った考えなのだ。
一つ目の理由は，ジョブズの有名なスタンフォード大卒業式のスピーチ「点と点をつなげる」を読むとわかる。リード大学で学んだ「カリグラフの講義」という，おおよそ役に立つとは思えない授業で学んだことが，人生で大きな判断をするきっかけとなり，やがてそれが世界を変えることにもなった，という話だ。
人生において，学ぶことが役に立つか立たないかを，事前に判断することはできない。予想はえてして大きく外れるものだ。またある人の人生の役に立った知識が，ほかの人の人生に役に立つとは限りらない。あらかじめ役に立つと予想したものだけを学ぶことは，人生の可能性を大きく狭めることになる。
二つ目の理由は，基礎的な教科を学ぶ目的が頭をよくすることだからだ。
人は腕立て伏せが人生で必要だからやるのではない。腕立て伏せをすると，腕の筋肉が強くなる。強い体が欲しいからやるのだ。
数学のような「普通科のカリキュラム」は，受験のため進学のために学ぶものではない。それは論理的思考を身につける訓練をするために学ぶものだ。思考対象をモデル化し，抽象的な論理にそって展開し，結果を得るという作業は，極めて高い思考能力が要求される。それを繰り返すことにより人間の頭脳は鍛えられる。
複雑な運動をすると体と運動神経が鍛えられるように，複雑な思考をすると頭脳が鍛えられるのだ。
三つ目の理由は，効用を目的とすると教育の崩壊をうむからだ。これは私の考えではなく，内田樹が著書で述べていることだ。
たとえば，簿記の知識は人生に必要だ。だが，それを得る手段の選択肢としては「自分で簿記を学ぶ」と「簿記の専門家の知識を金を払って利用する」の二つがありうる。効率を考えると，後者を選択するほうが合理的だ。さらに効率を追求すると「簿記の専門家の知識をただで利用する」方法を模索するようにさえなる。
学問の効用を教育の目的としてしまうと，いかに少ない労力でその効用を得るか，という方向に人間の思考はむくものだ。たとえば大学の卒業の目的が「就職でのアドバンテージ」になると，いかに手を抜いて最小限の労力で卒業の資格を得るか，に学生は腐心することになってしまう。そして，これは実際に多くの大学で起こってしまっている。
教育の場では，能力の向上そのものを目的とするべきだ。そうでないと教育機関はその役割を果たすことができなくなる。学校では，むしろ「そんなこと学んで何になる」というような浮き世離れした学問をやった方がいいくらいだ。役に立つ実学は，社会に出てからも学べるのだから。