コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2020年5月9日 >>> 2020年4月30日
link もっと後

2020年5月9日

Kindle for PCはダウンロードが遅い?

目次: Kindle

KindleのアプリはKindle Fire版、Android版、PC版など、いくつか種類があります。普段使っているのはKindle FireとKindle for PCです。どうもKindle for PCのダウンロードが遅い気がします。

Kindle Fireも決して速いとは思いませんが、大抵はマンガ1冊が1〜2分でダウンロードできているので、5Mbpsくらいは出ているんじゃないかと思います。

Kindle for PCはかなり遅い(1〜2Mbpsくらい、日によって違う)です。同じネットワークを使っているのに、差が出るものですかね?PC向けだけ帯域ケチるとか、そんな面倒なことしないよなあ?うーん?

Kindleアプリの動きがまた変わったけど、いつもどこかがダメ

Kindle Fire HDのアプリはたまにアップデートされて動きが変わります。今年の頭くらいだったか?覚えてないですけど、また動作が変わりました。

良くなったところ
フィルター「すべて」を選択したとき、本が多すぎると、数十秒フリーズしたり、アプリがクラッシュするバグが直ったこと
悪くなったところ
本のグループが意図せず表示されてしまうバグが埋め込まれたこと

新たなバグは再現率100%です。再現方法も簡単です。

  • ホーム → 「本」のタブ → すべての本を表示、をタップ
  • 本の一覧が表示される
  • グループ化された本をタップ(マンガの1〜最新巻までをグルーピングする機能)を選択
  • ホームボタンでホームへ → 「本」のタブ → すべての本を表示、をタップ
  • 先ほど見ていたグループ化された本が表示される(バグ)

この順に操作したとき、本来は本の一覧が出なければなりませんが、グループ化された本が再表示されてしまいます。明らかにバグってます。

このバグは、ユーザー側の操作で回避可能です。

  • グループ化された本が意図せず表示される(バグ)
  • ホームボタン「ではなく」戻るボタンでホームに戻る
  • もう一度、すべての本を表示、をタップ
  • 本の一覧が表示される

ユーザーの操作に影響が出るバグですし、テスターに触らせたら数分で見つけそうなのにね?KindleってUIのテストしてないのかなあ??

編集者:すずき(2021/12/08 03:49)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年5月8日

RISC-Vのgas

目次: RISC-V

マクロの名前にTypoと思しきものがあったので、riscv-binutils-gdb(サイトへのリンク)にPull Requestをしてみました。

RISC-V向けのgasの実装では、命令に対応した名前のマクロがあります。

命令の名前とマクロの名前の関係

//opcodes/riscv-opc.c

//通常は命令の名前からドットを除いて、大文字にした名前
//    vadd.vv -> MATCH_VADDVV

{"vadd.vv",    0, INSN_CLASS_V,  "Vd,Vt,VsVm", MATCH_VADDVV, MASK_VADDVV, match_opcode, 0 },
{"vadd.vx",    0, INSN_CLASS_V,  "Vd,Vt,sVm", MATCH_VADDVX, MASK_VADDVX, match_opcode, 0 },
{"vadd.vi",    0, INSN_CLASS_V,  "Vd,Vt,ViVm", MATCH_VADDVI, MASK_VADDVI, match_opcode, 0 },


//Reduce系の命令だけ名前が違う
//    vredsum.vs -> MATCH_VREDSUMV"S" のはずなのに、MATCH_VREDSUMV"V" になっている

{"vredsum.vs", 0, INSN_CLASS_V, "Vd,Vt,VsVm", MATCH_VREDSUMVV, MASK_VREDSUMVV, match_opcode, 0},

パッチの中身は簡単で、ベクトル命令の一部で、命令の名前とマクロの名前が違っていたので修正しただけです。この手の間違いがいくつあるか分からなかったので、ちょっとしたPythonスクリプトを書いてチェックしました。

マクロの名前チェックに使ったスクリプト

#!/usr/bin/python

import re
import sys

fname = sys.argv[1]
f = open(fname, 'r')

line = f.readline()
while line:
	if not line.startswith('{"'):
		line = f.readline()
		continue;
	line = line.strip().replace('}', '')
	line = re.sub('\{"([^,]*)",', r'\1,', line)
	line = re.sub('".*",', '', line)
	line = re.sub(' *', '', line)
	items = line.split(',')

	insnOrg = items[0]
	insn = items[0].upper()
	classInsn = items[2]
	matchInsn = items[3]
	maskInsn = items[4]
	aliasInsn = items[6]
	if not classInsn.startswith('INSN_CLASS_V'):
		line = f.readline()
		continue;
	if not matchInsn.startswith('MATCH_') or not maskInsn.startswith('MASK_'):
		line = f.readline()
		continue;
	if aliasInsn.startswith('INSN_ALIAS'):
		line = f.readline()
		continue;

	insn = insn.replace('.', '')
	matchInsn = matchInsn.replace('MATCH_', '')
	maskInsn = maskInsn.replace('MASK_', '')
	if matchInsn != maskInsn:
		print("MATCH != MASK: {:s} != {:s}".format(matchInsn, maskInsn))
	if insn != matchInsn:
		print("INSN != MATCH: {:s} != {:s}".format(insnOrg, matchInsn))
	line = f.readline()

条件を適当に継ぎ足して書いたのと、Pythonの経験値が低いのが相まって、エレガントさの欠片もないですね。仕方ない。実行結果はこんな感じです。

マクロの名前チェックに使ったスクリプト
$ ../checker.py opcodes/riscv-opc.c

INSN != MATCH: vzext.vf2 != VZEXT_VF2
INSN != MATCH: vsext.vf2 != VSEXT_VF2
INSN != MATCH: vzext.vf4 != VZEXT_VF4
INSN != MATCH: vsext.vf4 != VSEXT_VF4
INSN != MATCH: vzext.vf8 != VZEXT_VF8
INSN != MATCH: vsext.vf8 != VSEXT_VF8
INSN != MATCH: vredsum.vs != VREDSUMVV
INSN != MATCH: vredmaxu.vs != VREDMAXUVV
INSN != MATCH: vredmax.vs != VREDMAXVV
INSN != MATCH: vredminu.vs != VREDMINUVV
INSN != MATCH: vredmin.vs != VREDMINVV
INSN != MATCH: vredand.vs != VREDANDVV
INSN != MATCH: vredor.vs != VREDORVV
INSN != MATCH: vredxor.vs != VREDXORVV
INSN != MATCH: vwredsumu.vs != VWREDSUMUVV
INSN != MATCH: vwredsum.vs != VWREDSUMVV
INSN != MATCH: vfredosum.vs != VFREDOSUMV
INSN != MATCH: vfredsum.vs != VFREDSUMV
INSN != MATCH: vfredmax.vs != VFREDMAXV
INSN != MATCH: vfredmin.vs != VFREDMINV
INSN != MATCH: vfwredosum.vs != VFWREDOSUMV
INSN != MATCH: vfwredsum.vs != VFWREDSUMV
INSN != MATCH: vcompress.vm != VCOMPRESSV

明らかにTypoに見えるのはvred/vfred/vcompress系の命令で、vsとvvを取り違えています。

微妙なところなのはvzextです。他はドットを除いた名前なのに、vzextだけドットをアンダースコアに置換した名前です。ルールに一貫性が無いだけか、Typoか、どちらとも言い難いため、今回出したPull Requestでは修正していません。

Pull Request受け付けてるのかな?

リポジトリを見ていてちょっと気になったのはSiFiveの人以外、変更がほとんどないことです。著名プロジェクトでは珍しいです。もしかするとGitHubでPull Requestを受け付けてない(※1)可能性があります。

変更を提案するのはここじゃないとか、そもそも変更は受け付けてませんとか、何でも良いので反応があると嬉しいですね、週明けまで待ちましょうかね……。

(※1)本家および開発の場がGitHub以外に存在していて、GitHubをミラーにしているプロジェクトの場合、GitHub上で何か言っても無視されることがあるようです。

編集者:すずき(2023/09/24 13:12)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年5月5日

プレーヤー人口が増えるのは良いことだ

Splatoon 2のガチマッチ(Cランク)の難易度が下がった気がします。

1〜2か月前は、20kill対0killで負けたり、1分でノックアウトされたり、超フルボッコで負けまくるのが当たり前で、すっかりやる気がなくなっていましたが、今日久しぶりにやったら一度も負けず、あっさりC+ ランクになりました。

アクションゲームの腕は1か月やそこらで急に上達しないので、私が上達したというよりも、絶対勝てないおかしいレベルのプレーヤーとマッチする割合が減った、そんな感じです。

Stay Homeとかゴールデンウイークとかで、Splatoon 2のプレーヤー人口が盛り返して、初心者クラス(C-〜C+ ランクあたり)に合う人が増えたんじゃないかと推測しています。

最初からこのくらいの難易度だったら、ガチマッチ嫌いにならずに済んだんですけど、すっかりガチマッチ嫌いになってしまった(レギュラーマッチは好き)ので、もう遅いんだよな〜……。

編集者:すずき(2020/05/06 23:21)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年5月4日

C言語のマクロ

目次: C言語とlibc

C言語のマクロによる置換を、循環参照させたらどうなるでしょう?

循環するマクロ定義

A B C D
#define A B
A B C D
#define B C
A B C D
#define C A
A B C D

結論から言うと問題ありません。下記のような結果になります。

循環するマクロ定義、置換結果

A B C D

B B C D

C C C D

A B C D

4つ目の結果は、置換前のA B C Dと何も変わっていないように見えますが、実はそうではありません。下記のように定義するとわかります。

循環するマクロ定義、マクロによる置換結果を見やすくする

A B C D
#define A 1 B
A B C D 
#define B 2 C
A B C D 
#define C 3 A
A B C D
循環するマクロ定義、置換結果が見やすいはず

A B C D

1 B B C D

1 2 C 2 C C D

1 2 3 A 2 3 1 B 3 1 2 C D

4つ目の結果の「A」を例にとると、A -> B -> C -> Aと3回のマクロの置換が行われた結果、Aに戻っているわけです。#define A Bのマクロは1度しか適用されないようです。

C言語の仕様

C言語の仕様(C11 final draft (N1570) - 6.10.3.4 Rescanning and further replacementの第2項)を見ると、

2
If the name of the macro being replaced is found during this scan of the replacement list (not including the rest of the source file's preprocessing tokens), it is not replaced. Furthermore, if any nested replacements encounter the name of the macro being replaced, it is not replaced. These nonreplaced macro name preprocessing tokens are no longer available for further replacement even if they are later (re)examined in contexts in which that macro name preprocessing token would otherwise have been replaced.

(直訳)
2
置換されるマクロの名前がreplacement listのスキャン中に見つかった場合(ソースファイルの残りの前処理トークンは含まれません)、そのマクロは置換されません。 さらに、入れ子になった置換が、置換されているマクロの名前に遭遇した場合、それは置換されません。 後にそのマクロ名の前処理トークンが置換されていたであろうコンテキストで(再)検査されても、これらの置換されていないマクロ名の前処理トークンはそれ以上の置換はできなくなります。

正直言って何言ってんだお前……?って感じがしますけども、平たく言うと同じマクロを2回適用しない、ように読めます。

複雑版

下記のように同じマクロで何度も置換できそうなマクロを定義してみます。

循環するマクロ定義、より複雑版

#define A B C
#define B C A
#define C A B
A B C D
循環するマクロ定義、より複雑版、結果

A B A A C A B C B B A B C A C C B C D

1つ1つのトークンがどのマクロで展開されているか図示します。


循環するマクロ定義、展開の様子

複雑に見えますが、どのトークンを見ても同じマクロを2回適用されたものはないことがわかります。

関数型マクロの謎

しかし関数型マクロの場合は、不思議な挙動を示します。

循環する関数型マクロ定義

#define F(a) a G
#define G(a) a F(a)

F(7)(8)(9)
循環する関数型マクロ定義、結果


7 8 8 G(9)

展開の様子は下記のようになると思われますが、


循環する関数マクロ定義、展開の様子

どうして7 8 8 G(9) で展開が終わるのかが良くわかりません……。マクロF(a) を2回適用しない、というルールならば、7 8 F(8)(9) で止まらなければおかしいように思いますが、結果を見るとなぜかF(8) も展開されています。

編集者:すずき(2023/02/04 20:17)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年5月2日

ThinkPadと追加のGPU

今、使ってるノートPC(ThinkPad E480カスタムオーダー)には、Intelのグラフィクスと、Radeon RX 550が搭載されています。

Radeon RX 550はモバイル用としては結構強力で、主にゲームの時に助かっているのですが、Radeonを使ってゲームをしばらくやっていると、本体が触れないくらい熱くなり、しまいに熱暴走でクラッシュしてしまいます。

せっかくカスタムオーダーで追加したのに微妙な奴だな〜。

ドライバが挙動不審

このGPUはもうひとつ変なところがあって、デバイスマネージャでRadeon RX 550を「無効」にしてPCを再起動すると、冷却ファンが唸り続けます。

CPU利用率は極めて低いままにも関わらず、冷却ファンが全力稼働しているので、ファンの制御がおかしくなっているように思います。GPUの負荷を勘違いしているのだろうか?

プロセスを片っ端から終了させても収まらなかったところをみると、恐らくドライバが変なところにハマっている?のでしょうか。

デバイスを有効にするか、有効にしたあとに再度無効にすれば、CPUファンは静かになりますが、なんだか挙動不審ですよね……。

編集者:すずき(2020/05/06 23:40)

コメント一覧

  • hdkさん(2020/05/07 20:30)
    デスクトップ用のNVIDIA Quadro FX 1400は電源投入時から冷却ファンが全開稼働で、グラフィックスドライバーが読み込まれる(Windowsの起動中画面が切り替わるとか、FreeBSDでプロプライエタリドライバーを入れたXサーバーが起動するとか)までそのままだったと思います。ノートPCでGPU用冷却ファンが別に搭載されているのかどうかは知りませんが、別に搭載されているなら似たような話がありそうですね。
  • すずきさん(2020/05/08 15:23)
    結構、怖い制御に見えますね……。
    その世代の GeForce と Quadro って、ドライバがバグるとファンが回らなくなって、コアが焼けるやつでしたっけ?
  • すずきさん(2020/05/08 15:43)
    ちょっと調べたところ、コアが焼けると騒ぎになった GPU Killing Driver が、
    GeForce/ION Driver 196.75
    というバージョンで、その世代の GPU は GeForce GTX 280 辺りでした。

    2004, NV40/41/45(130nm): GeForce 6800 GT: Quadro FX 1400
    2006, G71(90nm): GeForce 7900 GTX
    2007, G84(80nm): GeForce 8600 GT
    2008, G92(65nm): GeForce 9800 GTX
    2008, GT200(65nm): GeForce GTX 280

    Quadro FX 1400 は GeForce でいうと GeForce 6800 くらいなので、結構前ですね。前からこういう制御なのか……。怖い作りだなあ。
open/close この記事にコメントする



2020年5月1日

Amazonでよくあること

Amazonでハンダごて一式を購入しました。

まず、ハンダが来ました。

次に、ハンダこて台、ハンダ吸い取り線が来ました。

肝心の、ハンダごてが来ません……(後日、ハンダごても届きました)。

Amazonは一括で注文できますが、発送元の違いで一括で発送されないことは良くあります。たまに不思議な順番で送られてきてちょっと面白いですよね。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2020/05/06 22:29)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年4月30日

Transport Fever 2初めの一歩 - その3

目次: ゲーム

昨日(2020年4月29日の日記参照)に引き続きTransport Fever 2の基本である、生産量について紹介します。画像をできるだけ使うようにしました。ゲームの雰囲気を感じてもらえたら嬉しいです。

生産量の概念は、私が最初に躓いたというか、一番訳の分からなかったところです。うまく説明できると良いんですけど。

生産施設と消費施設

Transport Fever 2のフリープレイで出現する生産者、消費者は5段階に分類できます。カテゴリの正式名がないため、私が適当に名付けています。間違っていたらごめんなさい。


生産施設と消費施設の相関図

図の見方を一応説明しておくと、食料加工プラントの場合、農場から「穀物」を2つ運ぶと、1つの「食料」が生産される、という風に見ます。生産がダントツで面倒くさいのは「商品」ですね。

経路がシンプルな「穀物」→「食料」にも罠があります。施設の生産キャパシティは基本的に最大400ですが、なぜか農場だけ200 しかありません。レベル最大の食料加工プラントで食料を400生産するには、穀物が800必要になりますから、農場4つから穀物を運ばなければなりません。

ちなみに…、「製油所」が2つ出てくるのは誤植ではありません。「製品」工場が「商品」を作るのも、「工場」と「プラント」が混ざっているのも誤植ではありません。Transport Fever 2の日本語はポンコツなので、突っ込み出すとキリがないです。

中間、最終生産のレベル

中間と最終生産を担う工場にはレベルがあり、生産上限がレベルで決まります。レベルは各施設をクリックすると出てくる概要に表示されています。


製材所はレベル1、森(一次生産)はレベルがない

ただまあ、工場のレベルを上げるぞ!!と思って上げることはあまりなくて「たくさん原料を運び込んで」「生産したものを全部消費」しているうちに、勝手に上がっていることが多いです。

生産と消費の条件

生産と消費がTransport Fever 2で一番わかりにくい概念だと思います。生産施設は常に「必要とされた分」しか作りません。私は最初、この概念が全く分かりませんでした。

先日作った経路で説明しましょう。森から製材所への運送経路を1つだけ作りました。生産(森)と消費(製材所)の関係はこうなります。


製材所と森の消費・生産の関係

基本的に消費側(製材所)の要求数 = 生産側(森)の生産数(2番目の「輸送」の数字)になります。正確に言えば、下記のロジックで決まります。

  • 板を作るのに、木材は2つ必要 -- (A)
  • 消費側(製材所レベル1)の生産上限は、板200個/年 -- (B)
  • 製材所は経路が繋がっている生産側(森)「全て」に「合計」(A) x (B) = 2 x 200 = 400個/年の木材を要求
  • 森は要求された数(400個/年)を満たす木材を生産

消費側は繋がっている生産側「全て」に要求するというのが、わかりにくいんですけど、結構大事です。

もし製材所レベル1に、森A、森Bを2つ繋いだとすると、森2つに対し「合計400の木材が要求」され、森の生産力が余ります。すると、森Aは100、森Bは300のように分散して生産し始めます。

このダイアログの情報は難しい部類ですが、日本語が完全に本当にポンコツです、全く説明になっていません。特に「輸送」を違う意味で2つ並べた人は何を考えているんでしょう?どう見てもおかしいでしょう??

路線の輸送力

これはわかりにくいというより、紛らわしい数字が表示されることが多いので、説明しておきます。トラック駅をクリックして、路線をクリックすると、路線の情報が表示されます。

ほとんど見ればわかる系の情報なのですが「割合」は注意が必要です。数字は路線の年間輸送力を意味しています。これもポンコツ翻訳のひとつですね……。

この路線は400の木材を森から製材所に運ぶために作ったことを思い出せば、400前後の輸送力にしておくと無駄がないことが分かると思います。


路線の情報

路線のコースを変えたり、トラックの種類や数を変更すると、すぐに年間輸送力の数字が変化します。例えばこの路線だと、トラックを1台から12台にすると、400くらいの値が表示されました。

しかしながら、この数字は実際の輸送力とかけ離れている場合があります。ある程度待つと、実情に近い値に補正されます。この補正がかなり劇的で、路線の変更直後は400だったのに、しばらく経つと480など大幅に増えたり、逆に激減したりすることが多々あり、気づかないうちに輸送力が不足したり、無駄になったりします。

ですから路線の輸送力を変更したときは、ちょっと時間をおいてから再チェックすることをお勧めします。

私の個人的な感覚では、トラックは最初の数字が低めに出る傾向(=後で増える)、鉄道と船舶は最初の数字が高めに出る(=後で減る)傾向があるように感じます。

編集者:すずき(2023/09/24 13:16)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2020年5月9日 >>> 2020年4月30日
link もっと後

管理用メニュー

link 記事を新規作成

<2020>
<<<05>>>
-----12
3456789
10111213141516
17181920212223
24252627282930
31------

最近のコメント5件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」

最近の記事20件

  • link 24年3月25日
    すずき (03/26 03:20)
    「[Might and Magic Book One TASのその後] 目次: Might and Magicファミコン版以前(...」
  • link 21年10月4日
    すずき (03/26 03:14)
    「[Might and Magicファミコン版 - まとめリンク] 目次: Might and Magicファミコン版TASに挑...」
  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
  • link 23年4月10日
    すずき (03/19 11:48)
    「[Linux - まとめリンク] 目次: Linuxカーネル、ドライバ関連。Linuxのstruct pageって何?Linu...」
  • link 24年3月18日
    すずき (03/19 11:47)
    「[画面のブランクを無効にする] 目次: LinuxROCK 3 model CのDebian bullseyeイメージは10分...」
  • link 24年3月3日
    すずき (03/19 11:07)
    「[解像度の設定を保存する] 目次: LinuxRaspberry Pi 3 Model B (以降RasPi 3B)のHDMI...」
  • link 24年3月14日
    すずき (03/16 23:03)
    「[JavaとM5Stamp C3とBluetooth LE - Bluetoothデバイスとの通信] 目次: ArduinoM...」
  • link 24年3月8日
    すずき (03/16 23:03)
    「[JavaとM5Stamp C3とBluetooth LE - BluetoothデバイスとServiceの列挙] 目次: A...」
  • link 23年6月2日
    すずき (03/16 21:11)
    「[Arduino - まとめリンク] 目次: Arduino一覧が欲しくなったので作りました。 M5Stackとesp32とA...」
  • link 23年5月15日
    すずき (03/16 00:57)
    「[車 - まとめリンク] 目次: 車三菱FTOの話。群馬県へのドライブ将来車を買い替えるとしたら?FTOのオイル交換とオイル漏...」
  • link 24年3月9日
    すずき (03/16 00:56)
    「[車のバッテリー完全に死亡で交換かと思いきや] 目次: 車またまた車のバッテリーが干上がって死にました。写真は撮っていませんが...」
  • link 24年3月10日
    すずき (03/15 03:34)
    「[誕生日] 早いもので41歳になりました。昨年の日記(2023年3月10日の日記参照)を見ると、コロナの流行を心配していました...」
  • link 24年3月6日
    すずき (03/12 01:18)
    「[Raspberry Pi 3 model Bの代わりにROCK 3 model C] 目次: Arduino最近、M5Sta...」
  • link 24年3月4日
    すずき (03/06 00:09)
    「[volatileをnon-volatileで参照してはいけない] 目次: GCC過去の日記(2021年3月13日の日記参照)...」
  • link 20年6月2日
    すずき (03/06 00:06)
    「[GCC - まとめリンク] 目次: GCCGCCについて。GCCを調べる - その1 - ビルドGCCを調べる - その2 ...」
  • link 15年5月9日
    すずき (03/05 03:00)
    「[自作ARMエミュレータ - 今さら気づいたブートローダのバグ] 目次: Linuxずっと気づいていなかった自作ARMエミュレ...」
  • link 23年6月1日
    すずき (03/05 02:59)
    「[自宅サーバー - まとめリンク] 目次: 自宅サーバーこの日記システム、Wikiの話。カウンターをPerlからPHPに移植日...」
  • link 15年5月3日
    すずき (03/05 02:59)
    「[GRUB2が起動しなくなってしまった] 目次: 自宅サーバーサーバにインストールしていたDebian 32bit版 のJes...」
  • link 15年5月2日
    すずき (03/05 02:58)
    「[systemdを使うのをあきらめた] 目次: 自宅サーバー独自ビルドのカーネルだと/sys/fs/cgroupが無いと言われ...」
  • link 15年4月30日
    すずき (03/05 02:56)
    「[Debian 8.0 Jessie] 目次: 自宅サーバーDebianのアップデートが来ていたので、試しに職場のPCをアップ...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/26 03:20