カジュアルブロックに対する抑止力になり、また明らかに「これはヤバいよね」というアカウントの抑止力に…なるのかなあ…?(ブロック情報の閲覧可能な件)
※個人的にThreadsで横行するカジュアルブロックにあまり良い印象は持っていない、自分も使うっちゃ使うけど
OpenBSD(uaa@), Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
カジュアルブロックに対する抑止力になり、また明らかに「これはヤバいよね」というアカウントの抑止力に…なるのかなあ…?(ブロック情報の閲覧可能な件)
※個人的にThreadsで横行するカジュアルブロックにあまり良い印象は持っていない、自分も使うっちゃ使うけど
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
一総通(4) ~A1A Breaker~ https://jh8.seesaa.net/article/201603article_1.html
----
送信速度の設定には「スピード(文字/分)」と「PARIS(語/分)」の2つがあります。
私は、この2つの切替え方が分からず、PARISの機能は当初全く使っていませんでした。
あるときたまたま分かったのが、数字の入力窓をクリックするのではなく、その横の部分をクリックすればいいのだということでした。(下図を参照。)
----
PARIS速度の設定ができずに困っていたのですが、「スピード」ないし「PARIS」の囲われた中をダブルクリックで切り替えとか…ポインタをかざしてクリックすると「ダブルクリックすると太字となり有効になります。」とか言われても正直「???」ですよ。
そーゆーとこだぞ、アマチュア無線向けソフトウェアのダメなところって。よく分からないUI、詰め込みすぎな機能…多少は整理して作らないと使い手は困るんだぞっ。と八つ当たりしてみよう。
音楽におけるメジャー vs インディーズのようなのが、書籍における一般誌 vs 同人誌だという認識。
このアカウントは、notestockで公開設定になっていません。
ミニコミ誌というのもかつてはありましたよね…(今も?) https://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%8B%E3%82%B3%E3%83%9F
いわゆるアニメ・マンガ・ゲーム等のオタク文化に染まったカテゴリの物を同人雑、それ以外をZINEとして切り離したいというZINE側の主張のように思えますけど…どっちも同人誌で良いと思いますし、おたく文化のイメージを払拭と言っている時点で十分「何言ってんのあんたら」案件では?
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
アマチュア無線の国家試験から電気通信術(モールス符号の受信)が無くなったという理由で、国内電信級特殊無線技士とか総合無線通信士を取るって流れなのか。
流石に一総通持ち出されちゃうと、それ以外の資格ではひれ伏す以外に何もできなくなるからな。一陸技ですら「たかだか一陸技程度で」と鼻で笑われてしまう(一総通を取るための通過点に過ぎないので)。
マウント取るためにそこまでやるか?って気がしなくもないんだけど、これが現実である以上はなあ…ていうか本当のプロならマウントなんか取らないと思うんだけど。
ん?32bit time_tでも負の値になるのが2038年だからってことなので…格納自体はuint32_tとしておけばとりあえずあと68年は引っ張れる?
※実はこういうの考えるの結構楽しい
そっか、unsigned long(uint32_t)に直しちゃう手があるか。単なる問題の先送り、ではあるんだけど。 https://ja.wikipedia.org/wiki/2038%E5%B9%B4%E5%95%8F%E9%A1%8C
time_tが32bitって気づいてれば…時間返せとか思ってたり思ってなかったり。
とはいえ、64bit time_tは避けて通れない道でもあるからなあ。落とし所をどこにするかもう少し探る必要はありそう。
気分的には今すぐ全部捨ててやり直したい気分ではあるけど、どうせまた似たようなことをすることになるので捨てるに捨てられないという未練があるというかなんというか。
あ゛あ゛あ゛あ゛あ゛あ゛あ゛、単に時刻の格納をするだけなら1bitシフトとかもあるけど、時間計算をしてパフォーマンスの算出とかもやってるから精度を落とすことは許されないんだ。
1970/Jan/01 00:00:00~2004/Jan/10 13:37:03 (1073741823sec)の範囲を2038年から後の34年分に振る?
ソフトウェアが2000年のリリースなので、2000年~2004年の範囲のデータが正しく扱えないという問題を抱えるからこの解決法もあまり良い方法じゃないけど…
こういう、先が無いふっるいシステムのお守りの真似事をすると、どっかの日経の偉そうな人が主張する「コボラーは死ね」について*ある程度*は理解する。
ただし、それは「未来の無い古いシステムのお守りを若手にやらせるな」であって、「特定の言語とそれを使う人々を焼け」では決してない。
今後あの偉そうな御仁は今後COBOLだけでなくC言語およびそれを使う人間を間違いなく攻撃対象にするであろうことは、これで確信した。
FATファイルシステム(2秒単位の記録)というのがある以上、単純に1bit右シフトで68年分の時間は稼げると思うけど。
time_tが64bitでも良いように細工したのを一旦すべて捨てる、はともかくとして…
32bitの領域で2038年以降をどう表現すんだよ、という問題を考えないといけないんじゃないのコレ?
uaa@slackware-vm:~$ cat test.c
#include <stdio.h>
#include <time.h>
int main(int argc, char *argv[])
{
printf("%d\n", sizeof(time_t));
return 0;
}
uaa@slackware-vm:~$ cc test.c
uaa@slackware-vm:~$ ./a.out
4
uaa@slackware-vm:~$ uname -a
Linux slackware-vm.uaa.org.uk 5.15.145-smp #1 SMP PREEMPT Sat Dec 23 14:23:29 CST 2023 i686 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz GenuineIntel GNU/Linux
uaa@slackware-vm:~$
な ん で す と … !