2021年12月30日木曜日

スパコーン 77TB の件

https://www.itmedia.co.jp/news/articles/2112/29/news040.html

TL上でもチラチラ見かけた件。原因となった挙動、bashソースコードのこの部分だねというのも出てた気がする。むかーしからなんだろうか。

実行中に書き換えたり cp したりしようなどと思ったことはなかったので、bash は実行時に適時読み込みますという記述で初めてこの挙動を知った。いやはや。

お〜確かにそうだねという↓これは sleep 中に、ささっと別ターミナルで  hoge!! 部分を fuga!! と書いた fuga.sh を cp  。Fedora 35 で。

$ cat hoge.sh; echo; bash --version ; bash -x ./hoge.sh ;echo ; cat hoge.sh
sleep 10
echo "$0: hoge!!"

GNU bash, バージョン 5.1.8(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
ライセンス GPLv3+: GNU GPL バージョン 3 またはそれ以降 <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
+ sleep 10
+ echo './hoge.sh: fuga!!'
./hoge.sh: fuga!!

sleep 10
echo "$0: fuga!!"

 

zsh の場合

$ cat hoge.sh; echo; zsh --version ; zsh -x ./hoge.sh ;echo ; cat hoge.sh
sleep 10
echo "$0: hoge!!"

zsh 5.8 (x86_64-redhat-linux-gnu)
+./hoge.sh:1> sleep 10
+./hoge.sh:2> echo './hoge.sh: hoge!!'
./hoge.sh: hoge!!

sleep 10
echo "$0: fuga!!" 

長いスクリプトだと違ってきそうな? zsh で -x だとスクリプト名も入る、というのをついでに知れた。

 

追記: FreeBSD 13 の "sh" で何行か echo させてみると冒頭は hoge で途中から fuga 。上のそのままにその後適当にecho

echo "01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee"
(中略。20まで。)

echo "20:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee"

で実行中に裏で cp すれば途中から変わった。

$ head -2 hoge2.sh ; echo ; sh -x ./hoge2.sh
sleep 10
echo "$0: hoge!!"

+ sleep 10
+ echo './hoge2.sh: hoge!!'
./hoge2.sh: hoge!!
+ echo 01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

(略)

+ echo 17:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
17:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 18:hugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
18:hugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ echo 19:fugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
19:fugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ echo 20:fugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
20:fugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

↑の18: のところ。1024文字(バイト)っぽい。

(パッケージの) zsh だと変わらず、hoge 。どうなってるかはあとはコード見るのが早いな。

どことなく、昔あった BSD magazine の「デーモン君のソース探検」っぽさを感じた。「うわーん、実行中のスクリプトをコピーして置き換えたら何たらかんたら・・」で、パパが「どれどれ、では sh のソースを見てみようか」的な。いやまぁ、そもそもそんなオペレーションをするなという話ではあるけど。。学びがあるね。


さらに追記: OpenBSD 7.0 の、"ksh" ( /bin/sh が /bin/ksh )

$ ksh -x  hoge.sh
+ sleep 10
+ echo hoge.sh: hoge!!
hoge.sh: hoge!!
+ echo 01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

(略)

+ echo 09:hogeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
09:hogeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ echo 10:fugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
10:fugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

ホゲーーーが途中から ホゲーーーああああになった。512文字(バイト)。

・・・じゃ、Fedora 35 の ksh 。

$ ksh --version; ksh  -x  hoge.sh
  version         sh (AT&T Research) 93u+m/1.0.0-beta.1 2021-05-10
+ sleep 10
+ echo 'hoge.sh: hoge!!'
hoge.sh: hoge!!
+ echo 01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
 (略)

+ echo 18:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
18:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 19:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
19:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 20:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
20:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

hoge のまま。

$ rpm -qi ksh
Name        : ksh
Epoch       : 3
Version     : 1.0.0~beta.1
Release     : 1.fc35
Architecture: x86_64
Install Date: 2021年12月30日 08時41分02秒
Group       : Unspecified
Size        : 3166151
License     : EPL-1.0
Signature   : RSA/SHA256, 2021年08月03日 12時24分51秒, Key ID db4639719867c58f
Source RPM  : ksh-1.0.0~beta.1-1.fc35.src.rpm
Build Date  : 2021年08月03日 12時08分15秒
Build Host  : buildvm-x86-08.iad2.fedoraproject.org
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://www.kornshell.com/
Bug URL     : https://bugz.fedoraproject.org/ksh
Summary     : The Original ATT Korn Shell
Description :
KSH-93 is the most recent version of the KornShell by David Korn of
AT&T Bell Laboratories.
KornShell is a shell programming language, which is upward compatible
with "sh" (the Bourne Shell)

 

では今度はFreeBSDの ksh パッケージをば・・と思ったが ksh オオスギィ!

$ pkg search ksh|grep Korn
ast-ksh-20141224_1             KornShell 93
ksh2020-2020_1                 Development branch of AT&T KornShell 93
ksh93-93.u_1,2                 AT&T KornShell 93
ksh93-devel-2020.06.30         Development branch of AT&T KornShell 93
mksh-59c                       MirBSD Korn Shell
oksh-6.9,1                     Portable OpenBSD Korn shell
pdksh-5.2.14p2_6               The Public Domain Korn Shell

まぁ oksh が OpenBSD のそれと同じ挙動でしょう、と予測し答え合わせ。

$ oksh -x hoge2.sh
+ sleep 10
+ echo hoge2.sh: hoge!!
hoge2.sh: hoge!!
+ echo 01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
(snip)

+ echo 09:hogeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
09:hogeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ echo 10:fugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
10:fugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

正解。

以下 pdksh と ksh93

$ ksh -x  hoge2.sh  
+ alias h=fc -l
+ alias j=jobs
+ alias m=less
+ alias ll=ls -laFo
+ alias l=ls -l
+ alias g=egrep -i
+ sleep 10
+ echo hoge2.sh: hoge!!
hoge2.sh: hoge!!
+ echo 01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee 

(中略)ところで alias が出てくるの何・・・?

+ echo 09:hogeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
09:hogeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ echo 10:fugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
10:fugaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

 

$ ksh93 -x hoge2.sh  
+ sleep 10
+ echo 'hoge2.sh: hoge!!'
hoge2.sh: hoge!!
+ echo 01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
01:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
02:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
03:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

(中略)

+ echo 18:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
18:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 19:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
19:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+ echo 20:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
20:hogeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee


$ pkg info -f oksh pdksh  ksh93
oksh-6.9,1
Name           : oksh
Version        : 6.9,1
Installed on   : Fri Dec 10 03:35:22 2021 JST
Origin         : shells/oksh
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : shells
Licenses       : PD
Maintainer     : tobik@FreeBSD.org
WWW            : https://github.com/ibara/oksh
Comment        : Portable OpenBSD Korn shell
Options        :
    CURSES         : on
    STATIC         : off
Annotations    :
    FreeBSD_version: 1300139
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 324KiB
Description    :
oksh is the portable version of the OpenBSD Korn shell, a continuation
of the Public Domain Korn Shell (PDKSH).  Its command language is a
superset of the sh(1) shell language.  oksh is best known as the
default user shell and /bin/sh on OpenBSD.

WWW: https://github.com/ibara/oksh
pdksh-5.2.14p2_6
Name           : pdksh
Version        : 5.2.14p2_6
Installed on   : Fri Dec 10 03:38:58 2021 JST
Origin         : shells/pdksh
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : shells
Licenses       : BSD3CLAUSE
Maintainer     : rodrigo@FreeBSD.org
WWW            : http://www.cs.mun.ca/~michael/pdksh/
Comment        : The Public Domain Korn Shell
Options        :
    STATIC         : off
Annotations    :
    FreeBSD_version: 1300139
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 320KiB
Description    :
PDKSH is the Public Domain Korn Shell. Its command language is a
superset of the sh(1) shell language.

WWW: http://www.cs.mun.ca/~michael/pdksh/
ksh93-93.u_1,2
Name           : ksh93
Version        : 93.u_1,2
Installed on   : Fri Dec 10 03:38:58 2021 JST
Origin         : shells/ksh93
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : shells
Licenses       : EPL
Maintainer     : cy@FreeBSD.org
WWW            : http://www.kornshell.com/
Comment        : AT&T KornShell 93
Options        :
    EXAMPLES       : on
    KSH            : off
    KSH93          : on
    STATIC         : off
Annotations    :
    FreeBSD_version: 1300139
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 1.94MiB
Description    :
KSH-93 is the most recent version of the KornShell Language described
in "The KornShell Command and Programming Language," by Morris
Bolsky and David Korn of AT&T Bell Laboratories.  The KornShell is
a shell programming language, which is upward compatible with "sh"
(the Bourne Shell), and is intended to conform to the IEEE P1003.2/ISO
9945.2 Shell and Utilities standard.  KSH-93 provides an enhanced
programming environment in addition to the major command-entry
features of the BSD shell "csh".  With KSH-93, medium-sized programming
tasks can be performed at shell-level without a significant loss
in performance.  In addition, "sh" scripts can be run on KSH-93
without modification.

WWW: http://www.kornshell.com/

 

そういえば OmniOS は消しちゃったな・・・


2021年12月27日月曜日

レコードプレーヤーを買った

ここしばらく帰っていない実家(と言っていいのか、いまだによくわからない家) で古ーいレコードがいくつか見つかったらしく、「どうすればいい?」と・・。

当然自分のものではなく、どこぞに売ったとして二束三文でつまらないだろうと思ったのでレコードプレーヤーを買って送ることにした。実家の者みずから買って楽しんでいる、ということがないことから「本格派!」なものでなくてよかろ・・。それだけで音が出せる手軽なもので探した結果買ったのは ION Audio  Max LP

2014年末に出てたものらしい https://info.shimamura.co.jp/digital/newitem/2014/11/39583

最初は下位機種?のArchive LP にしかけたが「カバーがなくてほこりがきて嫌」といった文句が予想されたのでカバー付きのにした。デジタル化の機能が云々と書かれていて結構前のmacOS/iOS から非対応だけども、対応してても多分使わないだろうから気にしないことにした。自分が使うものならマイナスポイントにはなるかな。

日本のメーカーで Max LP 並のものがあるかなとちょっと期待していたけど、見つからず残念。 探し方が悪いかもしれない。

交換針も定期的に送らないとダメなんだろうなと思いつつも、まぁいいでしょう。この「自分のことではないけど調べて、買って、送る」をするのが良いのかと思うとやや疑問ではある。「再生する気がないなら捨てればいいし、再生するなら今もレコードプレーヤー売ってるよ、お店の人に聞くのがよろしい」で終わらすことはできた。

しかし、レコードのことさっぱりわからないので調べてみると少しややこしかった。回転数いくつとか、EP? LP?コンパクト盤?ドーナツ盤?と。そういえば針をどこから落とすのかも知らない。未知との遭遇。

レコードとは https://www.audio-technica.co.jp/cartridge/navi/whatis/index.php

円盤のものだと CD をトレイに置いて(または突起にはめて)再生ポチー、からしか知らないので 8cm か 12cm かだけの違いだったのよね。なんとなくレコードは「余裕のある人のオーディオ」という印象を受けたね。

 

M1 Mac #4

ヴイエムウェアは今もまだプレビューなので VMware Fusion Tech Preview をインストール。「プロフェッショナル バージョン e.x.p (18656771)」

 

パラレルズはすでにプレビューでなく対応済みなのよね・・

https://www.parallels.com/jp/news/press-releases/show/pd17-for-mac-launches/

何年かぶりにパラレルズに戻るのもありかもしれない。しかしそもそも arm64 な vm が手元に要るかというと、そうでもないかも。


それはさておき VMware 上で適当に Debian やら Fedora をインストール。

$ uname -mrsv
Linux 5.10.0-10-arm64 #1 SMP Debian 5.10.84-1 (2021-12-08) aarch64

$ uname -mrsv
Linux 5.15.10-200.fc35.aarch64 #1 SMP Fri Dec 17 14:30:23 UTC 2021 aarch64

インストール時のオペレーティングシステムの選択、 「その他」で FreeBSD 14 があるのはどういうことなんだろう。「使うのは当然 CURRENT ですよね」ということ?

Linux は、intel 版のときにあった RHEL や CentOS は無い。


 


2021年12月25日土曜日

「やめる」を考える

お仕事ではなく。

やはり「何をするか」も大事だけど、「何をやめるか(しないか)」もちゃんとねという。 

ああ、第3の習慣な感じ。

2021年12月14日火曜日

都合のいい解釈

Java のスローガン? のひとつ、

https://docs.oracle.com/javase/tutorial/getStarted/intro/changemylife.html

  • Write once, run anywhere: Because applications written in the Java programming language are compiled into machine-independent bytecodes, they run consistently on any Java platform.

 と書かれている内容以外のものを勝手に付け足して解釈している様を観測した。

「なるほどそういう意味だったんですね」で終わらずに悪魔の証明に展開していて、もやもやっとしてしまい嗚呼変なものをみてしまった・・・という感想と同時にそういう「やり方」もあるんだなと思った。

2021年12月13日月曜日

M1 Mac #3

sysctl の違い

sysctl -a  の項目数 -  intel MBP(2018): 1626, M1Pro MBP: 1464

diff

@@ -5,4 +4,0 @@
-debug.acpi_flags
-debug.acpi_layer
-debug.acpi_level
-debug.agpm.LogLevel
@@ -26,70 +22,3 @@
-debug.intel.GlobalUsageTotal_Busy_nSec
-debug.intel.GlobalUsageTotal_nSec
-debug.intel.IGInterruptControl
-debug.intel.dtraceEnable
-debug.intel.flipCount
-debug.intel.gpuUsageEnables
-debug.intel.gpuUsageEnablesCheck
-debug.intel.graphicsFirmwareTracePointEnable
-debug.intel.graphicsTracePointEnable
-debug.intel.kdctlVersion
-debug.intel.mSecCalcGPUBusy
-debug.intel.oaEnable
-debug.intel.perfEventEnable
-debug.intel.ringBlitUsage
-debug.intel.ringBlit_nSec
-debug.intel.ringMainUsage
-debug.intel.ringMain_nSec
-debug.intel.ringMediaUsage
-debug.intel.ringMedia_nSec
-debug.intel.ringOnSample
-debug.intel.ringTakeSample
-debug.intel.ringVEBoxUsage
-debug.intel.ringVEBox_nSec
-debug.intel.schedEnableThrottleOverride
-debug.intel.schedPriCreditsHigh
-debug.intel.schedPriCreditsLow
-debug.intel.schedPriCreditsNormal
-debug.intel.schedPriCreditsNormalHigh
-debug.intel.schedPriElevatePID
-debug.intel.schedPriPreemption
-debug.intel.schedThrottleHighPriByVal
-debug.intel.schedThrottleLowPriByVal
-debug.intel.schedThrottleNormalHighPriByVal
-debug.intel.schedThrottleNormalPriByVal
-debug.intel.swapCount
-debug.intel.telemetryAltConfig
-debug.intel.telemetryConfig
-debug.intel.telemetryMode
-debug.intel.telemetryNumFrame
-debug.intel.telemetrySampleLocations
-debug.intel.telemetrySpot1
-debug.intel.telemetryStartFrame
-debug.intel.telemetryStatPasses
-debug.intel.telemetryStopFrame
-debug.intel.telemetryTestCase
-debug.intel.telemetryUsageReportmSec
-debug.intel.telemetryVersion
-debug.intel.temp0
-debug.intel.temp1
-debug.intel.temp2
-debug.intel.temp3
-debug.intel.temp4
-debug.intelfb.FBInfo
-debug.intelfb.FakeType2Dongle
-debug.intelfb.IGInterruptControl
-debug.intelfb.enableDECounting
-debug.intelfb.enableGTHWFreqRead
-debug.intelfb.euInfo
-debug.intelfb.fLastRequestedPState
-debug.intelfb.forceDither
-debug.intelfb.forceSlicesEUx
-debug.intelfb.forceSlicesGTx
-debug.intelfb.graphicsTracePointEnable
-debug.intelfb.sliceInfo
-debug.intelfb.temp0
-debug.intelfb.temp1
-debug.intelfb.temp2
-debug.intelfb.temp3
-debug.intelfb.temp4
-debug.intelfb.testCase
+debug.iogpu.dynamic_lwm
+debug.iogpu.wired_limit
+debug.iogpu.wired_lwm_mb
@@ -97 +25,0 @@
-debug.ioppf
@@ -111,0 +40,3 @@
+debug.mcc_channel_counters
+debug.mcc_clampwaycount
+debug.mcc_debug
@@ -120,3 +50,0 @@
-hw.busfrequency
-hw.busfrequency_max
-hw.busfrequency_min
@@ -129,3 +56,0 @@
-hw.cpufrequency
-hw.cpufrequency_max
-hw.cpufrequency_min
@@ -134 +58,0 @@
-hw.cputhreadtype
@@ -135,0 +60 @@
+hw.ephemeral_storage
@@ -140 +64,0 @@
-hw.l3cachesize
@@ -146,15 +70,44 @@
-hw.optional.adx
-hw.optional.aes
-hw.optional.avx1_0
-hw.optional.avx2_0
-hw.optional.avx512bw
-hw.optional.avx512cd
-hw.optional.avx512dq
-hw.optional.avx512f
-hw.optional.avx512ifma
-hw.optional.avx512vbmi
-hw.optional.avx512vl
-hw.optional.bmi1
-hw.optional.bmi2
-hw.optional.enfstrg
-hw.optional.f16c
+hw.optional.AdvSIMD
+hw.optional.AdvSIMD_HPFPCvt
+hw.optional.arm.FEAT_AES
+hw.optional.arm.FEAT_BF16
+hw.optional.arm.FEAT_BTI
+hw.optional.arm.FEAT_CSV2
+hw.optional.arm.FEAT_CSV3
+hw.optional.arm.FEAT_DPB
+hw.optional.arm.FEAT_DPB2
+hw.optional.arm.FEAT_DotProd
+hw.optional.arm.FEAT_ECV
+hw.optional.arm.FEAT_FCMA
+hw.optional.arm.FEAT_FHM
+hw.optional.arm.FEAT_FP16
+hw.optional.arm.FEAT_FPAC
+hw.optional.arm.FEAT_FRINTTS
+hw.optional.arm.FEAT_FlagM
+hw.optional.arm.FEAT_FlagM2
+hw.optional.arm.FEAT_I8MM
+hw.optional.arm.FEAT_JSCVT
+hw.optional.arm.FEAT_LRCPC
+hw.optional.arm.FEAT_LRCPC2
+hw.optional.arm.FEAT_LSE
+hw.optional.arm.FEAT_LSE2
+hw.optional.arm.FEAT_PAuth
+hw.optional.arm.FEAT_PAuth2
+hw.optional.arm.FEAT_PMULL
+hw.optional.arm.FEAT_RDM
+hw.optional.arm.FEAT_SB
+hw.optional.arm.FEAT_SHA1
+hw.optional.arm.FEAT_SHA256
+hw.optional.arm.FEAT_SHA3
+hw.optional.arm.FEAT_SHA512
+hw.optional.arm.FEAT_SPECRES
+hw.optional.arm.FEAT_SSBS
+hw.optional.arm64
+hw.optional.armv8_1_atomics
+hw.optional.armv8_2_fhm
+hw.optional.armv8_2_sha3
+hw.optional.armv8_2_sha512
+hw.optional.armv8_3_compnum
+hw.optional.armv8_crc32
+hw.optional.armv8_gpi
+hw.optional.breakpoint
@@ -162,14 +115,6 @@
-hw.optional.fma
-hw.optional.hle
-hw.optional.mmx
-hw.optional.mpx
-hw.optional.rdrand
-hw.optional.rtm
-hw.optional.sgx
-hw.optional.sse
-hw.optional.sse2
-hw.optional.sse3
-hw.optional.sse4_1
-hw.optional.sse4_2
-hw.optional.supplementalsse3
-hw.optional.x86_64
+hw.optional.neon
+hw.optional.neon_fp16
+hw.optional.neon_hpfp
+hw.optional.ucnormal_mem
+hw.optional.watchpoint
+hw.osenvironment
@@ -180 +124,0 @@
-hw.perflevel0.cpusperl3
@@ -184 +127,0 @@
-hw.perflevel0.l3cachesize
@@ -188,0 +132,8 @@
+hw.perflevel1.cpusperl2
+hw.perflevel1.l1dcachesize
+hw.perflevel1.l1icachesize
+hw.perflevel1.l2cachesize
+hw.perflevel1.logicalcpu
+hw.perflevel1.logicalcpu_max
+hw.perflevel1.physicalcpu
+hw.perflevel1.physicalcpu_max
@@ -194,0 +146 @@
+hw.use_recovery_securityd
@@ -199,0 +152 @@
+kern.amfm_log_ctl
@@ -204 +156,0 @@
-kern.auxiliaryfilesetuuid
@@ -210 +161,0 @@
-kern.bridge.bootsessionuuid
@@ -215,0 +167,2 @@
+kern.cpu_checkin_interval
+kern.darkboot
@@ -252,5 +205,4 @@
-kern.hv.clock.generation
-kern.hv.clock.tsc_base
-kern.hv.clock.tsc_clock_last
-kern.hv.vmx_mitigations
-kern.hv.vmx_supported_mitigations
+kern.hv.ipa_size_16k
+kern.hv.ipa_size_4k
+kern.hv.max_address_spaces
+kern.hv.supported
@@ -263 +214,0 @@
-kern.interrupt_timer_coalescing_enabled
@@ -475,4 +426,12 @@
-kern.skywalk.flowswitch.ap1.ipfm.frag_count
-kern.skywalk.flowswitch.ap1.ipfm.frag_limit
-kern.skywalk.flowswitch.ap1.ipfm.queue_count
-kern.skywalk.flowswitch.ap1.ipfm.queue_limit
+kern.skywalk.flowswitch.anpi0.ipfm.frag_count
+kern.skywalk.flowswitch.anpi0.ipfm.frag_limit
+kern.skywalk.flowswitch.anpi0.ipfm.queue_count
+kern.skywalk.flowswitch.anpi0.ipfm.queue_limit
+kern.skywalk.flowswitch.anpi1.ipfm.frag_count
+kern.skywalk.flowswitch.anpi1.ipfm.frag_limit
+kern.skywalk.flowswitch.anpi1.ipfm.queue_count
+kern.skywalk.flowswitch.anpi1.ipfm.queue_limit
+kern.skywalk.flowswitch.anpi2.ipfm.frag_count
+kern.skywalk.flowswitch.anpi2.ipfm.frag_limit
+kern.skywalk.flowswitch.anpi2.ipfm.queue_count
+kern.skywalk.flowswitch.anpi2.ipfm.queue_limit
@@ -503,4 +462,8 @@
-kern.skywalk.flowswitch.en9.ipfm.frag_count
-kern.skywalk.flowswitch.en9.ipfm.frag_limit
-kern.skywalk.flowswitch.en9.ipfm.queue_count
-kern.skywalk.flowswitch.en9.ipfm.queue_limit
+kern.skywalk.flowswitch.en5.ipfm.frag_count
+kern.skywalk.flowswitch.en5.ipfm.frag_limit
+kern.skywalk.flowswitch.en5.ipfm.queue_count
+kern.skywalk.flowswitch.en5.ipfm.queue_limit
+kern.skywalk.flowswitch.en6.ipfm.frag_count
+kern.skywalk.flowswitch.en6.ipfm.frag_limit
+kern.skywalk.flowswitch.en6.ipfm.queue_count
+kern.skywalk.flowswitch.en6.ipfm.queue_limit
@@ -522,0 +486 @@
+kern.stackshot_busy_enabled
@@ -527 +490,0 @@
-kern.systemfilesetuuid
@@ -554 +516,0 @@
-kern.timer_coalesce_idle_entry_hard_deadline_max
@@ -602,4 +564 @@
-kern.zleak.active
-kern.zleak.global_threshold
-kern.zleak.max_zonemap_size
-kern.zleak.zone_threshold
+kpc.pc_capture_supported
@@ -615,10 +573,0 @@
-machdep.cpu.address_bits.physical
-machdep.cpu.address_bits.virtual
-machdep.cpu.arch_perf.events
-machdep.cpu.arch_perf.events_number
-machdep.cpu.arch_perf.fixed_number
-machdep.cpu.arch_perf.fixed_width
-machdep.cpu.arch_perf.number
-machdep.cpu.arch_perf.version
-machdep.cpu.arch_perf.width
-machdep.cpu.brand
@@ -626,3 +574,0 @@
-machdep.cpu.cache.L2_associativity
-machdep.cpu.cache.linesize
-machdep.cpu.cache.size
@@ -631,10 +576,0 @@
-machdep.cpu.extfamily
-machdep.cpu.extfeature_bits
-machdep.cpu.extfeatures
-machdep.cpu.extmodel
-machdep.cpu.family
-machdep.cpu.feature_bits
-machdep.cpu.features
-machdep.cpu.leaf7_feature_bits
-machdep.cpu.leaf7_feature_bits_edx
-machdep.cpu.leaf7_features
@@ -642,21 +577,0 @@
-machdep.cpu.max_basic
-machdep.cpu.max_ext
-machdep.cpu.microcode_version
-machdep.cpu.model
-machdep.cpu.mwait.extensions
-machdep.cpu.mwait.linesize_max
-machdep.cpu.mwait.linesize_min
-machdep.cpu.mwait.sub_Cstates
-machdep.cpu.processor_flag
-machdep.cpu.signature
-machdep.cpu.stepping
-machdep.cpu.thermal.ACNT_MCNT
-machdep.cpu.thermal.core_power_limits
-machdep.cpu.thermal.dynamic_acceleration
-machdep.cpu.thermal.energy_policy
-machdep.cpu.thermal.fine_grain_clock_mod
-machdep.cpu.thermal.hardware_feedback
-machdep.cpu.thermal.invariant_APIC_timer
-machdep.cpu.thermal.package_thermal_intr
-machdep.cpu.thermal.sensor
-machdep.cpu.thermal.thresholds
@@ -664,42 +579,11 @@
-machdep.cpu.tlb.data.small
-machdep.cpu.tlb.data.small_level1
-machdep.cpu.tlb.inst.large
-machdep.cpu.tsc_ccc.denominator
-machdep.cpu.tsc_ccc.numerator
-machdep.cpu.vendor
-machdep.cpu.xsave.extended_state
-machdep.cpu.xsave.extended_state1
-machdep.eager_timer_evaluation_max
-machdep.eager_timer_evaluations
-machdep.memmap.ACPINVS
-machdep.memmap.ACPIReclaim
-machdep.memmap.Conventional
-machdep.memmap.Other
-machdep.memmap.PalCode
-machdep.memmap.Reserved
-machdep.memmap.RuntimeServices
-machdep.memmap.Unusable
-machdep.misc.fast_uexc_support
-machdep.misc.interrupt_latency_max
-machdep.misc.nmis
-machdep.misc.panic_restart_timeout
-machdep.misc.timer_queue_trace
-machdep.pmap.hashcnts
-machdep.pmap.hashmax
-machdep.pmap.hashwalks
-machdep.pmap.kern_pv_reserve
-machdep.pmap.kernel_text_ps
-machdep.tsc.at_boot
-machdep.tsc.deep_idle_rebase
-machdep.tsc.frequency
-machdep.tsc.nanotime.generation
-machdep.tsc.nanotime.ns_base
-machdep.tsc.nanotime.scale
-machdep.tsc.nanotime.shift
-machdep.tsc.nanotime.tsc_base
-machdep.tsc.rebase_abs_time
-machdep.uncore_pcie_mmio_base
-machdep.uncore_sample_ctl
-machdep.uncore_sample_interval_ms
-machdep.uncore_sample_mask
-machdep.uncore_sample_state
+machdep.deferred_ipi_timeout
+machdep.lck_mtx_adaptive_spin_mode
+machdep.phy_read_delay_panic
+machdep.phy_writedelay_panic
+machdep.report_phy_read_delay
+machdep.report_phy_read_osbt
+machdep.report_phy_write_delay
+machdep.report_phy_write_osbt
+machdep.time_since_reset
+machdep.trace_phy_read_delay
+machdep.trace_phy_write_delay
@@ -707,52 +591,3 @@
-machdep.vectors.IPI
-machdep.vectors.timer
-machdep.x2apic_enabled
-machdep.x86_fp_simd_isr_uses
-machdep.xcpm.bootplim
-machdep.xcpm.bootpst
-machdep.xcpm.cpu_thermal_level
-machdep.xcpm.deep_idle_count
-machdep.xcpm.deep_idle_last_stats
-machdep.xcpm.deep_idle_log
-machdep.xcpm.deep_idle_total_stats
-machdep.xcpm.epp_override
-machdep.xcpm.forced_idle_period
-machdep.xcpm.forced_idle_ratio
-machdep.xcpm.gpu_thermal_level
-machdep.xcpm.hard_plimit_max_100mhz_ratio
-machdep.xcpm.hard_plimit_min_100mhz_ratio
-machdep.xcpm.io_control_disengages
-machdep.xcpm.io_control_engages
-machdep.xcpm.io_cst_control_enabled
-machdep.xcpm.io_epp_boost_enabled
-machdep.xcpm.io_filtered_reads
-machdep.xcpm.io_thermal_level
-machdep.xcpm.lpm_enabled
-machdep.xcpm.lpm_plimit_max_100mhz_ratio
-machdep.xcpm.maxbusdelay
-machdep.xcpm.maxintdelay
-machdep.xcpm.mbd_applications
-machdep.xcpm.mbd_mode
-machdep.xcpm.mbd_relaxations
-machdep.xcpm.mid_applications
-machdep.xcpm.mid_cst_control_limit
-machdep.xcpm.mid_mode
-machdep.xcpm.mid_mode_active
-machdep.xcpm.mid_relaxations
-machdep.xcpm.mode
-machdep.xcpm.pcps_mode
-machdep.xcpm.pcps_rt_override_mode
-machdep.xcpm.pcps_rt_override_ns
-machdep.xcpm.perf_hints
-machdep.xcpm.power_source
-machdep.xcpm.qos_txfr
-machdep.xcpm.ratio_change_ratelimit_ns
-machdep.xcpm.ratio_changes_total
-machdep.xcpm.ring_boost_enabled
-machdep.xcpm.soft_plimit_max_100mhz_ratio
-machdep.xcpm.soft_plimit_min_100mhz_ratio
-machdep.xcpm.tuib_enabled
-machdep.xcpm.tuib_ns
-machdep.xcpm.tuib_plimit_max_100mhz_ratio
-machdep.xcpm.tuib_plimit_min_100mhz_ratio
-machdep.xcpm.vectors_loaded_count
+machdep.virtual_address_size
+machdep.wake_abstime
+machdep.wake_conttime
@@ -1249,0 +1085,2 @@
+net.ppp.l2tp.nb_threads
+net.ppp.l2tp.thread_outq_size
@@ -1464,0 +1302,2 @@
+vm.cs_defer_to_pmap_cs
+vm.cs_defer_to_pmap_cs_not
@@ -1570 +1408,0 @@
-vm.vm_clump_promote_threshold

2021年12月12日日曜日

某脆弱性の話

CDN各社のアナウンスのようなもの。(各社と言っても数社しか知らない・・)

Akamai

https://www.akamai.com/blog/news/CVE-2021-44228-Zero-Day-Vulnerability

https://www.akamai.com/blog/news/CVE-2021-44228-Patching-is-Recommended 

https://twitter.com/Akamai/status/1469450716234330115

 

Cloudflare

https://blog.cloudflare.com/how-cloudflare-security-responded-to-log4j2-vulnerability/

https://blog.cloudflare.com/secure-how-your-servers-connect-to-the-internet-today/

https://blog.cloudflare.com/actual-cve-2021-44228-payloads-captured-in-the-wild/

https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

https://twitter.com/Cloudflare/status/1469451993630580738

https://twitter.com/Cloudflare/status/1469418483364601859  

https://twitter.com/Cloudflare/status/1469413867700822018

https://twitter.com/Cloudflare/status/1469376339199283205 


Fastly

https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j

https://twitter.com/fastly/status/1469439041942786051

 

CDNetworks

それらしいツイートなし、ブログ記事なし https://www.cdnetworks.com/blog/

Limelight Networks

それらしいツイートなし、ブログ記事なし https://www.limelight.com/resources/blog/

 

メガクラウドのもの。これらは G で検索。

AWS

aws log4j で サーチすると↓ヒット。site:aws.amazon.com log4j がよろしい。

Apache Log4j2 Security Bulletin (CVE-2021-44228) - Amazon ...


Azure

Azure log4j でサーチしてもそれらしいものなし

site:azure.microsoft.com  log4j でもなさそう


Google Cloud(グーグルさんのは Google Cloud と呼ぶのが正しいのか、GCP なのかよくわかってない。。)

google log4j で↓が

Cloud Armor WAF rule to help address Apache Log4j ...

site:cloud.google.com log4j にしたらもうひとつ見つかった

Apache Log4j 2 Vulnerability Security Advisory | Google Cloud


2021年12月8日水曜日

マイスィーコーの話

例のあれ

https://www.theregister.com/2021/12/06/mysql_a_pretty_poor_database/ 

updated at ..... に書かれてるMariaDBの中の人の、

"In 2016, at MariaDB, we completely abandoned MySQL code, and brought in new storage engines, dialects, monitors, even ML-based workload analysis."

ってそうだったのね〜。当時結構な話題になってそうだけど覚えがないな。気が向いたらcompletely abandoned っぷりを確認してみよう。

2021年12月6日月曜日

M1 Mac #2

・クラッシュするらしいので試してみる

https://japanese.engadget.com/m1-pro-max-hdr-youtube-kernel-crash-041033610.html

追記1: まだ(?)クラッシュしない・・

HDR らしい動画を鑑賞。例 https://www.youtube.com/watch?v=xXiSN8Tftjg

その後 The HDR Channel というのが見つかったのでそこを見て、 https://www.youtube.com/c/TheHDRChannel/videos
再生リストで 96 あるのをひたすら流し続け・・・
コメントをスクロールしても問題なし、全画面オンオフを切り替えても問題なし。Safari でのみ試したので Chrome でもみてみるか
 
追記2: Chrome でも問題なし。4K HDR な外部ディスプレイでもつけてそっちで再生してみるといいかも?残念ながら無い。

・パフォーマンス

ブラウザのビルドというヘビーなものでなく、簡単なスクリプトでもまぁ結構な違い。(そもそも3年前のモデルと比べてる時点で、ねぇ・・というのはある)

https://qiita.com/tossh/items/659e5934e52b38183200 のようなものを python で、 numba あり/なし。M1 は今のところ unofficial support だけど業務で使ってるわけでもなし、気にしない。

numbaなし: 2018 で 1m30s , 2021 で 58s

numbaあり: 2018 で 0.58s, 2021 で 0.29s

M1 に慣れてしまうと、お仕事用のの貧弱さに辟易、苛々してしまうだろうというのが一番の問題か・・・。お仕事用に Pro/Max じゃない M1 なのを買って BYOD してもいいかもしれないな

2021年12月5日日曜日

M1 Mac

10月末に MBP を購入していた。やっときた。

再びブラウザをビルドしてみると、Firefox だと18分くらい。ビルドしかさせてなかったらもうちょっと速いかもしれない。


    17:47.04 Your build was successful!
    To take your build for a test drive, run: |mach run|
    For more information on what to do now, see https://firefox-source-docs.mozilla.org/setup/contributing_code.html

mach resource-usage でみると以下の通り。


Wall Time (s)    1065.13
Start Date    2021-12-05T09:33:09.127Z
End Date    2021-12-05T09:50:54.260Z
CPU %    95.27
Write Bytes    16579727360
Read Bytes    5277798400
Write Time    15374
Read Time    232337

ファンは唸りをあげず(iStat Menus でみると回ってはいる)、手元は思ったより熱くならない。今の時期はむしろ熱くなって欲しかったり。なお blackmagic Disk Speed Test すると、これまで使っていたものの倍程度は出る。

 

WebKit は20数分。これもビルドしかさせてなかったらもうちょっと(以下略)

====================================================================
 WebKit is now built (23m:07s).
 To run Safari with this newly-built code, use the
 "Tools/Scripts/run-safari" script.
====================================================================

 

Chromium はまだ。fetch chromium でコケてしまった。

2021年11月29日月曜日

ブラウザをビルドしてみよう

intel な Mac と昨年の M1、今年でた M1な Mac とで WebKit のビルドにかかる時間を測っているのを見かけ、「そういえばブラウザをビルドしたことないな」と思ったのでそれぞれの手順載ってるサイトと、大して高スペックでもない MBP でかかった時間は以下に。

WebKit

https://github.com/WebKit/WebKit#building-webkit

最も手間が少ない感じ。MacBook Pro (13-inch, 2018, Four Thunderbolt 3 Ports) で 1時間ちょっと。

 

Chromium

https://chromium.googlesource.com/chromium/src/+/main/docs/mac_build_instructions.md
やたら時間がかかるのね・・。なんと 5.6時間・・・!何か間違ってるのかな・・・?と思ったけど、ググってみたところどうもそういうものらしい。1から何度もするのはしんどい感じ。ninja-mac がぶんまわっているのが見える。


Firefox

https://firefox-source-docs.mozilla.org/setup/macos_build.html

brew が要るため、まだ試していない。MacPorts 派なのがここでデメリットになるとは・・。追記: 要らない。入れずに一度試した時、./mach build 時に brew 入れるかい?と聞かれたのだけども、後でまた試してみたら進んだ。パスおかしなことになってたかなぁ。

57:29.76 Notification center failed: Install terminal-notifier to get a notification when the build finishes.
To view resource usage of the build, run |mach resource-usage|.
57:29.76 We know it took a while, but your build finally finished successfully!
57:29.76 If you are building Firefox often, SCCache can save you a lot of time. You can learn more here: https://firefox-source-docs.mozilla.org/setup/configuring_build_options.html#sccache
To take your build for a test drive, run: |mach run|
For more information on what to do now, see https://firefox-source-docs.mozilla.org/setup/contributing_code.html

と。そして ./mach run


 


某 Linux

年がついているやつの話。

systemd-foobard なのが増えた

不要なファイルがそこかしこに残っているように見える

デフォルトの chrony.conf がおかしい。leap smearing なやつのクライアントになっているのに leapsectz 設定されているという。

https://chrony.tuxfamily.org/doc/4.1/chrony.conf.html#leapsectz

Clients of leap smearing servers must not use this directive.

UTC 縛りなの?というデフォルト設定

上流のと異なり、ソースをダウンロードできない

/etc/**-release のコードネームの箇所( Rocky Linux 8.4 だと Green Obsidian と書かれているところ)  がその Linux の名前になっていて主張が激しい

上流または既存の下流のを使ってみたことがある人が見れば、なんだこれという目につくものがちらほら。


・・・という具合で、リリースではないしまぁこんなもんかな〜という印象。リリース候補?の時にはどうなっているか。

単にタダでかつカーネル新しめがいいということなら RockyAlmaelrepo を使う、でいいような気もする。longterm, mainline 、お好みで。また Rocky, Alma どっちも各クラウドベンダーがスポンサーに名を連ねていたりする。

Debian, Ubuntu な人だと「ふーん」な感じかな。

networkd

 メモ

Networkd https://fedoracloud.readthedocs.io/en/latest/networkd.html

2021年11月14日日曜日

「〜〜の解像度」

「〜〜の解像度」という言い回しをいつからか目にするようになったけど、元はどこから、いつからなんだろう。この意味ではなく。 

・・そう思い -画面 -画像 -表示 -画質 つけてググると・・

「「解像度」という言葉がビジネスの界隈ではしばしば使われるようになりました。解像度が高い状態とは、顧客の状況や課題が鮮明に見えていたり、次の... 」

と。なんか「解像度」言っておけばとりあえずおk、という感じだろうか。

 

色々と。

https://twitter.com/ayhy/status/1028087711251353600

https://twitter.com/holysen/status/1415980020397330433 

https://twitter.com/matsurara/status/1396074223706148865

https://twitter.com/bamulet/status/1455097094306365445 

https://twitter.com/DMi2wo/status/1412136381090910209

https://twitter.com/NatsunoAyano/status/1457138867572641793 

https://twitter.com/kivantium/status/1325475512320364546

https://twitter.com/mav_curry/status/1305160694501842945  

https://twitter.com/bear_thinking/status/1362385968272056337

https://twitter.com/zerothelements/status/1444271858795253760

https://twitter.com/Hal10099/status/1458726111278342146 

https://uriver.hatenablog.com/entry/2021/02/14/070125

https://www.sankeibiz.jp/econome/news/190322/ecc1903220630001-n2.htm

https://allkeyneeds.info/?p=758


濫用してしまうと「解像度おじさん」などと揶揄されそうである。

2021年11月8日月曜日

すご「い」/すご「く」

誰が呼び始めたか知らないけど、例の新幹線で売られている堅いアイスにつけられた俗称って

「シンカンセンスゴイカタイアイス」か「シンカンセンスゴクカタイアイス」か。

後者と思っていたのだが、ググった結果ではどうも前者が優勢。公式に?もそうらしい。

https://twitter.com/mikimurai/status/1160910694184656896

「スゴイ」なら「スゴイカタサノアイス」になると思うけどそうでもないと。多分「すごいおいしい」も「すごくおいしい」より優勢だしそういうものかな。

2021年11月1日月曜日

macOS Monterey (12.0.1) にした

前回: macOS Big Sur (11.0) にした

$ sw_vers
ProductName:    macOS
ProductVersion:    12.0.1
BuildVersion:    21A559

$ uname -v
Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64

いつもの MacPorts はすぐ出てたような気がする。

不具合のようなもの、今のところ以下二つ。12.0.2, 12.0.3 とか、12.1,  12.2 くらいには直されるのだろうか。これまでアップグレード後に目立った不具合起きたことなかったのになぁ 。

1. テキストエディットがおかしい

単なるテキストファイルを開くことができなくなった。開けるものもあれば開けないものがある。開けない時には何もエラーなし。うん、意味がわからない。もしかしたら気付いたのが Monterey に更新後だっただけであって、Big Sur の時からこうなっていた可能性はあるかもしれない。まぁ常用しているエディタではないので影響は軽微だけども。

2. 外付けディスク(SSD)のマウントがおかしい

SanDisk Extreme Portable SSD が、接続してもマウントされない。ディスクユーティリティで見ると見えるけどマウントできたりできなかったりして不安定な感じ。

確実にマウントできる手順がわからず、何かの拍子に一度マウントできてからはおかしくなることはないようには見えるが不安。ディスクユーティリティ起動した後に表示されるまで妙に待たされるようになった気もする。ディスクユーティリティでマウント試してダメだった時は「com.apple.DiskManagement.disenterエラー0。」と出てくれる。Time Machine 兼、VMイメージ置いてるんだけどな・・。できる限り再起動やマウント解除せずにスリープしなさいってことか。これは明らかにアップグレード後から。

とてもわかりやすい不具合だと思うんだけど、ベータの時点では誰の目も掻い潜ったの・・?

そういえば Windows や macOS、「不具合報告のしかた」は公開されているのか知らないな。macOS のクラッシュレポートしか知らん。 同じ症状にあたってる人いないかググってみるか。。

 

追記1: 2. は、どうも12分くらい待つとマウントされる。diskutil list でみるとすぐに出てきている。結果の出力が終わってプロンプトに戻るまで妙に「待ち」が発生していて何かおかしい感じはする 。マウント後だと diskutil list はすぐに終わる。 

SSD以外のもの、例えばUSBメモリでもマウントまで待たされるんだろうか?と試しに繋いでみると全く問題なく即座に Finder 上に現れる。SSD のマウントを待っている間に何度もマウント、アンマウント可能。

ではでは HDD だとどうだろう?と、だいぶまえに Time Machine 用に使っていて、何かに使う機会があるかもしれないと眠らせておいた Western Digital の My Passport for Mac を繋げると、これも即座に Finder に現れる。

こんな感じで出てきて/dev/disk2 の表示後に少し待たされる。3,4 は表示後待たされない。

$ diskutil list external
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI ⁨EFI⁩                     209.7 MB   disk2s1
   2:                  Apple_HFS ⁨Extreme SSD⁩             999.9 GB   disk2s2

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk3
   1:                        EFI ⁨EFI⁩                     209.7 MB   disk3s1
   2:                  Apple_HFS ⁨My Passport for Mac⁩     999.8 GB   disk3s2

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *7.8 GB     disk4
   1:               Windows_NTFS ⁨SONYUSB8G⁩               7.8 GB     disk4s1
 

mount でみると /dev/disk2s2 はマウントされていない。

$ mount -t hfs,exfat
/dev/disk3s2 on /Volumes/My Passport for Mac (hfs, local, nodev, nosuid, journaled)
/dev/disk4s1 on /Volumes/SONYUSB8G (exfat, local, nodev, nosuid, noowners) 

待ってるとじきにマウントされる。接続後、常に10分以上かかる。

$ mount -t hfs,exfat
/dev/disk3s2 on /Volumes/My Passport for Mac (hfs, local, nodev, nosuid, journaled)
/dev/disk4s1 on /Volumes/SONYUSB8G (exfat, local, nodev, nosuid, noowners)
/dev/disk2s2 on /Volumes/Extreme SSD (hfs, local, nodev, nosuid, journaled)

接続して diskutil で見えるようになってから mount で見えるまで、を適当にチェックしてみた結果(それぞれ出てくるまで diskutil, mount をスリープ入れつつ繰り返し実行しただけ)

Tue Nov  2 02:18:15 JST 2021
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI ⁨EFI⁩                     209.7 MB   disk2s1
   2:                  Apple_HFS ⁨Extreme SSD⁩             999.9 GB   disk2s2

Tue Nov  2 02:30:28 JST 2021
/dev/disk2s2 on /Volumes/Extreme SSD (hfs, local, nodev, nosuid, journaled)

→ 12ふん。

フォーマットがやたら遅い、というのも観測されているようだ。。 https://twitter.com/Navesink/status/1453938926352175110 

Monterey はシロかなぁ。SanDisk に問い合わせてみるか。

 

追記2: 早速回答が得られた。

現時点でMacの最新OS Montereyとの動作確認が取られておりません。
そのため、新OSでご利用いただいた場合、正常にご使用いただけない場合がございます。

と。 12秒まってマウントされた後の状態は正常かどうかは不明。動作確認が取れている製品一覧があるのか不明。

・・・という感じなので対応一覧すでに出してくれてるメーカーのを買って使うのがよさそう。

Apple のコミュニティに投稿している人もいた。M1 だったり、出てるエラーは違ったりするけど使っているのは容量が違うだけで同じものかな。自分のはケツのGH25は書かれていない。

https://discussionsjapan.apple.com/thread/253318215

サンディスク エクストリーム ポータブルSSD サポート情報、というところには「Mac OS 10.4以降対応」とだけ。10.4 て。。ただこれも型番のケツにはJ25とあって、この有無でも動作は違うのかもしれない。わからん。

https://kb-jp.sandisk.com/app/answers/detail/a_id/21178

良い子の諸君は事前に対応状況を確認しよう! 


2021年10月29日金曜日

security

Ubuntu

Security https://ubuntu.com/security 

Security Notices https://ubuntu.com/security/notices

CVEs https://ubuntu.com/security/cve

USN から CVE は辿れて、CVE から USN は辿れない?

 

Debian

Debian -- Security Information https://www.debian.org/security/index.en.html

Debian Security Advisories は CVE互換らしい

Cross References of Debian Security Advisories https://www.debian.org/security/crossreferences.en.html

Security Bug Tracker https://security-tracker.debian.org/tracker/


CentOS

ない? Red Hat Customer Portal をみなさいということかな。そういったことはどこかに書かれているのかしら

https://forums.centos.org/viewtopic.php?t=45214


Red Hat

Security Center https://access.redhat.com/security

CVE Database https://access.redhat.com/security/security-updates/#/cve 

Product Advisories https://access.redhat.com/security/security-updates/#/security-advisories



2021年10月24日日曜日

某社サイト

キャリアページを覗いてみたら単に募集中のポジションが載ってるだけでなく、あなたの強みを表すものを選んでね、というスタイルだったのでぽちぽちそれらしいのを選択してみたら、出てきたのは DevOps エンジニアと Operations エンジニアだった。まぁそうよねと思うと同時に、違ってなくてよかったとも思った。

娯楽としてあちこちみてみよう

2021年9月26日日曜日

どっかー、くーばねてぃす

実務とほぼ無関係なのでここしばらく触らずにいたけど、Docker を再びちょいちょい触ってみることにした。どのくらい触っていなかったかというと、コマンド体系が変わっていたことを知らなかったほど。

もはや更新する気はないものの(年齢的に、あったところでアピれるものではない) LinuC には今は Docker も含まれているらしいのを知り、それなりに追従しておくかなというのもある。

https://www.oreilly.co.jp/books/9784873117768/ は以前買って多少読んだ記憶があるものの不要だなと思って手放していた。書店へ足を運べば、今は Docker, Kubernetes な書籍はあれこれと出ている。新しめのものでも旧コマンドで書かれていたりもするのだけど気にしないでおく。

Docker は以前触った時のを再びというくらいなのでそれなりに雰囲気はわかってるのだけど Kubernetes に触れたことは微塵もなかったのでこれから。庶民のための Borg と思っているのだけどそうでもないのかしら。

そういえば Join the DotCloud beta なメールを受け取ったのが 2011/5/1 だった。やー、懐かしい。

dotCloud を引き取った cloudControl は 2015年に破産、dotCloud サービスは 2016年に終了していた。

2021年9月17日金曜日

すめるとてむりん

たまに sdkman で Java を入れてゴソゴソすることがあるのだけど(コードを書くわけではない)、sdk list java すると見慣れないのが増えていた。Semeru と Temurin↓

$ sdk list java |grep ' [A-Z]'|grep '|'|grep -v Vendor |cut -d'|' -f 1
 AdoptOpenJDK  
 Corretto      
 GraalVM       
 Java.net      
 Liberica      
 Liberica NIK  
 Microsoft     
 SapMachine    
 Semeru        
 Temurin       
 Trava         
 Zulu

サイト https://sdkman.io/jdks には MS も書かれてないからあまり更新されてないかな。

AdoptOpenJDK は Eclipse Foundation に移管、Eclipse Adoptium Project として HotSpot のが Eclipse Temurin に、 OpenJ9 のは IBM Developer サイトから提供されて IBM Semeru Runtime だそうで。へぇ。

https://adoptopenjdk.net/ 

https://blog.adoptopenjdk.net/2021/03/transition-to-eclipse-an-update/

https://adoptium.net/

https://developer.ibm.com/languages/java/semeru-runtimes/

https://developer.ibm.com/blogs/introducing-the-ibm-semeru-runtimes/


vaccinated #2

2回目。前回と同じくその日午後と次の日はおやすみにしておいてから臨んだ。

接種前の検温は 36.2℃、やっぱり低めに出ると思う。そして接種。前回と違って針が「プスっ」と刺された感があった。1回目は「あれっ?いつ刺した??」と思ったんだけど。

その日には熱はなし、なんとなくだるさはあり。次の日起きた時から微熱(37.3℃) と頭痛あり。前のような異様な空腹と眠気はなく、それと引き換えにという感じだろうか。注射打ったところの肩の痛みはほぼなし、ほんの違和感だけ。

昼過ぎには 38℃近くまで上がってダルかったのでバファリンプレミアム服用。また寝て起きたら平熱に。これで副反応終了かな。もうちょっと様子見。

2021年8月27日金曜日

vaccinated

やっと1回目を接種した。職域の武田/モデルナはスルーし自治体のファイザーにしたのだった。

接種する午後のためにその日は半休とし、かつ次の日も予め休みにしておいた。

接種前の体温測ってもらったら 36.0 ℃ 、これは手首で測るやつで低くでたような気がする。体温計壊れてて1台目だと何度測ってもらっても 32 ℃ と出てたし・・・。

帰宅後数時間おきに熱測ってみても特に変動なく、36.7 - 36.9 で安定。倦怠感や頭痛などなし。肩はちょっと痛い程度で、「いたいいたいいたい!!」というのとはほど遠い。腫れははなし。

これが副反応なのかわからないけど、ただ異様に眠気は襲って来ていた。疲労として感じずに眠気として現れてるのかしら。あとやたら腹が減ってるような気もするけど、これは気のせいかもしれない。発熱は接種後 1~2日以内に起こること多いですよと貰った紙に書かれてたので明後日くらいまで様子見か。

これまで医療系なイベントで何か起きたのは、前に書いた、耳鼻科で耳の裏にできた粉瘤を切除してもらった後にクラクラっとしたことがあるくらいだな。20年以上前。

追記: 次の日は多少だるさがあった。どうも頭も痛い・・かな・・?という感じ。その次の日には副反応らしいものは無くなったように思う。買っておいたバファリンプレミアムの出番は今回はなかった。さて来月の2回目後はどんなかな。

2021年8月21日土曜日

メールアドレス確認がしょぼいサービス #3

これの続き

2021年 3月 不動産屋、「賃貸営業部」の人から。これはサービスではないので単に送信ミスだな。。

今朝電話しましたがタイミングが悪かったようでメールで失礼します、といった内容。物件の所有者から、家を整理していたらとあるものが出てきたので心当たりがあるか、という確認。メール本文冒頭に書かれていた 〜〜様 ではないです、物件の住所に心当たりもないです、と返信。

その後、失礼いたしましたと返ってきて終了。

 

2021年 6月 レイクALSA

いきなり

「お申込みいただきまして、誠にありがとうございます。お手数ですが、下記URLにて審査結果をご確認ください。」

というメールが来た。名前の読みが同じと思われる人は今年消費者金融のお世話になっているらしい。その後に何通か送られてきて、

「※本メールにお心当たりのない方はお問合せのお客さま専用フリーダイヤルへご連絡いただきますようお願いいたします。」

と書かれていたのですぐ電話した。その後7月頭までメールが来ていたけど、ちゃんと対応されたのかが確認不可。

必要書類をアップロードいただきありがとうなメールを送る前に、メールアドレスを確認してくださいな。ビジネスとしては誰かに金貸し付けられればよしでその辺は適当なのかもしれないな。

 

2021年 8月 Uber Eats

〜〜 様のアカウントに、ご注文が 2500 円引きになるクーポン( 1 回分)が付与されました。

と。 いや私は別のメールアドレスでアカウント作っていますね・・。ダメもとでメール返信したら、予想通り自動返信で

「お問い合わせを頂きましてありがとうございます。
ご質問を頂いている宛先はご利用頂けないようになっております。 」と返ってきたため、フォームからぽちぽち問い合わせ。

 

やれやれ。

 

なぜか HTTP/3 だけ

VMware Fusion  上で動かしている Windows 10 がおかしい。

ウェッブサイトは Google しかちゃんと表示できない。YouTube も OK。

Twitter は 'Something went wrong, but don’t fret — let’s give it another shot.'

Bing は

このサイトへの接続はセキュリティで保護されていません www.bing.com から無効な応答が送信されました。
Windows ネットワーク診断を実行してみてください。
ERR_SSL_PROTOCOL_ERROR
と。。促された Windows ネットワーク診断 は案の定「問題を特定できませんでした」と。

GitHub は真っ白。

Windows Update かけると 0% から進まない。

Edge でなくて Firefox で Bing みると エラーコード: SEC_ERROR_REUSED_ISSUER_AND_SERIAL 出たり 、mozilla.org みると エラーコード: SSL_ERROR_BAD_MAC_READ になったり。うーむ。mozilla.org だと何度かリロードすると表示してくれたりもするな。

Google のサイトは問題ないということはもしかして・・?と cloudflare のサイト( www.cloudflare.com ) 見てみると表示。

https://aws.amazon.com/ だめで https://cloud.google.com/ OK 

HTTP/3 だけは問題ないような感じ。それもたまに白くなるけど。うーん、どうした。

Wireshark でゴソゴソしてみるか

2021年8月1日日曜日

「〜〜万年ぶりに〜〜」

タイトルのような言い回しを時々目にする。いつからあるのだろう。単に「久しぶり」「久方ぶり」でないのは、それとなく大袈裟に言いたいから?

「エルフなんですね!」というツッコミを待ってはいないと思う。そういう言い回しを(も)するキャラですというアピールという可能性はあるかも。

 

2021年7月18日日曜日

https

TL上で、ある企業のサイトのTLS証明書が Let's Encrypt で云々、、、というのを目にした。証明書の前に、載せてるコンテンツでこれはどうなの、という話があったみたいでその流れで Let's Encrypt がでてきていた。

やや貶すような印象を受ける内容だったけども、サイト作った直後、「何はなくともまずは暗号化しとこ」というなら別におかしくはないと思うのよね。

何年か前にはこのような記事はあるので、まぁ言いたいことがわからんでもない。

https://security.srad.jp/story/16/01/10/1837213/ https://news.mynavi.jp/article/20170414-a103/

 

ブラウザのタブで開きっぱなしにしてるサイト見てみたら、多くが Verified by: DigiCert Inc であった。wiki.centos.org は Let's Encrypt 、あと個人のブログっぽいサイトも Let's Encrypt だった。

ナントカ企業500社〜みたいなののサイトをまるっと openssl コマンドなどでツンツンして証明書見てみるとよさそう。その場合、多分 EV が多いと思う。多分。

どこかでそういうのまとめられていそうではある。あと、Let's Encrypt を用いているサイトで最もアクセス数の多いサイトはどこかというのは気になる。

2021年6月30日水曜日

mbr2gpt

VMware Fusion 上で動かしている Windows 10、元々は Windows 8 で作成して更新して今に至っている。そのため .vmx などのファイル名は Windows 8 x64.XXX という。

これまでUEFIでなくレガシーなBIOS起動だったのを、Windows 11 に向けて? UEFI に変更しようと思い立ちゴソゴソ調べると、mbr2gpt というのでサラッとできることを知る。 Windows 11 は DX12 が必要のようなので、VMware Fusion で動かすのは無理なんだけども、、。

DX12 のことはそれとして、令和の時代なので UEFI にはしてみようと mbr2gpt 実行すると、どうもエラーでだめ。/validate /AllowFullOS してみると

Cannot find OS partition(s) for disk 0

と・・・。いや、OS パーティションあるから今起動してるよね・・?? Windows は(も)難しいなと思いつつググると、ピンポイントでそれを解決する動画が YouTube に。

A Solution to "Cannot find OS partition(s) for disk 0" - MBR2GPT https://www.youtube.com/watch?v=E2a5Uqj02OM

bcdedit というので unknown なものを確認して、それを /delete 。実際やってみると削除後はエラーが出なくなった。yay!

 

そのあとは修復ディスクから起動して mbr2gpt 実行、完了後はシャットダウンし .vmx に

firmware = "efi" 

を書いて起動。うまくいった。 firmware = "efi"  はまた確認してみると消え去っていたのだけど、以降は 「BIOS モード    UEFI」で起動しているので問題はないはず。

2021年6月12日土曜日

ふぁすとり〜の件で

pypi や rubygems などが揃って落ちていたりと、オーエスエス界にも結構な影響あるのだなと。

https://status.python.org/incidents/7ltfyzj2jk0x

https://status.rubygems.org/incidents/yml4xgf7547f

↑のように status.example.com でステータス見るのがいつからか定番?になっているのだけどもどちらも statuspage というやつなんだね。

https://www.atlassian.com/software/statuspage/powered-by

reddit はドメインから別 https://www.redditstatus.com/

twitch https://status.twitch.tv/

などなど

statuspages のステータスページはあるのかしら?メタステータスページ。

2021年4月29日木曜日

PS5

まだ PS5 のソフトは買っていない。キムタクが如くはあいにく売り切れで、PS4 な NieR Replicant ver.1.22474487139... 購入。どういう話かさっぱりわからんのだけども設定資料集が 7月に出るらしく、これも買って楽しむのがよさそう。https://www.amazon.co.jp/dp/404733541X/

プリインストールの Astro's Playroom 良い。軽いデモ程度のものかと思ってたら違った。アダプティブトリガーやハプティックフィードバック、なるほどこんな感じか〜という感想。

本体の重量はやはり重い、サイズはでかい。果たして何年後に小型化して、それはどのくらいのサイズになるのだろう。

歴代の初期モデルと小型版発売日を見てみると、

PS 1994/12/3 ; 2000/7/7

PS2 2000/3/4 ; 2004/11/3

PS3 2006/11/11 ; 2009/9/3 ; 2012/10/4 

PS4 2014/2/22  ;  2016/9/15

PS4 Pro 2016/11/10 ; 小型版なし

このような具合。2023年末〜2024年には出るかも? 

なるべく早くに小さく軽くできれば少なくとも輸送に関わるコストのようなのは減って嬉しいんじゃないかなと思う。電車に乗って買いにいく人の辛さも減る、お店の人たちの運ぶしんどさもきっと減る。

2021年4月25日日曜日

Silent Red 軸

今ギョームで使っているクリア軸なキーボードは6年くらい使用。先日重い重いと言われたので、これを機に軽い Silent Red 軸を使ってみることにした。重さの他には tactile bump から linear に変わるものの、かな〜り前には重い linear な黒軸使っていたので linear の感触は初ではなかったりする。

キートップ外してみると軸は確かに Silent Red なんだけども、ある事についてやや疑問があったので購入元へ問い合わせをした。どんな回答が返ってくるかな。

2021年4月20日火曜日

JAM

先週から急にジュディマリの曲を聴きたくなり、 YouTube で MV 見たり Amazon Music で延々と流したりしていた。そして適当に DVD 二つ買った。画質は良くない。

どこの誰が言ってたか思い出せないのだけど、何かで見た「ボーカル以外は以前出した曲をその後も演奏できるけど、ボーカルはその歌詞で歌えなくなる」のようなことってジュディマリにも当てはまるんかなーと適当なことを考えつつ。。

2021年4月4日日曜日

PS5

春、夏くらいまでは」と買いていて、先日オプーナの抽選販売に当たった。1,2回は落選し、その後の繰り上げ抽選で当選だったので、購入意欲のあった人の何割かは今はもう興味が薄れているのではないかな。または他の抽選販売にも申し込んでいてそっちで当選、購入ずみなのかしら。

https://www.playstation.com/ja-jp/ps5/games/ をざっとみても別段プレイしたいタイトルはないな・・と思いつつも、PS4 のもプレイできるし入手しておくことにした。互換なかったら買わなかったと思う。蕎麦屋の出前的に鋭意生産しているのか、出荷は今月下旬らしい。

キムタクが如く Remastered はやたらお求めやすい価格。PS4では未プレイだったのでちょうどいいな。

https://www.yodobashi.com/category/140007/140008/500000144001/500000144000/?word=ps5

https://ryu-ga-gotoku.com/judgeeyes/ 

2021年3月18日木曜日

LINEの件

残当

まぁ終わりの始まりということにはならないだろうし、一方なったらなったで面白いね。

2021年3月6日土曜日

この先

今の会社は入社して〜年になり、自己最長ではある。勤続年数なんてものはほぼ意味はなく、N年迎えるとリアクションにやや困る記念品がもらえたり、入館に使うカードのカラーが変わったりするのみ。

社内のお作法みたいなのにはそれなりに馴染んでいるかもしれないものの、仕組みやツールはコロコロ変わるしアンラーニングのコストがそれなりにあるので、まっさらな状態の方がむしろ色々いいとも思う。

おちんぎんの面だと、「月々振り込まれるもの」としては以前いた某社の後期のが上であり、そう思うと現職での振る舞い方をだいぶ誤ってきた感はある。新卒の方よりも今の自分のが低い可能性もある。(えっ、お前新卒より優秀と思ってたの!?といわれると、身分弁えていませんでした、すみませんとしか)一方以前の会社に居続ける選択肢はなかったわけだが。

税金の取られっぷりをみるとこれから上がったところでねぇ・・・という気持ちもあり、チンタラ上がっていく程度ではこれも意味がない。職位のレベル上げはどういうメリットがあるのかさっぱり見えず、レベル高いのに、、えっそうなのという人をみてモヤモヤはする。また、上がっていくよりも元からそのレベルで入った人のが高いらしいというのもあるとね。真偽は不明なものの火のないところになんとやら。

さて、ある日突然「君はパフォーマンス良くないから来月で辞めてね♡♡♡」と言われる日が来たとした場合、はて私は次どこかへ入れるのだろうか?という疑問は大いにある。いわゆる「キャリア」として積みあげられているものがない。〜〜にいたから〜〜ができるというのはなく、正直、あまりよろしくない状況である。

社には〜〜の凄い人、〜〜の凄い人はいるけど、関係はないし、私は何にもなれていない永遠のワナビー。


プライベートでは相変わらず主だったライフイベントはなく、今度もないだろう。


さぁどう生きていこうかな。

2021年2月28日日曜日

gtdl

Go でサポートしているプラットフォームは  go tool dist list で見れるというのをどこかで知ったので記録。Go 使っているわけではないけども。 

$ go tool
addr2line
asm
buildid
cgo
compile
cover
dist
doc
fix
link
nm
objdump
pack
pprof
test2json
trace
vet
$ go tool dist
usage: go tool dist [command]
Commands are:

banner         print installation banner
bootstrap      rebuild everything
clean          deletes all built files
env [-p]       print environment (-p: include $PATH)
install [dir]  install individual directory
list [-json]   list all supported platforms
test [-h]      run Go test(s)
version        print Go version

All commands take -v flags to emit extra information.
$ go tool dist list
aix/ppc64
android/386
android/amd64
android/arm
android/arm64
darwin/amd64
darwin/arm64
dragonfly/amd64
freebsd/386
freebsd/amd64
freebsd/arm
freebsd/arm64
illumos/amd64
ios/amd64
ios/arm64
js/wasm
linux/386
linux/amd64
linux/arm
linux/arm64
linux/mips
linux/mips64
linux/mips64le
linux/mipsle
linux/ppc64
linux/ppc64le
linux/riscv64
linux/s390x
netbsd/386
netbsd/amd64
netbsd/arm
netbsd/arm64
openbsd/386
openbsd/amd64
openbsd/arm
openbsd/arm64
openbsd/mips64
plan9/386
plan9/amd64
plan9/arm
solaris/amd64
windows/386
windows/amd64
windows/arm

$ go tool dist list |cut -d/ -f 1 |uniq
aix
android
darwin
dragonfly
freebsd
illumos
ios
js
linux
netbsd
openbsd
plan9
solaris
windows

$ go version
go version go1.16 darwin/amd64

'solaris/amd64' と、Solaris は x86_64 だけらしい。NetBSD より OpenBSD のが多いのが意外な。

2021年2月25日木曜日

カーネル本より #2

3章、スレッドと軽量プロセス で混乱気味。 

3.2 基本的な概念要素 で 

本節では、3つの重要なタイプであるカーネル・スレッド、軽量プロセス、ユーザ・スレッドについて述べる

とある。ここの軽量プロセス( lightweight process, LWP ) が、?

カーネル支援ユーザ・スレッドのことである

と書かれていて、読んでる最中はいまいちピンと来ず、 「支援」と書かれているからかな・・と思い

すべてのプロセスは、1つあるいはそれ以上のLWPを持つ。その各LWPは別個のカーネル・スレッドで支援されている(図 3.4)

その図には 1つの P(プロセス) が複数のL(LWP) と対応していて、L と K(カーネル・スレッド) が 1:1 で対応している。

各LWPはカーネル・スレッドに関連している一方で、カーネル・スレッドにはシステム・タスクに貢献してLWPを持たないものもある。

 ・・・その後に

メモ:  LWP という術語は、SVR4/MP と Solaris 2.x の術語から借りてきたものである。 SunOS バージョン 4.x では、LWP は次の項のユーザ・レベル・スレッドを指しているので、混乱がある。しかし、本書では、LWP をカーネル支援ユーザ・スレッドとして一貫して用いる。あるシステムでは、仮想プロセッサとして用いているが、本質的には LWP と同じである。

はい・・?

カーネルがLWPを生成、同期、管理する機構を提供する一方で、LWPの賢明な使用はプログラマに任される。多くのアプリケーションはユーザ・レベル・スレッド機能の方がよりよいサービスを受けられる。

と。スレッドのご利用は計画的にと。「次の項」の 3.2.3 ユーザ・スレッドには以下

Mach の Cスレッドや POSIX の pスレッドなどのライブラリ・パッケージを介して実現する。

うーん・・?グリーンスレッドとは違う?ややわけがわから無くなってきたのでなんとなく wikipedia を頼ると・・・ https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89_(%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF)#%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89%E3%81%A8%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89

書かれている、「カーネルスレッドとLWPを総称してネイティブスレッドと呼ぶこともある。」だと自分としてはしっくりくる感。

その後の 3.5 節ではスケジューラ・アクティベーションが出てくる。前の NetBSD 。https://ja.wikipedia.org/wiki/Scheduler_activations

「Scheduler activations は 1999年に Anderson、Bershad、Lazowska、Levy により提唱された」と書かれているけど 1991年ではないかな。Received June 1991; revised August1991; accepted September 1991とある。

https://en.wikipedia.org/wiki/Light-weight_process

原書が出た当時に触ってたら「これなー」となるんだろうな。2000年代前半にいた職場では Solaris 入れたラップトップを持ってる人いたけど、LWP がどうの、というのは一度も聞いたことがなかったなぁ。

https://docs.oracle.com/cd/E19253-01/819-0390/mtintro-75924/index.html

Solaris のマルチスレッドライブラリと標準

 

その後2003年には Linux で ネイティブなパジックススレッドライブラリが出てくる。

Red Hat Linux 9 のプレスリリース残ってるのね

https://www.redhat.com/en/about/press-releases/press-redhatlinux9

2021年2月17日水曜日

OS本

古のカーネル本はいくつか買ったので、さて、ナウなOS本を今買うとしたら何になるのだろうと熱帯雨林のサイトで探してみると以下が見つかる。

オペレーティングシステムの概念 https://www.amazon.co.jp/dp/4320122534/

だが2010年刊と10年も前、原書は 2004年。

https://www.amazon.co.jp/dp/0471694665/

和訳版は7版までだけど、原書なら 10th まで出ていた。このペースだと再来年には11th ?

2008, 8th https://www.amazon.co.jp/dp/0470128720/

2013, 9th https://www.amazon.co.jp/dp/1118093755/

2018, 10th https://www.amazon.co.jp/dp/1119456339/

なかなか値が張る。9th までは O'Reilly Online Learning にあるので 9th をちらっと読んでみよう。ToC みて 10th めちゃくちゃ欲しい!となれば買おう。

https://www.os-book.com/OS10/index.html https://www.os-book.com/OS9/index.html

カーネル本より

1-3の 3. から

1.3 過去、未来  より

最近その卓越した地位も Microsoft 社の Windows や Windows NT オペレーティング・システムの出現によって脅かされている。デスクトップ市場のようなローエンドでは UNIX は戦いに負けたように見える。

 

1.3.2 UNIX の何が間違っているか  より

UNIX は素晴らしいオペレーティング・システムであるが、多くのユーザはオペレーティング・システムではなく、単純にある仕事をしてくれる能力だけを欲する。これらのユーザは基盤となるファイル・システム構造やプロセス・モデルの優雅さには興味を持っていない。ただ、特定のアプリケーションを最低のコストと手の掛からない方法で実行させることを望んでいる。

 

そうよねぇ。今も Windows なり macOS なり、使いたいアプリケーションがちゃんと動きさえすればいいとは思う。例えば、Windows Update がー、ソフトウェアアップデートがー、とかを気にしなくてもいい未来は死ぬまでに来るのかしら。スマホ、タブレットがそれに近いのかもしれない。使ったことがないけどもしかして Chromebook ?

 

この書籍読んでると、上に書いたようになかぐろでの表記がしばしばある。他のをいくつか挙げると、32ビット・マシン、ジョブ・コントロール、コマンド・ヒストリ、オリジナルの UNIX ソース・コード、デバイス・ドライバ、メッセージ・キュー、など。どれも今は「・」書かないんじゃないかな。当時はそういうものだったのか、訳者の好みだったのか。

なかぐろではないけど、カリフォルニア大学バークレー校と書かれたすぐ後にはカルフォルニア大学バークレー校と書かれていた。揺れている。

 

IBM の knowledge center はなかぐろってる。ナレッジ・センターとは書かれていないけど。

https://www.ibm.com/support/knowledgecenter/ja/SSFKSJ_9.0.0/com.ibm.mq.pro.doc/q002620_.htm

 

1.4 本書の意図 より

SVR4 には最も注意を傾けたが、4.3BSD や 4.4BSD、Mach にも十分な用紙を割いている。商業用 UNIX の中では本書は SunOSと Solaris 2.x に最大の用紙を割いた。それはただ単に、UNIX 市場における重要性だけでなく、Sun Microsystems 社がその後の基本リリースへの統合された多くの技術貢献の責任を負っていることと、これらのシステムに対する方の出版物のためである。

 「用紙を割いた」という表現は新鮮だった。紙面だと雑誌や新聞紙になる?紙幅なりページ数、頁数でもよさそうな。。 

 

読み終えたら単に「やっぱり Solaris はすごかったんだね」という感想になると予想。


2021年2月12日金曜日

カーネル本

最近、なんの気無しに古いカーネルな本を数冊買った。読むとは言っていない。

1. https://www.amazon.co.jp/dp/4320025512/

1991/6 刊、丸善。手元のは 2000/9 の14刷。

原書は 1986/5 刊 https://www.amazon.co.jp/dp/0132017997/ 

 

2. https://www.amazon.co.jp/dp/4890529306/ 

1996/4 刊、ソフトバンク。手元のは刷数不明。1刷かな。

原書は 1994/6 刊 https://www.amazon.co.jp/dp/0201633388/

 

3. https://www.amazon.co.jp/dp/4894711893/

2000/5 刊、ピアソンエデュケーション。まだ手元にない。手元のは1刷。3冊中で最も鈍器度が高い。表紙には 4.4BSD, Solaris 2.x, Digital UNIX などと書いてあってそれだけで古い本であることが感じられる。

原書は 1995/10 刊 https://www.amazon.co.jp/dp/0131019082/

 

1 や 3 のように原書発刊から5年くらい経ってたのはすごいな。ものによっては原書新版が出てたりするくらいな気がする。

当時はどうやって「この専門書良いから翻訳して日本でも出そう」という動きが発生したんだろうか。ネットニューズで盛り上がったりしてたのかしら。 UNIX magazine は 1986年創刊、 UNIX USER は 1992年創刊だったようだ。

 

1 の Maurice J. Bach 氏は書籍に略歴は書かれていなかった。ググってもこの本しか出てこない。

2 の Curt Schimmel 氏はベル研UNIX開発チームの元メンバー、発刊当時は SGI の中の人だったらしい。お〜〜

3 の Uresh Vahalia 氏は現在 HPE の VP of Engineering の方のはず。当時は EMC の中の人だったと。

どれもパラパラっと読むくらいかな。いずれも「コンディション: 良い」以上のを買って、1 が最も高価だった(当時の定価よりかは安い)。2 は 1,000円、送料まで入れると 3 がもっとも安価で手に入れられたのだった。

 

これは 2001年: あえてSolarisを使う理由  https://askslashdot.srad.jp/story/01/08/29/1320256/

 

ところでウルリッヒのスレッドプログラミング本は一体どうなったのだろう。2018 年に発売してたように見えるけど、出てないと思う。

https://www.amazon.co.jp/dp/0131487264/


2021年2月6日土曜日

ACM 更新していた

ACM のメンバーシップ更新。

O'Reilly Learning の技術書利用が主目的で、社の制度で O'Reilly Learning 利用することも可能だけども、前に塩対応されたので ACM メンバーになって使い始めた、という感じ。

一冊すみからすみまで読み切ることはなくリファレンス的利用が多いな。ちゃんと読んだ方が血肉となるだろうと思いつつ出来てはいない。

去年はしばらく(数ヶ月)利用しておらず、久しぶりになにか読むかと思ったら O'Reilly Learning を deactivate されており Customer Service Representative に問い合わせしたのだった。利用するならちゃんと利用しなさいてこと。

Early Release で出てきてる書籍で気になるのもあるのでぽちぽちと playlist に追加。AWS Cookbook やら High Performance MySQL, 4th Edition あたりよさそう。

BSD grep の今

 container_of をゴソゴソと見てるとき、macOS 上にソース持ってきて当初は grep してたのだけど、あれ、これやたら遅いな?と思いやっぱり ripgrep だなと rg にしたのだった。

macOS の grep (BSD grep) はGNU grep より遅いね、というのはささっとググるだけでこんな感じで見つかる。BSD grep が遅いのか、GNU grep が速いのか。

https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html

http://jlebar.com/2012/11/28/GNU_grep_is_10x_faster_than_Mac_grep.html

 

うん、おそい。

$ time grep -r ^#include . |wc -l; grep --version
  341659

real    0m14.074s
user    0m12.134s
sys    0m1.902s
grep (BSD grep) 2.5.1-FreeBSD

$ time ggrep -r ^#include . |wc -l; ggrep --version
  335204

real    0m2.162s
user    0m0.762s
sys    0m1.411s
ggrep (GNU grep) 3.6
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others; see
<https://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.

$ time rg ^#include |wc -l; rg --version
  335204

real    0m0.557s
user    0m1.036s
sys    0m2.906s
ripgrep 12.1.1 (rev 9c8d873a75)
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)

ん、BSD grep とそれ以外で数が合わない。いやいや・・diff とってみてもこの差が出るのかわからんぞ・・


以下は VM な FreeBSD 12.2-R で。BSD grep 最も遅いけどもだいぶマシになっている感。

$ time grep -r ^#include . |wc -l; grep --version
  341714

real    0m2.061s
user    0m0.999s
sys     0m1.149s
grep (GNU grep) 2.5.1-FreeBSD

Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ time bsdgrep -r ^#include . |wc -l; bsdgrep --version
  341714

real    0m3.863s
user    0m2.525s
sys     0m1.435s
bsdgrep (BSD grep) 2.6.0-FreeBSD

$ time rg ^#include |wc -l; rg --version
  335259

real    0m0.872s
user    0m1.242s
sys     0m2.031s
ripgrep 12.1.1
+SIMD -AVX (compiled)
+SIMD +AVX (runtime)

これもまた数が合わない、今度は ripgrep が。

find ~ xargs しましょう

 $ time find . -type f|xargs rg ^#include |wc -l
  335259

real    0m1.257s
user    0m1.356s
sys     0m2.155s
$ time find . -type f|xargs grep ^#include |wc -l
  335259

real    0m1.906s
user    0m0.824s
sys     0m1.235s
$ time find . -type f|xargs bsdgrep ^#include |wc -l
  335259

real    0m3.522s
user    0m2.560s
sys     0m1.110s

2021年1月31日日曜日

ファイルシステム

Linux シェアを見ると、Ubuntu が圧倒的、その後に続く CentOS と Debian を合わせるとこの3つで8割強。

Ubuntu, Debian のデフォルトのファイルシステムは ext4 で CentOS は 7 から XFS 。XFS をデフォルトにしてるのは RHEL とその互換(を謳うもの)以外に知らず、XFS のこと自体もあまりよく知らないのだった。( SLES はOS用がbtrfs、他はXFS )

XFS の出自としては IRIX だけども IRIX がまだ多用されていた頃に触れる機会はなかったので当時のことも全くわからない。稼働する実機を見たことがないという。RHEL での XFS 採用は確か 5,6 で scalable filesystem add-on とし存在していたなというのは記憶にある。

ちょっとググると、

http://www.intellilink.co.jp/article/column/oss-rh02.html

"RHEL 5、6でも有償のアドオンとしてXFSは利用可能です。RHEL 7のXFSは無償でサポートを受けられるようになりました。"

と。また、

"昨今では、多数のプロセッサーやディスクアレイを搭載したサーバーに大容量ファイルシステムを構築するなどの要件もあり、ext系ファイルシステムではスケーラビリティの限界が見えつつあります。"

のように書かれているのだけども、ext4 不向きなユースケースは多数存在するのかしら。

File systems and storage limitsを見るとまぁ確かにXFS はすごい。Maximum file size よりも Maximum file system size かな?

phoronix の記事見ると性能も◎ https://www.phoronix.com/scan.php?page=article&item=linux-58-filesystems&num=1

とすると Ubuntu や Debian でもデフォルトにされてもよさそうに思う。あくまでデフォルトでしかないからわざわざそうしてないだけかもしれない。

「XFSの中の人」の数の関係もあるのかな。

2021年1月30日土曜日

container_of

ツイッター上で container_of の話題を目にした。カーネルは薄ーく読む程度しか関わりがなく「なるほどそういうのもあるのか」という感じ。

はてこのマクロはいつからあるんだろうと調べてみると 2.5.28 からある模様。2002/7/25リリース。

https://www.linux.com/news/linus-torvalds-linux-2528/

https://lwn.net/Articles/5482/

$ find linux-2.5.28 -name \*.[ch] |xargs rg container_of|wc -l
      27

今日時点での最新stable 5.10.11 はどのくらいあるか。

$ find linux-5.10.11 -name \*.[ch] |xargs rg container_of|wc -l
   17222

ほえ〜

2005年にGKHさんが書いてる=> container_of() 元は2003年に Linux Journal に書かれたらしい。

マクロはその後2017年によりシュッとした kernel.h: handle pointers to arrays better in container_of()


そうそう、2002年、回線なんてこんなんだったか。。https://bb.watch.impress.co.jp/cda/special/16691.html#2002

数年後に開始のメタルプラス使っていたな。その前何を使っていたか覚えていない。

2021年1月13日水曜日

初詣

二箇所行った。ひとつ目で丑の小さな置き物に入ったおみくじを引いて、中吉。結びの言葉は「今は何も控えよ」と書かれていた。

ふたつ目で明治神宮へ行き大御心を引く。今回は一七で明治大帝の一首、これまでのと被りなし。(心はいつも清く明るく持ちましょう)と。 去年からか英文も併記されている。

2021年1月10日日曜日

加水分解

何年か使っていた Anker の USB 3.0 、4ポートのハブ。どうもケーブルが加水分解してしまいベットベトに。被覆はボロボロと剥がれ落ちてしまうので処分。さようなら。