今でこそWindowsでも全く問題なく開発できるけど、ちょっと前は﹁Macのが開発体験が良い﹂と言われていた。具体的には2011~2015年あたり。
2013年のころ、俺はWindowsで開発していた。WSL2なんてものは当たり前に存在しない時代だ。 ~~たとえばC言語を使いたい場合、MinGWとMSYSを使ってこんなかんじで必要なものにチェックマークをしてインストールしていた。~~ まちがえた。俺が使っていたのはCygwinだ。こんなかんじでインストールする。﹁パスを通す﹂とか言われていた時代だ。今ではインストーラがほとんどやってくれる。 Windowsのコマンドプロンプトがアホほど役に立たないので、m~~sys~~Cygwinのコンソールを使うのだ。 Pythonのインストールにもパスを通していた時代だった。当時はまだ2系が主流で、卒論を書く際、大学の教授から﹁3系は使ってもいいけど、俺は知らないからサポートできない﹂と言われた。 Scipyはインストールしなければ使えなかったので、﹁python scipy インストール﹂で検索して出てきた記事を参考にしてインストールしていた。これがまたエラーの連続だった。
プログラムを開発するエディタも、vim、emacsがまず候補に上がった。どちらも癖のあるエディタなので、そういうのが嫌な人はサクラエディタが推奨されていた。そして少しして登場するAtomに感動したのだ。今ではあたりまえのようにVSCodeがある。ちなみに俺はPythonの開発ではIDLEというのを使っていた。知ってる？こんなの。
そんなWindows ユーザーを少し煽るような︵Win ユーザが自虐するような︶、﹁プログラミングするならMac﹂という風潮があったと記憶している。そこから﹁どうやらMacはUnix系で、コンソール操作が簡単らしい﹂﹁文字がきれい﹂﹁Windowsでは定期実行するためのcronすらないが、Macにはある﹂﹁xcodeというのがあるからめちゃくちゃプログラミングがラクらしい﹂みたいなイメージがあった。今ではWindowsも随分便利になったし、IDEやインストーラがなんでもしてくれるようになった。今では結論、﹁どっちでも好きなほうを使えばいい﹂という良い環境になった。 Permalink | 記事への反応(4) | 17:29

2023-12-27

■anond:20231227222447

なんでもいいけどAppleはキャッシュ管理もまともにできないXcodeとかいうゴミを早くなんとかしてくれ

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

2023-11-02

■anond:20231102103303

OSとマシンを一体で開発するのはいいんですけどそれなら開発環境もちゃんと一体で開発して

Xcodeとかいうゴミカスうんちをまともにファイルシステムとキャッシュが扱えるちゃんとしたツールに作り直してくれませんかね

Permalink | 記事への反応(2) | 10:34

2023-10-30

■anond:20231030153025

これよくあるなぁ。自分でXvideosと言っていることに気が付かないからずっとそういい続けてしまう。困ったもんだ。＞XcodeのことXvideosって言う Permalink | 記事への反応(0) | 15:46

■何気ない日常で起きる言い間違え（と、その後の対応）

・上司をお母さんと呼んでしまう（普通にすいません、と謝る）

・XcodeのことXvideosって言う（噛みました、Xって言いにくいですよね…とごまかす）

・妻に向かって初恋の人の名前で呼んでしまう（顔面蒼白になる）

あと一つは？

Permalink | 記事への反応(2) | 15:30

2023-10-29

■anond:20231029155904

ああああああああああああああああああああああああああああああああああああああああ

Xcode ごみごみごみごみごみこんなゴミでビルドさせんなカスカスカス

Permalink | 記事への反応(0) | 15:59

2023-10-26

■

Xcodeとかいうごみごみごみごみクズクズクズクズかすかすかすかすうんちうんちを出している会社の製品をプライベートで絶対使いたくない

キャッシュもファイルシステムもまともに扱えないビルドもロクにできないゴミの使用を強制するな

Permalink | 記事への反応(0) | 20:53

2023-07-24

■anond:20230724232732

ワイはXCode・Androidstudio・Visualstudioくらいしか使わんやで

Permalink | 記事への反応(1) | 23:39

2023-05-25

■

VisualStudio ネイティブ勢から見たらそうかもしれないんだけれども、MacBookやLinuxに慣れた人から見たらその環境を強制されるだけでモチベーションダダ下がりなのは事実で、だからこそMSもdotnetをLinuxやmacで使えるようにしたり、VSCodeよくしたり、VS for macを作ったりしている。 https://t.co/HIg2LBUFsT— Naoki 🇺🇦🇯🇵 (@methane) May 25, 2023 Windows嫌いのまかーってXcodeとかのこと棚に上げるよな iOS appをWindows, LinuxでSigningまでできるようにしてから言え Permalink | 記事への反応(0) | 14:07

2023-04-06

■anond:20230406195428

ワイはアプリデバッグでiOS12のiPhone5s使ってるやで

去年はiOS9のiPhone4S使ってたけどとうとうXCodeが非対応なったやで

Permalink | 記事への反応(0) | 20:05

2022-12-30

■入院で必要だったもの・不要だったもの

2022年ももうすぐ終わり。今年は個人的には1ヶ月間ほど入院してたので残念ながら成果物は少なめ。その代わりに、入院に際して必要だったものなどを挙げておきたいと思う。将来入院する誰かの役に立てれば幸い。

増田のスペック

●40代中盤・男 ●フリーランスのプログラマ兼サーバ管理者 ● 呼吸器系の重めの病気持ち︵コロナではない︶ ●2022年中に2回入院した。2回の入院先は別々で、1回目は2泊、2回目が1ヶ月。前年までの入院歴は無し。 ●いずれの病院でも、コロナ禍という事情により、入院中の外出や面会は厳禁なので、持ち込んだ機器等が故障したらそこで試合終了。 ●関東地方で一人暮らし︵天涯孤独︶

持って行って良かったもの

●ノート PC : 入院中もコードは書くので当然。2病院とも鍵付きのロッカーが備わっており、A4サイズのものは余裕で入った。離席中はPCはそこに保管。冗長性などの都合から3台持って行ってた。充電設備は二重化。 ●Nintendo Switch : 常にコード書くやる気に満ち溢れているとは限らず、休息は必要。また、ゲームプレイ中はお腹の減りが遅いということを活かし、空腹を紛らわすためにもゲームは必要。ゲームには冗長性は無し。 ●アクション系︵Splatoon等︶、すなわち高い集中力を要するソフトは、空腹を紛らわすのに最適。通信回線の問題はどうにかする必要あり。スタンドアロンで動作するアクション系ゲームとしてBiohazardを持って行ったけども、病院でプレイするものではなかったｗ ● 非アクション系︵どうぶつの森等︶は、コントローラの操作音が静かになりがちなので、夜間のプレイに最適。﹁どうぶつの森﹂はアクションゲームだという説はあるかもしれないが、夜間の激しい操作は控えよう。 ●Switchのドック＋14インチのモバイルディスプレイ : 快適なゲーム環境が得られた。肩こり防止にも最適。快適すぎて夜中までプレイしてしまい、同部屋の爺さんに光害を与えてしまったほどｗ︵申し訳ない m(__)m︶なお、モバイルディスプレイは当然ながら、PCのサブのディスプレイとしても利用可能で、とても有益だった。 ●Switchのプロコン : 自分には必要だった。Splatoonには必須で、他のゲームにおいても肩こり予防には良かった。 ●海外仕様のiPad : 写真を撮る時に音が鳴らないので、病室で食事の写真を撮るのに便利。良い子のみんなは悪用しちゃダメ。 ●SIMを2枚差しできるモバイルルータ : NEC製のAterm ブランドのルータに、mineoの﹁マイそく﹂プランに加入している2枚のSIM︵docomo版とau版︶を挿して持って行った。通信障害があっても安心。今年発表された﹁マイそく﹂は神サービス。なお、ルータ故障の際の備えとしてはiPhoneがあったが、iPhoneのSIM スロットを開ける純正の工具を持って行くのを忘れたので焦った。ルータは故障しなくて助かった。 ●なお、マイそくプランにおいては、330円/24 時間を支払うと﹁24時間データ通信し放題﹂にできる。これには数回ほどお世話になった。OSやXcode等のアップデート等の際は活用させてもらった。 ●旅行用の歯ブラシ : 近年の旅行用歯ブラシセットは、セミハードケース︵？︶で通気孔が備わっており、乾燥させるのに便利。昔のものとは違うので、良いものを買おう。自分はほとんど旅行をしないので、文明の発達に気付くのが遅れた。 ●サンダル : ちょっとトイレとかに出る時に使うやつ。会社員で物理出社してた時代にオフィスで使ってたものを持って行った。オフィスと同様に、転倒防止の文脈で﹁かかと﹂を有する製品であることが求められた。 ● 電源タップ : 必要。 ●健康保険の限度額適用認定証 : 敢えて出さずに全額をクレカで支払ってキャッシュバック︵健康保険の高額医療費制度のもの＋クレカのもの︶を受けるという技もあるようだが、1ヶ月も入院するとなると、流石に出していた方が安心︵クレカの限度額を超えた時にタヒぬので︶ ●ちり紙 : 呼吸器を病んでる者としては、やはり超重要アイテム。院内のコンビニだとかなり割高︵1箱ずつの販売なので︶ ●100円玉を沢山 : コインランドリーで使う。 ●タッチ決済のできるクレカ : PASMO / SUICA は途中でチャージが枯渇するので、院内コンビニでの買い物はタッチ決済のクレカが良かった。

持って行ったけど不要だったもの

● 冬物の寝巻き : ︵冬場の話︶自宅とは違って、自分が入院した病棟内の室温は22℃以上に保たれていたので、自分は半袖Tシャツ・ハーフパンツで良かった。無駄な荷物を持って行ってしまった。 ●カロリーメイト : 好き嫌いが激しいので念の為持って行ったが、栄養士㌠が、アレルギーや病状だけでなく、好き嫌いの要望にも配慮してくれたので、食事はほぼ全て美味しく頂くことができた。

持って行かなかったけども欲しかったもの

●フロアマット : 椅子に座っている時やスタンディングデスク等で作業するとき、裸足の方がずっと快適だけれども床に直接というのは衛生的に疑問があるので、洗濯可能なマットが欲しい。タオルで代用可能で、自分は院内のコンビニで購入した。 ●骨伝導方式のヘッドフォン : 普通のイヤフォン等を持って行ったけども、長時間付けてると耳が痛くなったりした。聴力的にも良くなさそう。 ● 紙コップ : 歯磨きするときに必要だった。院内のコンビニで調達できた。 ●ストレージ容量の大きなiPad等 : 事前にダウンロードしておいた映画等をベッドで見たい。 ● 激しく打鍵しても静かなキーボード : 夜間のプログラミングのためには、こういう設備を整えておきたかった。

﹁これは不要かな﹂と思って、やはり不要だったもの

●耳栓 : 当方はそんなに金持ちではないので、入院する病室は4人部屋。当然ながら他人の生活音がきっちり聴こえるけれども、幸いにして音には鈍感なので自分には耳栓は不要だった。よく必要なものリストに挙げられるけどね。 ●書籍 : 寝ながら本を読むのは、10分とかが限界。分厚い技術書の物理書籍なら尚更。また、いくら音に鈍感とは言っても騒音環境下での読書だけは厳しい。︵ここで耳栓が活躍するのかもしれないけども…︶

その他

入院するにあたっては﹁保証人﹂を求められるけれども、自分にはそんな人は居ない。以前であれば自分のような人間は治療を拒絶されていただろうが、数年ほど前に厚労省が﹁身寄りがない人の入院及び医療に係る意思決定が困難な人への支援に関するガイドライン﹂を発表したことで、治療が受けられるようになった。 https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/kenkou_iryou/iryou/miyorinonaihitohenotaiou.html 本件に関わった厚労省の方、そしてこのガイドラインに従って入院させてくれた病院の皆さんに心より感謝したい。 Permalink | 記事への反応(0) | 09:08

2022-09-22

■

ああ～いやじゃいやじゃ～

MacもXcodeも触りたくないんじゃ～

いやまあMacは、使い勝手だけはなんとなく気持ち良さがあるから許せる（でもApple 信者が言うほど安定してねえな・・）

Xcodeは致命的にいやじゃ～

みんな何がよくてiPhoneなんて使いたがるの・・・アプリ作る側は地獄見てんよ？？？

あーくそストレス溜まる

いっその事、俺もApple 信者になれば楽になるんだろうか？

いやこれ無理でしょ笑

信者は一体何がきっかけで信者になったんだ？？？

Permalink | 記事への反応(1) | 14:30

2022-09-21

■

俺氏「Visual Studio 2022 のインストールに2時間もかかったわｗ

　　デスクトップアプリとマルチプラットフォームアプリ、あとUnityの環境整えたいだけなのにｗ

　　まあSSDの容量が心許なくてHDDにインストールしてるのも敗因だろうが

　　こんなに時間がかかるIDE、他にあるか？ｗ」

？「あるさっ！ここになっ！」

俺「その声は・・！」

Mac ユーザー「Xcode ！！！」

俺「やめろ！無理するな！」

Mac ユーザー「トータルで2日がかりだーーっ！！！」

俺「やめろーーーっ！！！！

Mac ユーザー「ぐはあああーーーっ！！！」

俺「うわああああーーーっ！！！」

全　員　死　亡　！

Permalink | 記事への反応(0) | 13:08

2022-08-11

■anond:20220811210806

それはどういうプログラミングするかにもよるやん

WindowsPCで動くもの作りたいならVisualStudio入れてC#でどうぞやし

スマホで動くもの作りたいならAndroidStudioかXcodeやし

どういうもの作りたいかも聞かずプログラムはサーバーやWEBで動くものと決めつけるのがおかしい

「プログラマをエンジニアというな」ってのは耳たこやろうけど

「プログラマはWEB系やってる人ばかりではない」というのも周知すべきやと思うやで

Permalink | 記事への反応(1) | 21:21

■anond:20220811210008

CLIもIDEも必要に応じて学べばええんやで

どっちも種類によって使い方も違うんやし

UNIX系OSでバックエンド開発しようとしてる人に「XCode インストールしてください」「AndroidSDKの仕様学んでください」はおかしいのと同様に

Androidアプリ開発しようとしてる人に「UNIXのCLIの使い方を学んでください」「laravel環境構築してください」はおかしいんやで

Permalink | 記事への反応(1) | 21:12

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という新しい沼へギークの皆さんをご案内しているに過ぎないのだ。 Permalink | 記事への反応(10) | 15:50

2022-04-16

■ついにMontereyにした

最新のXcode から Big Surが未対応になり、渋々上げることとなった。問題なのが、マシンがハッキントッシュである事だ。興味本位で手を出したハッキントッシュだが、OpenCoreのバージョンが上がる度に試すような熱心さはなく、動いてるしいいや位の完成度で使っている。Debug版を使い続けてるし、OpenCanopyなど楽しいものも入れてないカジュアル野郎だ。　まずそのままでも動くかなと思って試してみたがダメだった。ブートメニューにMontereyのインストーラーが出てこない。 OpenCoreのバージョンを最新にし、sample.plistを参考に設定を更新して再トライ、さらにkextも更新してまたトライ。やっぱりダメ。ブートループやフリーズが起きる。　 ocvalidateの存在を知ってからは簡単だった。 sample.plistとのにらめっこで見逃した項目を潰したらすんなりとアップグレードできた。このコマンド前からあった？何はともあれ、めでたしめでたし。　それにしても、OpenCoreでもCloverでもそうだけど、開発してる人はすごいなあと思う一方、何のためにやってるんだろうと思う。 OpenCoreの作者︵複数？︶は寄付したいならその金チャリティーに送れとすら言っている。ハッキントッシュの為のツール開発なんて永遠に日の目を浴びないだろうし、ただの好奇心が原動力だとしても多くの構成のマシンに対応する意欲に繋がるだろうか。そこには執念とか、使命感とかいうものを感じざるを得ない。競合他社による営業妨害の可能性もあるが、熱量や発覚リスクを考えると流石にないかとも思う。 Permalink | 記事への反応(0) | 11:12

2022-03-08

■anond:20220308200056

2年くらいはビルドしていないので最新のXCodeでビルドができない

月単価100万超えるんで業務委託でなく、開発請負会社探したほうがいいよ

Permalink | 記事への反応(0) | 20:07

「xcode」を含む日記

■ちょっと前は「プログラミングするならMac」という風潮が確かにあった