  |
はてなキーワード: MacOsとは
Appleお前なぁ・・・学習コスト高すぎんだよ！！！！！
ナンチャラKitとかよぅ・・・イノベーティブだって！？Appleデバイスでしか使えないやんけ！！！！！
VulkanとかFlutterとかのほうが話題になっちゃってる現状を見ろよ！！！！！
何故かわかるか！？
VulkanとかFlutterはほかのプラットフォームでも使えるからなんだよ！！！！！
お前どうせDirect3Dみたいな立場を夢見てんだろ！！！！！
macOSのゲーム環境がウンコなのDirectXのせいだろ！！！！！
なんでマイクソソフトの真似しようとしてんだよ！！！！！
Flutterが流行の兆しを見せたからってやっつけでSwiftUIなんて作りやがって！
そういう仕事するからSwift(SwiftUI)は未完成とかって言われるんだぞ！！！！！
いまだUI Kit使われてるのはそういうことやぞ！！！！！
WindowsのWSL2がそこそこ使えるLinux環境整備しちゃって開発者みんなWindowsだLinuxだと言い始めてる現状をマジで直視しろよ！！！
これでQualcommがまともに使えるラップトップ向けSoCでもリリースしてみろ！
M1のマイナーチェンジのくせにメジャーナンバー上げてマーケティングで劇的性能アップなイメージ振りまいてる場合じゃなくなるぞ！！！！！
ブランディングネームなんてお前の胸先三寸だってバレてんだよ！！！！！
Apple信者！いまのAppleの開発環境の学習コスト高すぎてマジで微妙だってのは知ってくれ！！！！！
そのコストを負っているのは開発者でWindowsやLinux、Android界隈がクロスプラットフォームを強化していて眩しく見え始めていることを認識してくれ！！！！！
Apple信者お前らだけがAppleの目を覚まさせられるんだ！！！！！
もう書いている内容の時点でエンジニアに既に向いてないじゃん
でも向いてなくてもなんとなく食っていけるのがIT業界のいいところよな
Macを推奨するサイト（ブログ）が多いが…
数量的にきちんと把握したものではないですが、「プログラミングに向くPCはMac」（特にMacBook）という解説のサイトは多く見つかりますが、大抵はプログラミングスクールが制作した集客用ページ、フリーランス（ブロガー）による広告収益目的のページで、制作の意図には商業的な目的がありそうです。
「エンジニアはMacを使用している」という主張もありますが、実はこれは根拠がありません。
ITエンジニアがWindowsとMacどちらをよく使用しているかを調査した統計は見つかりませんが、エンジニアに限らず、一般的にどちらが使用されているかを示すデータならあります。情報処理推進機構がインターネット利用者の使用OSを調査したものですが、圧倒的にWindowsです。macOSはたった4.3%です。数年前とは言え、状況は劇的には変化していないでしょう。
Windows7 (21.9%)
明確な根拠がない以上、主観の域を出ませんので、安易に信用はできません。
私見ですが、MacBookを推奨するサイトが多い理由の1つは「おしゃれでウケが良いから」です。twitter上の駆け出しエンジニア（もしくはエンジニア志望）の方々を見ると、大抵、見た目がきらびやかなものに飛びつく傾向があるので、その点、MacBookはウケやすそうです。まぁ、スタバに座ってMacBookで仕事をすれば確かにおしゃれです。
Google AdSenseを収益源にするサイトは閲覧数が重要なため「どのような記事なら見られるか」から逆算して考えます。なので、必然的に見た目の格好良さが重視されます。これは、SEOとかWebライティングと呼ばれる技術の悪い側面ですね。
ちなみに、私もMac（MacBook Pro）を1台所有していますが、購入のきっかけは勉強のためでした（色んな機械を触ってみたいから）。Macは特にメイン機ではありません。開発環境がWindowsにもあるので、両方を使用しています。
「Macはプログラミングに向いている」は本当か？
複数のプログラミングスクールのサイトで「MacはRuby、Python、PHPは特に開発効率が良い」という解説も見つかりますが、理由が説明されておらず根拠がありません。
WindowsだとVisual Studio Codeという非常に強力なエディタが無料で使用できるし、テキストエディタのAtomもプラグインを入れれば、それなりに開発はできます（ちなみに両者はMac版もある）。後で解説しますが、Web系がメインのエンジニアであればmacOSは親和性は高いのは事実ですが、だからと言ってWindowsの開発効率が悪いことはないです。
それに、Python、Rubyは今後はデフォルトではmacOSには含まれなくなります
https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes
プログラミングPCにWindowsとMacどちらを選べばよいか、という問題 | YukiPress
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
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という新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
弊社ではその設立当初、というよりも創業者(＝私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。
従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。
弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。
社内文書として用いられる文書フォーマットはODF形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。
ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているものの日本国内でLibreOffice Enterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね？
社内では「むしろウチがやったら？」なんて声もチラホラ聞こえますが……。
ちなみに社内デファクトスタンダードのフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています。
弊社ではFLOSSを活用しているせいもあって特にOSの縛りを設けていません。何なら経理担当はChromebook使ってます。
社内のOSシェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。
気になるであろう開発環境についてですが、Dockerを用いて開発環境の統一化を計っており、その時々に応じてDockerコンテナを切り替えて開発しています。
Dockerを用いているせいもありLinuxディストリビューションの社内OSシェアが高くなっているのです。
プライベートで従業員は様々なOSを選択しているようです。ゲームとかVRが趣味であるならばWindowsしか選択肢ないでしょうしね。
ちなみに業務用のPCはBYODで購入補助あります。
結局は従業員の現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ？」とは助言してます。
会社はまとまったお金を出しているに過ぎないのでメリットとデメリットがありますよね。
いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクト下ソフトウェアは無申請で利用可としています。
ただし制限は公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます。
どこの会社もそうでしょうけれどもAWSやAzure、GCPなどたいてい大手に置いてますね、予算の都合もあるけれど。
これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員がWindowsユーザであったので惰性のままWindowsとなっているだけであり、中にはMacで仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります。
Linux環境では苦手なIllustratorのAI形式などはSVGやラスター画像に落とし込んでもらって開発者が適用するという運用になっています。
社内では特定の環境へ依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。
開発者から経理、デザイナーに至るまで弊社従業員はみんなGitが使えます。
ただし使えると言っても全員がCLIからコマンドを打てるわけでなくGUIクライアント上からの操作しか出来ない者も居ます。
主に使われているGitのGUIクライアントはGitKrakenです。
入社時の受け入れ教育でLibreOfficeやGitの指導をすることになっており、全従業員が浅くともGitとは何ぞや？を理解している状態にあります。
ちなみにGitリポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます。
社内にセルフホストしているGitLabサーバもありますが、こっちは従業員が個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時のバックアップと思われるものがちょこちょこありますが。
プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります。
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmineと操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。
他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています。
これは当時インターン生だった弊社の現従業員が若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます。
ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。
会計はFreeeです。特にこだわりはありません。たまたまWebブラウザから使えたのでFreeeとなってます。
残り5%は主に私が出社しているからｗ
社内にサーバがあるので私以外も出社してくることはありますが基本的にコロナ禍以降は全従業員がリモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね？週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目に時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろｗ
結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます。
オフィスの処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも？
1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在は新規募集を停止中です。いやホント申し訳ない。
事業が軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。
上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます。
早くコロナ禍終わらんかなぁ……。
RStudioがPC内から気がついたら消滅していたので何回もやり直すのが面倒で書いた
コメントアウトをいじればFedoraやmacOSでも動くと思う
https://pastebin.com/HiPqLVq7 (6/4 shコマンドでも動くように修正 以前はbash hogehoge起動していたので動作確認していなかった)
エラーでここに貼れなかった
util-linux(rev) libxml2-utils(xmllint) gpg curl coreutils(sha256sum)とR関連
echo "$HTML" | xmllint --nowarning --xpath hogehoge --html - | hogehoge
こうしないとxmllintがエラーでhtlmなどをうまく読み取らない
sed 's/href="//g;s/"//g;s/\s/\n/g;s/^.?$//g;s/^\n//g'
href="hogehoge"の形で出てxmllint内で除去出来なかったのでsedで妥協
hrefが1回しか出ないのでひとまとめにできそうだが面倒なので分けた
この書き方なら複数回出ても除去できるはず
先頭の謎のスペースの除去が面倒だった
echo "$HASH" "$FIELNAME" | sha256sum --status -c ;echo $?
スペースが2つないと書式で怒れられてハッシュ値が合っていてもsha256sumが終了ステータス0で正常終了を返してくれない
VScodium
ShellCheck
https://open-vsx.org/vscode/item?itemName=timonwong.shellcheck
XPath Helper
https://chrome.google.com/webstore/detail/xpath-helper/hgimnogjllphhhkhlmebbmlgjoejdpjl
zenn.devに書こうか迷ったがどちらの方が良かったのだろうか…
ダウンロードしたサーバーがやられてるならハッシュ値も改ざんするだろうgpgで確認しないと意味ないでしょとかsudoでやったらディレクトリがとか色々ガバあるから誰かいい感じに改良して
https://cran.rstudio.com/bin/linux/debian/
https://www.rstudio.com/code-signing/
少し前にmacOSはLinuxではないとTwitterで話題になりました。その際に
といった内容のTweetを見かけたのですが「元になったのはBSDではなくMachなんだけどな～。昔を懐かしみつつ、調べながら何か書くか」と思いつつ、面倒になったので記憶のまま適当に書くことにしました。
Machは当時一世を風靡していたマイクロカーネル設計を採用したOSで、BSDとは全く違うOSです。
ただしBSD互換機能を利用していたユーザーは、内部に関心が無ければ
といった印象を持っていたのではないでしょうか。互換機能としては成功なのですが。
macOSのもとになったNeXTSTEPはMachを改造して始まりましたが、現在では別物であると考えるべきです。
macOSは直接にはMachから派生したもので、BSDではありません。ただし
など、BSDと誤解させる点があるのは確かです。
上記のUnix → BSD → Mach → NeXTSTEP → macOSではソースコードを利用しながらOSを作って行ったため共通の部分がありますが、これらとは全く関係無く独立して開発されたものです。
しかし現状ではNode.jsやPythonなどでプログラムを作ろうとした場合にシェルで使うコマンドはmacOSとLinuxでは共通するものも多く
ビジネスや教育現場において、ときには1000台以上のパソコン端末を管理しなくてはならないケースがあります。この際、各端末を一元管理するために用いられるのが「ネットワークブート（＝ネットブート）」です。
今回は、大学や専門学校などの教育現場にも採用されることが多い一元管理システム「ネットワークブート」の概要と導入するメリットについて紹介します。
通常、コンピューターを使用するためにはWindowsやmacOSなどのオペレーティングシステム（OS）を各端末に導入する必要があります。これに対して、情報処理のほとんどをサーバーで行い、ユーザーが操作する端末自体の処理を必要最小限にする運用方法を「シンクライアント」といいます。「ネットワークブート」はシンクライアントの方式の1種であり、構築したネットワークを通じて、サーバーからOSなどの情報を取得して起動するシステムのことです。原則、ログイン情報を打ち込むだけでネットワーク内のどの端末からでも、アプリやファイルなどの環境を再現できるため、パソコン教室に設置するデスクトップパソコンなど不特定多数が使う環境に適しており、教育機関に採用されやすい理由の1つです。
ネットワークブートと同じ意味で使われることが多い「ネットブート（Net Boot）」ですが、厳密にはネットブートはmacOSの機能の1つで、macOS Serverからの指示によって構築したネットワーク上のMacを起動・操作するシステムのことです。
この機能によって遠隔からのソフトウェアのインストールなども行えます。
ネットワークブート型と比較されることが多いシンクライアント方式の1つです。仮想環境に作成したデスクトップ環境をネットワーク環境下の各端末に転送して操作する方法で、ネットワークブート型よりもカスタマイズ性が高いことが特長です。また、ネットワークブート型よりも少ないリソースで運用が可能である一方、サーバー上で処理しなければならないのでサーバーの負荷やライセンス料が増大する傾向があります。
教育機関での利用においては、基本的に生徒は全員同じ環境で授業を受けたり、作業したりする可能性が高いため、VDI型の高いカスタマイズ性は必要ないケースが多く、ネットワークブート型が採用されることが多いです。
シンクライアントソリューションである「ネットワークブート」は、データなどをサーバー側で一元管理できるので、活用することでセキュリティ面や管理の効率化などに大きなメリットを得られます。
パフォーマンスが高い
端末側のCPU・メモリで実行するので、導入したiMacなどの性能を十分に活用できます。ネットワーク環境のPC台数が増えても、高速ブートが可能なので高いパフォーマンスが期待できます。
インストールするアプリケーションや端末側で利用する周辺機器に、原則、制限がなく使い勝手が良いのもネットワークブートのメリットです。「ローカルディスクがないPC」という感覚で利用できます。
管理が容易
詳細は導入先やシステムによって異なりますが、ネットワークブートと運用管理システムを組み合わせて一元管理することで、各端末の状態を簡単に把握できるほか、ログの採取、サーバー設定・更新の自動反映などが可能になります。これにより、少数の担当者でも運用管理が容易になるでしょう。
セキュリティの向上
近年、ネットブートが注目されている理由の1つが、セキュリティ性が高いことが挙げられます。各端末のデータはサーバーで管理するため、ユーザーが利用する端末にはデータは残りません。このため、データの流出などを未然に防ぐことができます。
これらのメリットに加えて、教育現場ではクラス替えなどがあって従来とは違う端末を生徒が使うケースでも問題なく、同じ環境で利用することができるほか、必要台数分の有料アプリケーションなどを購入すれば良いので、全生徒分のライセンス料などを払わなくて良いといった特長もあります。
ネットブート環境を構築するためには、導入先の独自のシステムとの連携や構築方法をしっかりと把握して仕様書にまとめる必要があります。規模によっては検討から運用供給まで1～2年かかるケースもあるので、ネットブート環境の構築の豊富な実績と経験がある業者選びが重要になります。三谷商事は1000台以上の大規模ネットブートを構築するなど、教育機関への導入実績を長年にわたって積み重ねています。大学や高等専門学校への導入事例をまとめているので興味のある方は確認してください。
※関連ページ：導入事例
はてブを見ていたらコメントにlinOSというのを見かけて、そんなmacOSのパクリみたいな名前のLinuxディストリビューションでもあるのかと思ったんだが、調べたがそんなものは存在しないらしい。
どうやら特定個人がlinux全般の事を指してlinOSと呼んでいるようだ。
linuxの事を連想できるし悪い略語ではないんだが、いかんせんmacOSすぎて、macが買えなくてlinuxの見た目だけ変えてmacOSを再現しようとしてるキッズぐらいにしか刺さらないんじゃないだろうか。
まあ、そんなことはどうでもよくて、
リーナス・トーバルズがGitHubについて何か言っている記事があった。
LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan
数ヶ月前の2021-09-08の記事だが、普段GitHubを使っているので問題があるなら知っておきたい。
翻訳前の原文へのリンクがわかりやすいところにある素晴らしい記事なので原文も読んでみたが、やっぱりわからない。
結局リーナスのメールと問題のコミットを見ることで、やっと問題が何かわかってきた。
それに対して、Paragon SoftwareのKonstantin Komarov氏は、3日にNTFS3のプルリクエストを送ったと回答したが、Torvalds氏の意に反して、このプルリクエストはGitHubのウェブインターフェースから送られたものだった。
まずこれが間違っている。今回のやりとりにGitHubのプルリクエストの機能は使われていない。
toshitanian Linuxはメーリングリストでマージリクエスト出すんじゃなかったっけ？って思ったら、フォーク先でGithubのPull Request使って開発してたからcommit履歴が汚くなってたって事みたい
はてブコメントにも釣られたものがあった。ちなみにフォーク先でもプルリクエストは使われていない。
https://github.com/Paragon-Software-Group/linux-ntfs3/pulls
リーナスのメールはこれだ。問題のコミットメッセージを示して、GitHubの作るマージコミットについて文句を言っている。
http://lkml.iu.edu/hypermail/linux/kernel/2109.0/03712.html
https://github.com/torvalds/linux/commit/11e4e66efd440216032f53ee7e5ca08cd263a292
Merge branch 'torvalds:master' into master
はてブを見ていたらコメントにlinOSというのを見かけて、そんなmacOSのパクリみたいな名前のLinuxディストリビューションでもあるのかと思ったんだが、調べたがそんなものは存在しないらしい。
どうやら特定個人がlinux全般の事を指してlinOSと呼んでいるようだ。
linuxの事を連想できるし悪い略語ではないんだが、いかんせんmacOSすぎて、macが買えなくてlinuxの見た目だけ変えてmacOSを再現しようとしてるキッズぐらいにしか刺さらないんじゃないだろうか。
まあ、そんなことはどうでもよくて、
リーナス・トーバルズがGitHubについて何か言っている記事があった。
LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan
数ヶ月前の2021-09-08の記事だが、普段GitHubを使っているので問題があるなら知っておきたい。
翻訳前の原文へのリンクがわかりやすいところにある素晴らしい記事なので原文も読んでみたが、やっぱりわからない。
結局リーナスのメールと問題のコミットを見ることで、やっと問題が何かわかってきた。
それに対して、Paragon SoftwareのKonstantin Komarov氏は、3日にNTFS3のプルリクエストを送ったと回答したが、Torvalds氏の意に反して、このプルリクエストはGitHubのウェブインターフェースから送られたものだった。
まずこれが間違っている。今回のやりとりにGitHubのプルリクエストの機能は使われていない。
toshitanian Linuxはメーリングリストでマージリクエスト出すんじゃなかったっけ？って思ったら、フォーク先でGithubのPull Request使って開発してたからcommit履歴が汚くなってたって事みたい
はてブコメントにも釣られたものがあった。ちなみにフォーク先でもプルリクエストは使われていない。
https://github.com/Paragon-Software-Group/linux-ntfs3/pulls
リーナスのメールはこれだ。問題のコミットメッセージを示して、GitHubの作るマージコミットについて文句を言っている。
http://lkml.iu.edu/hypermail/linux/kernel/2109.0/03712.html
https://github.com/torvalds/linux/commit/11e4e66efd440216032f53ee7e5ca08cd263a292
Merge branch 'torvalds:master' into master
はてブを見ていたらコメントにlinOSというのを見かけて、そんなmacOSのパクリみたいな名前のLinuxディストリビューションでもあるのかと思ったんだが、調べたがそんなものは存在しないらしい。
どうやら特定個人がlinux全般の事を指してlinOSと呼んでいるようだ。
linuxの事を連想できるし悪い略語ではないんだが、いかんせんmacOSすぎて、macが買えなくてlinuxの見た目だけ変えてmacOSを再現しようとしてるキッズぐらいにしか刺さらないんじゃないだろうか。
まあ、そんなことはどうでもよくて、
リーナス・トーバルズがGitHubについて何か言っている記事があった。
LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan
数ヶ月前の2021-09-08の記事だが、普段GitHubを使っているので問題があるなら知っておきたい。
翻訳前の原文へのリンクがわかりやすいところにある素晴らしい記事なので原文も読んでみたが、やっぱりわからない。
結局リーナスのメールと問題のコミットを見ることで、やっと問題が何かわかってきた。
それに対して、Paragon SoftwareのKonstantin Komarov氏は、3日にNTFS3のプルリクエストを送ったと回答したが、Torvalds氏の意に反して、このプルリクエストはGitHubのウェブインターフェースから送られたものだった。
まずこれが間違っている。今回のやりとりにGitHubのプルリクエストの機能は使われていない。
toshitanian Linuxはメーリングリストでマージリクエスト出すんじゃなかったっけ？って思ったら、フォーク先でGithubのPull Request使って開発してたからcommit履歴が汚くなってたって事みたい
はてブコメントにも釣られたものがあった。ちなみにフォーク先でもプルリクエストは使われていない。
https://github.com/Paragon-Software-Group/linux-ntfs3/pulls
リーナスのメールはこれだ。問題のコミットメッセージを示して、GitHubの作るマージコミットについて文句を言っている。
http://lkml.iu.edu/hypermail/linux/kernel/2109.0/03712.html
https://github.com/torvalds/linux/commit/11e4e66efd440216032f53ee7e5ca08cd263a292
Merge branch 'torvalds:master' into master
はてブを見ていたらコメントにlinOSというのを見かけて、そんなmacOSのパクリみたいな名前のLinuxディストリビューションでもあるのかと思ったんだが、調べたがそんなものは存在しないらしい。
どうやら特定個人がlinux全般の事を指してlinOSと呼んでいるようだ。
linuxの事を連想できるし悪い略語ではないんだが、いかんせんmacOSすぎて、macが買えなくてlinuxの見た目だけ変えてmacOSを再現しようとしてるキッズぐらいにしか刺さらないんじゃないだろうか。
まあ、そんなことはどうでもよくて、
リーナス・トーバルズがGitHubについて何か言っている記事があった。
LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan
数ヶ月前の2021-09-08の記事だが、普段GitHubを使っているので問題があるなら知っておきたい。
翻訳前の原文へのリンクがわかりやすいところにある素晴らしい記事なので原文も読んでみたが、やっぱりわからない。
結局リーナスのメールと問題のコミットを見ることで、やっと問題が何かわかってきた。
それに対して、Paragon SoftwareのKonstantin Komarov氏は、3日にNTFS3のプルリクエストを送ったと回答したが、Torvalds氏の意に反して、このプルリクエストはGitHubのウェブインターフェースから送られたものだった。
まずこれが間違っている。今回のやりとりにGitHubのプルリクエストの機能は使われていない。
toshitanian Linuxはメーリングリストでマージリクエスト出すんじゃなかったっけ？って思ったら、フォーク先でGithubのPull Request使って開発してたからcommit履歴が汚くなってたって事みたい
はてブコメントにも釣られたものがあった。ちなみにフォーク先でもプルリクエストは使われていない。
https://github.com/Paragon-Software-Group/linux-ntfs3/pulls
リーナスのメールはこれだ。問題のコミットメッセージを示して、GitHubの作るマージコミットについて文句を言っている。
http://lkml.iu.edu/hypermail/linux/kernel/2109.0/03712.html
https://github.com/torvalds/linux/commit/11e4e66efd440216032f53ee7e5ca08cd263a292
Merge branch 'torvalds:master' into master
