The 3′ cis-Acting Genomic Replication Element of the Severe Acute Respiratory Syndrome Coronavirus Can Function in the Murine Coronavirus Genome (Scott J. Goebel et al, Journal of Virology 2004 Jul) https://www.ncbi.nlm.nih.gov/pmc/articles/PMC434098/
この時点でMHV, BCoV, SARS-CoV他との3'UTRの比較をやってるのか。

SARS-CoV-2, SARS-CoV, MERS-CoV, BCOV, MHV間である程度の類似性が見られるってのも面白いな。同じコロナウイルスの仲間だからその辺も似るっちゃ似る、ってことなんだろうけど…SARS-Cov-2以外のウイルスにおける3'UTRの研究成果をSARS-CoV-2に持って来れる（もしくはその逆）っていう可能性はあるんだろうか。

ああ、Figure 1にそう書いてあるじゃないですかー（ちゃんと読んでないのがバレた）

5'UTRが265塩基、3'UTRが337塩基、でいいのかな？ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7766253/
The RNA Architecture of the SARS-CoV-2 3′-Untranslated Region (Junxing Zhao et al, Viruses 2020 Dec)

ふーん（ぐぐって適当に見てる）、SARS-CoV-2の場合は5'よりも3'UTRの方が注目されてるのかな。5'側/3'側、それぞれのUTRの大きさがどれくらいか知りたいところだけど。

今だとRNAシーケンスを統計的に処理して、stem-loop構造のどの辺のRNAに変異が起こりやすいか（という所までは自分が院生やってた頃の話）に加えて…それが立体構造の変化にどう寄与するかなんてのもシミュレーションできるのかなあ。

おお、今の論文ってCC-BY-NC-NDとかで公開されてるのか。 https://pubs.acs.org/doi/10.1021/jacsau.3c00641

（ちょっとウイルス絡みの研究とかやってた時期も院生時代にあったもんで…こーゆう話、好物なんすよ）

3'UTRってことは末端側か（先頭の5'側にあるウイルスもあるけどSARS-CoV-2はそうじゃないってことか）。ウイルスRNAの非翻訳領域って立体構造を取って色々な働き（分かってないこともある）をするという箇所だからなあ…これは面白そう。

このアカウントは、notestockで公開設定になっていません。

趣味にも成果主義が求められているなーというのは実感としてあるんだけど、タイパ主義が入ってくるのも時間の問題っていうかもう入ってるんだろうなあ。

タイパ思想っていうか成果主義なんだろうなあ。「成果」として他人に認められないものは何をやっても無駄、って。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

NetBSD: sys/endian.h, endian.h
DragonFlyBSD: sys/endian.h, endian.h
OpenBSD: sys/endian.h, endian.h
FreeBSD: sys/endian.h, endian.h
Slackware: endian.h

BSD系だと<sys/endian.h>にしないといけないかなーと思っていたけど、<endian.h>で十分そう。

わかる。わくわくする。

このアカウントは、notestockで公開設定になっていません。

ぐふぁ（吐血

このアカウントは、notestockで公開設定になっていません。

Blueskyで知った良記事。「おわりに」の項は必読。五寸釘用意しよう。 Blueskyの一ヶ月前史 (2023/4/15) https://riq0h.jp/2023/04/15/110859/

Mastodon側から直接のぞき窓へこんにちわーはできないだろうから、多分一旦repostすることになるんだろうな。

FM++の使用するCODECの仕様、https://fmplapla.com/core-c を見たところで何も得るものは無い（し教科書体を使うweb pageは無条件で悪印象を抱いてしまいます）…Opusらしいというのは分かったとしても、ビットレート可変っぽい感じがするとして、どの範囲で可変するかが分からない…ラジオ局のpodcastとかを考えるに、せいぜい上限を64kbpsにしているんじゃないかと勝手に推測してみる。

fmplapla --station fmhanabiを実行したマシンでtcpdumpすると、is1304.fmplapla.com.httpsになるから…局名の指定に何か鍵があるのかな。fmhanabiを再生しているmplayerの表示は
AUDIO: 48000 Hz, 2 ch, floatle, 0.0 kbit/0.00% (ratio: 0->384000)
Selected audio codec: [ffopus] afm: ffmpeg (FFmpeg opus)
ってなっているので、ビットレートは分かんないけど…やっぱなんか疲れる音な気がする。

tcpdumpでルータの通信状況を見るに、os1302.fmplapla.com:443とやり取りしてるから…SSL越しの何か(websocket?)なんだろうか。

FM++のスキルでFM HOT 839は聞けるけど、https://kemasoft.net/?Stories/2022-04-04 にあるツールでは聞けないってことは…伝送経路どうなってるんだろう？

FM HOT 839（エフエムさがみ）をAmazon Echo Dot越しのFM++(Opus/ビットレート不明)で聞くのと、サイマルラジオ(WMAv2/64kbps)で聞くのとで、どうもOpusだと秋元系の曲がしゅわしゅわ聞こえて音質悪いなーと思ってしまうんだよなあ。気のせいかもしれないけど。

特にMisskey見ていて思うけど（開発者の事情まではちゃんと見ていないので外していたらゴメン）、あれだけ盛り上がるプラットフォームを作れるなら、まだまだ希望はあると個人的には思ってる。とはいえその希望は「こっち側」のものであって、日の丸なんとかとかごちゃごちゃいう「そっち側」のものでは決してないし、むしろ「そっち側」の人達は隙あらば潰そうとしてくるから。

結局日本のITがうまくいかないのって、日経何とかの記事とかで「日の丸云々」とか書かれちゃってさあ、成功しなければ腹を切れ、金を稼げなければ穀潰し、みたいな謎のレッテルとかプレッシャーをかける人達がいるからじゃないの？

「成功するか」「成功するぞ」みたいな成否にうるさい人を呼び寄せるんじゃなく、ワイワイと楽しくお祭りのようにやっていく人をどれだけ集めて進めていくかというのが重要なんじゃないのかなーというのが、Misskey/Nostr/Blueskyを見ていて思ったこと。（Blueskyのpostはここで止めてる）

ここで何尋ねようか、未だ思い出せません…

何故etcupdateは/etc/master.passwdまで更新しようとするのか…絶対これうっかり更新してログインできなくなったうぎゃーする人いるよ怖いよこれ

NetBSD-current暮らししてる人って、/usr/share/man/cat4/<自分の使っていないアーキテクチャ>とかって用意してるもんなんでしょうか。etcupdateでいちいちCreate?されるの、ちょっと面倒に感じてきたので（邪魔だけど）作っちゃった方がいいのかなって。