北極圏コード貯蔵庫コントリビューター -Arctic Code Vault Contributor-

GitHub が北極圏にデータセンターみたいなのをつくって、そこに GitHub 上にあるほぼ全てのリボジトリのスナップショットを収蔵したらしい。
【参考】『Arctic Code Vault が実施段階へ突入』(GitHub ブログ)

MS すげーな。

また、このとき収められたリポジトリのオーナーやそれらプロジェクトにソースコードを(正式な形で)提供した者には、

Arctic Code Vault Contributor

の肩書きが与えられたようだ。「北極圏コード貯蔵庫コントリビューター」とでも訳せばいいだろうか。

私も OsiriX や Horos にはソースコードを提供したことがあるので、認定されたようだ。
大したものではないが、ちょっとは誇らしい気持ちになれる。

最近(2021 上半期)だと専用ロゴ?もついた。

air-h-128k-il

 

システムクラフトとかいう会社が出鱈目な情報を流している件

システムクラフトという会社の杉原利彦という人が X などで出鱈目な情報流しているようだ。

時期的には少々古いのだが、下図上部のようなポストがあった。

2018 の時点で OsiriX MD は既にオープンソースではなくなっており、プルリクエストなどを送りたくても送れないし、あちらにはあちらで立派な日本語リソースがある。

私が提供した先は、オープンソース版の方で、これはリポジトリ上にも痕跡が残されている。

どういう内容だったかは、このページなぞ参照。

大した内容ではないのでアピールしてないが、このプルリクのおかげで contributors の一人には数えられているようだ。

OsiriX は医療分野におけるオープンソースソフトの代名詞のように考えられていたようだが、実際、ある程度まとまった内容のソースコードを提供したのは pixmeo 関係者以外では、上図でわかるように世界で 9 人くらいしかおらず、これでは(商用版を)オープンソース開発方式を継続していく意義は薄いだろう。

ところで OsiriX MD がオープンソース開発方式を捨てて、ソースコードをクローズドに移行した際に、落胆の声が上がったようだが、これは若干筋違いの批判のように思えなくもない。

オープンソース開発方式を望むなら、現在のオープンソース版にプルリク送るなどして、クオリティを上げていけばいいだけの話だからだ。

 

(追記)OpenDolphin という名称使用に関しても完全に間違った解釈してますね。

【魔改造】Surface Laptop GO 3 【SSD 128G→1T】

おかげさまで Surface Pro 7 + の SSD 換装の記事がよく参照されている。

今では Surface のエントリーモデルの SSD を換装するのは、けっこう一般的に行われるようになったようだ。

今回は Surface Laptop GO 3 の SSD 換装。

まずは、Surface 公式が SSD の取り外し方を解説してくれているのでチェック。

底面のゴムを取り外すところに心理的な抵抗を覚えるかもしれないが、やってみるとわかるが、かなり取り外しやすい接着になっている。

Surface Pro よりは若干手間かかるが、やはり SSD の交換はやりやすい。

基本的なやり方は前回と同じです。

つまり、

回復ドライブ(USB)制作→SSD換装→回復ドライブから起動

です。

Surface Pro と違うのは、UEFI 設定に入る時には、F4 キーを押しながら電源ボタン投入です。

 

 

 

Galaxy Fold 3

老眼のせいでそろそろコンパクト機が辛くなってきたので、大画面機か折りたたみ機の導入を検討。

実は「折りたたみスマフォの元祖」初代 Galaxy Fold は所有していて、室内でタブレットのように使ってはいた。

その重量や機能(お財布携帯機能はない)から外に持ち出すことはしていなかったが、ここらへんがクリアになっているならば、ありだとは思っていた。

調べたら Galaxy Fold3 から、おサイフ携帯機能には対応しているらしく、中古市場でお手頃価格(10万以下)になっているようだ。

物色していたら、7 万台の中古が出ていたので、結局、購入。

見ての通り、s20 -> fold3 のデータ移行もおおよそ済ませたのだが、ここら辺バタつくのがいつもの galaxy クオリティ。

Smart Switch というアプリを使えという。
USB-C 端子同士をケーブルで繋げるか、同一 WiFi 経由でデータを移行してくれる。
ケーブルで移行するのが確実なんだろうが、S20 の USB 端子が摩耗でほぼ使えないので、断念。
ならば WiFi 経由で、ということになるが、セットアップしたら、「高速転送のために WiFi は使いません」とかいう指示が出る。
ユーザー、舐めてる?
最初に「Smart Switch というアプリを使うと転送が楽です。Smart Switch は galaxy 同士ならば、WiFi も不要です」と案内しておけばいい話ではないか。
またデフォルトでは、S20 の SD カード内のデータは移行できない。(なお、Fold 3 に SD カードはない)

まあ、端末自体には満足しているので、Spigen のケースと S ペンもアマゾンで購入。

 

レビューは気が向いたら、するかも。

えーと、やはり重い (^^;)

ただ、これ、Spigen のケースがしっかり作られすぎていることも原因の一端になっているとは思う。
Spigen ケースは両面テープで本体に接着することにはなっているのだが、精度がそれなりに出ているせいかテープなしでもズレることはないと思う。
強度を出すためか肉厚でもある。2階から落としても衝撃吸収してくれるんじゃないかってくらいガッチリ作られている。
だから、薄くするといい感じになるかもしれない。

アプリの移行

モバイル SUICA

基本的には

旧端末で SUICA をサーバに預ける
→新端末で同一アカウントでログインし受け取る

という理屈らしいのだが、手順通りやっても「他の端末で利用中の Suica のため、当該 Suica は受け取れません」というエラーが出る。

android の場合、日を跨ぐと受け取れる。だからこれはエラーではなく仕様といった方がいい。

メッセージの表現といい、仕様自体といい、なんかモヤっとする。

PowerAmp

買い直すことなく使えている。これは good。

 

(続く)

 

いまさら? Windows 11 と Ubuntu ダブルブート

WSL 環境が整備されてきたせいか win機で Ubuntu を使いたい場合、WSL(2) をインストするのが主流になってきていると思いますが、通信に関してはまだ不安定なところがあるように思います。

さらに Ubuntu のデスクトップ環境を使いたいといった場合(WSL ではデスクトップ環境は使えない)、今でもデュアルブートは考慮される選択肢でしょう。

以前に SSD を換装した Surface があったので、デュアルブートを試みました。

作業に入る前に

UEFI が強化されているらしく、意外に手間かかります。

途中で何かあってもいいように、最低

・回復ディスクは作成しておく

・BitLocker は切っておく

ことを強くオススメします。

これさえやっておけば、何があっても最悪、システム自体は復旧できます。

手順

作業の手順は検索かけて物色しましたが、けっこう不自然な手順が紹介しているサイトを見かけました。

おそらく最も自然なのは

windows10 と Ubuntu のデュアルブート環境の構築

で紹介されている方法です。

windows 機に Ubuntu を間借りさせるわけだから

・windows のユーティリティを使って空き領域を作る

・その空いた領域に Live USB を使って Ubuntu 本体をインストールする

という手順です。

ただし、win10 時代には SSD 自体を暗号化する BitLocker がなかったようで、この点に関する配慮が抜けています。

私も作業に入る前はわかってなかったのですが、BitLocker はパーティション毎にオンオフできるものではなく物理的なディスク全体を暗号化するもののようです。
だから、windows OS の領域を空けたところで暗号化自体は有効なので、そこに Ubuntu をインストールしてしまうと Ubuntu はその領域を読み込めない(=起動できない)、という結構ヤバめの状態になります。

使い心地 -どういう人に向いているのか-

私の場合、 Surface のエントリーモデルを SSD 換装して使うことが多いので、仮想化して Ubuntu を使うのは辛いものがあります。

このような場合、デュアルブートは快適です。

現在(2024 春)なら、Surface Laptop GO 3 なんかは、いい対象になると思います。→ UEFI の設定のせいなのかデュアルブートはできないようです。結構な人が試しているが、未だ成功例はないようです。こことか参照。

実用的な速度で使いたければ WSL。少々遅くてもデスクトップ環境欲しければ VM Player 使うしかないですかねー。

 

 

イマドキの JavaScript

JavaScript といえば、html などと組み合わされクライアント(ブラウザ)上でページを動的に動かすための言語、とされていた。

かつては。

node が開発され、そういった状況は一変したわけだが、いまだに「node はサーバサイド JavaScript の一種」というイマイチな説明がなされているサイトも多いようだ。

node は JavaScript 実行環境

node.js は JavaScript 実行環境といった方がいい。

試しに

console.log("hello, node");

という簡単なスクリプト?をコマンドラインから実行してみよう。

 としっかり Mac マシン上で動く。

私の場合、node はいつの間にか入っていたが、Mac に導入したい人はこちらあたり参照。
(入っているかわからなければ node -v を実行。バージョンが返ってくれば入っている)

npm は Node Package Manager ではないらしい

node といえば npm だが、npm は Node Package Manager の略ではないらしい。この記事参照。
が、こういう言葉遊びに拘泥するのが面倒くさいと感じる人はスルーで。

文法も進化している

ES2015(ES6) あたりで、文法も大きく変わったようだ。
ES2015(ES6)入門

(続く)

 

Metal Shading Language

MacOS, iOS などの新しいグラフィック API といえば Metal だが、Mtal のシェーダーを記述する言語は、Metal Shading Language (MSL)という。

現在のバージョンは 3.0 で仕様も公開されている。

C++14 ベースというのは聞いていたので、クラスやメソッドなどを C/C++ や Objective-C あたりで書いておけば、シェーダー(具体的には .metal ファイル)から特別な手続きなしに呼び出せるのだろうと安直に思っていたのだが、どうやら違うようだ。

これはなかなか困った事態だ。

というのは、ある種の機能はシェーダーからも普通のコードからも使いたい、ということがよくある。

大抵は、こういった共通に使うような機能は C/C++ などで書いておけば、それほど困った事態にはならないのだが、これが必ずしも成立しないということを意味している。

StackOverFlow にもこの手のお困り質問が見られるようになった。

(追記)公式にも .metal で複雑な操作(例えば複数の .metal を使いたいような場合)をするときには、一旦、シンボルファイルを作って… という記事が上がっていた。
いや、しかし、これ本当にさせるつもりあるの???

C++ に似ているが C++ 標準ライブラリは使えない

仕様書の最初の方にも

Do not use the C++ standard library in Metal code

と早々と警告を発している。

標準ライブラリの他にもラムダ式も使えない。

 

参考:
これ
海外でもやはり。。。

(続く)

小山哲央(当時アーク情報システム所属)の誹謗中傷 tweet について

こういう記事は気分の良いものではないので書きたくもないが、一応、ご報告ということで。

以前に小林慎治という人が OpenDolphin-2.7m および OpenOcean について出鱈目な記事を書いて公開していたのだが、当時の所属先から疑義照会を受け、当方の知りうる限りでの回答をさせてもらったところ、事実と異なる根拠に基づいて書かれていると判定されたようで、その所属先の上司の方からかなり丁寧に謝罪してもらったという件がある。(『保健医療科学院 小林慎治が国家公務員法違反疑いで厳重注意を受けた件について』参照)

事態がこれですんでれば、この話はおしまい・・・

になるはずだったのだが、そうもいかなかった。

問題となった記事にさらに個人的推察を付加して、ツィートした人(小山哲央という人)がいたようなのだが、内容がかなり悪質だったため、(ツィート時点での)所属先および当人に問い合わせた。
結果、「事実関係を把握していないで、軽率なツィートをした」旨の回答をもらい、謝罪してもらった(ただし法的な意味での和解はしていない)。

個人的に凄まじく変に思ったのは(このアカウント自体、共同アカウントだが、総人のコンセンサスとして、程度の意味合い)、問題となったツィートが 2019 年のものだったこと。

2019 といえば、

・当時の開発元の LSC 自体が OpenDolphin を GPL ではライセンスしなくなった

・ソースコード上で、それまで開発者とはされていない人の署名が見つかり始めた

時期で、ちょっと調べれば、前提となっている認識を持ちようがないように思えたからだ。(まあ、だから、当方関係者もつい最近まで見落としてたんだと思うんだが)

しかし、オープンソース「信者」みたいな人の言い分には、本当に辟易させられる。
実際のソースコードにあたれば、自分の主張が間違っていることに気がつくはずなのに、その作業を怠っているからだ。
特に、誰かを批判するような場合、検証は十二分にやらなければいけないでしょう。

いったい、何のためにソースコードが公開されていると思っているのだろうか?

(追記)第2ラウンド開始、みたいになってます。

(追記2)「実際のソースコードにあたれば」云々と書いたが、ひょっとするとこの小山哲央という人は能力的にできなかったのかもしれない。
経歴は、東京理科大建築系大学院修士(地震工学)→アーク情報システム(数理解析業務)なのだが、いわゆる建築系の FEM(有限要素法)ソフトの操作がもっぱらのようで物理系の人が取り扱うような汎用的な FEM をガシガシ取り扱っているわけではないようだ。
当然、Java の経験もほとんどないようで、かなり懇切丁寧にどこで間違ったか教えたはずなのだが、まったく理解できていないようだった。
もしそうなら、このような物言いはやめるべきだ。
自分が判断できないようなことをさもわかっているかのように振る舞い、他者を一方的に批判するのは社会人として最低限のマナーが身についていないからだ。

 

OpenDolphin Ver 7

ちょっと前に OpenDolphin Ver6OpenDolphin-2.7m の JakartaEE 9.1, Java17 対応版)を関係者向けにリリースしたのだが、先ほど WildFly の公式ページをチェックしたら、27 が使用可能となっていた。

これは動作チェックが必要になってくる。

というのは、WildFly 27 は完全な JakartaEE 10 対応のアプリケーションサーバで、あるサーバープログラムが JakartaEE 9.1 環境で動作していたからといって必ずしも JakartaEE 10 環境で動くとは限らないからだ。

Java の EE 環境は、長らく JavaEE 8 が続いていたのだが(停滞しているという声も多かった)、ここにきて機能の追加が加速している感じである。

ついででいっておけば、WildFly 26 までは、Jakarta EE 8 にも対応していたから、Java EE 8 にしか対応していない古いウェブアプリであっても、基本的には動くはずである。
ここらへんは、JavaEE → JakartaEE の移行に伴う配慮でしょう。

試しに Ver 6 に若干手を入れて WildFly 27 に投入。

デプロイは問題なくできているようだ。

ちょっと気になるところもあるが、機能的にも大きな問題なく動きそう。

なお、「ちょっと気になるところ」というのは主に hibernate が動作するところ。

JakartaEE 9.1 で問題なく動いた箇所でエラーを吐いたりする。

本格的な JakartaEE 10 対応は、もうちょっと待ってからでもよさそうだ。

 

 

1台の Mac でマルチアカウントで homebrew を使う

為替の関係なのか apple 製品値上げしそう。

というわけで現在主流である arm 系の Mac をホイホイ買うことが難しくなった。

そうなると当然1台の Mac を複数人で「仲良く」共有ということになる。
本当にできるかどうかは別にしてw

ちょっと引っかかったのは Mac の定番パッケージマネージャー homebrew を複数アカウントで使うとパーミッションの関係で色々と不具合が出るという問題。

ググってみたが、「個々のアカウントのホームにそれぞれ homebrew をインストールする」というのが一番シンプルな解決法のようだ。

なので、ホームに homebrew フォルダをつくり、そこに homebrew を展開して使ってもらうことにした。

$ cd ~
$ mkdir homebrew
$ curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew

これに合わせて、.zprofile に以下の一行を追加。

PATH=~/homebrew/bin:$PATH

本来の brew コマンドより「優先して」自分の brew コマンドが動くようにする、という理屈ですね。