2002-06-17
ogg
奈々アンテナからなんとなく辿ったところにOggEnc (win32) Daily Binariesというのを発見。なんとなく encode してみました。
対象はすぐ手もとにあった奈々ちんの「 LOVE & HISTORY 」。やってみたら MS-DOS の 8 文字制限がかかってファイル名が変わってしまた。
mp3PRO な encode と ogg な encode を聞き比べ。微妙に mp3PRO のほうが良いかしら。
ただ、プレイヤが mp3PRO は mp3PRO の plugin を導入した Winamp 。ogg もそれ。プレイヤが mp3PRO に最適化されてるかもしれないので、ogg は ogg に最適化されたプレイヤを持ってくると良いのかもしれないっすね。あるのか矢口らないけど。
聞いてて気づいたんだけど、 LOVE & HISTORY ってリップノイズが入っててハァハァ。
というけで本家サイトを見てみたんだけど、やっぱ Winamp ( とか )がプレイヤみたいっすね。
_ 的を得る
いつもどーりに週刊少年ジャンプを買ったですよ。いつもどーりに HUNTER X HUNTER は落ちてましたよ。そんな流れで ONE PIECE を読みましたよ。そこに出てきた「 王下七武海 海賊 バーソロミュー・くま 」とかいう彼の言葉。
「 的を得ている 」
週刊少年ジャンプって小学生とか中学生とかヲレみたいな大人とかようするに老若男女が読むと思うんですよ。あとうちの母上も読んでます。最近はマンキンとかヒカ碁とかテニプリとかがアニメになってるから一時季のジャンプ( ドラゴンボールの連載が終了したころ )よりはるかに人気が出てると思うんですよ。げんに、どこぞの番組でこんなことを言ってました。「 最近囲碁をやる子供が増えたそうです。ヒカ碁の影響らしいです。」 とかなんとか。もうあれですよ。スラムダンクを読んでバスケを始めたとか、キャプテン翼を読んでサッカーを始めたとか、北斗の拳を読んで北斗神拳を始めたとか、イベントに逝けば道蓮( タオレン )とかアンナのコスプレしてる子が居るとか、そのくらいの影響があるんですよジャソプは。
なのにどーですかこの言葉の誤りは。どーしたんですかジャソプは。いつかのアタタ大神拳のころの勢いはどーしたんですか。こんなことだから「あ。この漫画ってプリティ・フェイスっていうんだ。知らなかった」とかヲレは思うわけですよ。読んでないけど。
ひょっとして的を得るというのは、むしろ、的ごとげっちゅしちゃって、それでゆっくりと的を射ようということが言いたかったのかしら。最近の日本語って難しいんですね。あ。たけしも落ちてら。
2003-06-17
_ 無駄な作業
客サキと電話したときの会話。
客サキ「 では、いま仰った内容をメールに書いて投げていただけますか。」
ぉぃぉぃ。いまさっき言ったことと同じ内容を文書にするのかよ。ヲレが言った内容をメモしてたんじゃないのかよ。ヲレはなんのために電話連絡したんだよ。
デスマーチに書いてあった「 無駄な作業 」がリアルで発生した。
_ しえすた
うーん。まいった。
_ さて
木曜休むためにがんばろう。
_ どーでしょー
今日も k** っちのお世話になってしまった。せっかくなのでりしゅに頼んだ。
23:37 >rin<りしゅれんらく tue,22:55 どーでしょー 23:37 <Rishu> みわしゃん：おぼえたでし(Tue,22:55 / どーでしょー)
_ ターン A ガンダム Episodes
読み終えた。アニメのほうでなくて小説のほうのターン A がもとになってる。
地球降下前のロランたちの話とか、本編のサイドストーリーとか、あとは本編のその後の話( なんて言ったっけ。プロローグ？ )。楽しめた。
ターン A はアニメのほうより小説のほうが話が悲劇的なんだよな。そこがちょっとイヤ。
2005-06-17
_ 仕事
0750 へいしゃー。
_ Mac OS X の .emacs まわり
ぅぅ。
以前から cannot open file: debug とかよく分からないエラーが起きてた Mac OS X の Emacs 。
.emacs でこんな条件でホストを判定してて...
(defconst running-UNIX (or (equal system-type 'gnu/linux) ;; linux
(equal system-type 'berkeley-unix) ;; SunOS
(equal system-type 'usg-unix-v))) ;; Solaris
(defconst running-MacOS ( or ( equal system-type 'darwin)))
(defconst running-Emacs (and running-UNIX
(or (= emacs-major-version 20)
(= emacs-major-version 21)
(= emacs-major-version 22)
)))
(defconst running-XEmacs (featurep 'xemacs))
(defconst running-Mule2.3 (and running-UNIX (= emacs-major-version 19)))
(defconst running-Meadow (featurep 'meadow))
.emacs 内で load してる .irchat.el には以下のような行を書いていた。
(setq load-path
(cond
(running-Meadow
(append '("c:/usr/local/Meadow/site-lisp/irchat") load-path))
(running-Emacs
(append '("/usr/local/share/emacs/site-lisp/irchat") load-path))))
冒頭の .emacs の条件により Mac OS X だと running-MacOS を定義するけど running-Meadow と running-Emacs はどちらも定義されない。よって irchat が load-path に追加されない。
もはや Meadow は使ってないので以下のようにさっくり削除。
ok 。
rin@sakura[~]% diff -u .irchat.el.l .irchat.el
--- .irchat.el.l Fri Jun 17 18:52:33 2005
+++ .irchat.el Fri Jun 17 18:52:40 2005
@@ -8,11 +8,7 @@
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(setq load-path
- (cond
- (running-Meadow
- (append '("c:/usr/local/Meadow/site-lisp/irchat") load-path))
- (running-Emacs
- (append '("/usr/local/share/emacs/site-lisp/irchat") load-path))))
+ (append '("/usr/local/share/emacs/site-lisp/irchat") load-path))
(autoload 'irchat "irchat" nil t)
_ skype
先日注文した VoSKY( 2005-06-15 ) が届いた。
どうも商品名は VoSKY というらしい。DN-VS6000 などとはどこにも書いてないのだけど、日本での販売名が DN-VS6000 とか？ そんなのあるのかしらん。
さっそく設置作業開始。
手の平サイズ。
設置終わり。
外部からの電話線と既存の電話器との間に VoSKY を置いた。
skype での動作は未確認。
だれか skype 使ってるひといませんかー。
既存の電話を 117 なんぞにかけてみた。正常動作することを確認した。
VoSKY は USB バスパワーで動作する。
計算機から USB 接続を外しても( VoSKY の電源が切れても )電話は使えた。
電話ってそーいうもの？
_ Mac OS X で irchat
ついでに Mac OS X から日記を書いてみる。
make しなくていいんすね。
rin@kahori[~/usr/local]% wget http://www.ircnet.jp/dist/irchat/irchat-jp26d.tgz rin@kahori[~/usr/local]% mkdir irchat rin@kahori[~/usr/local]% mv irchat-jp26d.tgz irchat rin@kahori[~/usr/local]% cd irchat/ rin@kahori[~/usr/local/irchat]% tar xzf irchat-jp26d.tgz rin@kahori[~/usr/local]% sudo mv irchat /usr/local/share/emacs/site-lisp/
2007-06-17 :-)
_ [精霊の守り人]精霊の守り人
アニメのほう。
唐突に「サグ」と「ナユグ」という言葉が出てきたが、これは 2 つの世界があるということ？原作を読んでるとたぶんこのあたりの説明があるのだろうけど読んでないというかアニメのほうでも説明があったっけ。
wikipedia 検索。
この作品の世界には、目に見える人間の世界（サグ）と目に見えない精霊の世界（ナユグ）がある。この二つの世界は同じ時、同じ場所に重なって存在する。呪術師は呪術によってナユグを見たりそこの生き物と話したりできる。また、ごく一部の人間（主に子供）は、呪術を用いなくてもナユグが見えることがある。まれにサグとナユグの交わる場所があり、カンバルの山の底、青霧山脈の谷間などがそうである。
ほお。
_ [ソフトウェア工学]ソフトウェア工学
ソフトウェア工学が大規模ソフトウェアにしか適用できないのは大規模ソフトウェアを経験したひとがソフトウェア工学という言葉を作ったからである。ソフトウェアの歴史を紐解いてないので嘘 50 % くらい。
「人月の神話」は IBM S/360 を作ったフレデリック・ブルックスによるものである( ref. フレデリック・ブルックス - Wikipedia )。「ソフトウェアエンジニアリング論文集80's」[ 2006-11-29 ]にある論文はスペースシャトルに乗せるソフトウェアなどをもとにして書かれている。
大規模なソフトウェアを作った経験をもとにしてソフトウェア工学というものを作った。ソフトウェアの開発経験をもとにしてさらに工学までに発展させるような頭が良いひとは、ソフトウェア工学というものが出来た当時は大規模ソフトウェアの開発チームにしか居なかったんである。
などということを「精霊の守り人」を見ながら妄想してみた。
4795296758
4798110612
_ [ライトニングトークス]オブジェクト倶楽部 2007 夏ライトニングトークスのプレゼンの練習をしたよ
4 分 30 秒はけっこう短いですね (´ω｀；)
そもそもライトニングトークスというのはどんな雰囲気だったかなと平鍋健児さんのライトニングトークスの動画を見てみました。すいません、いま初めてまともに見ました。
この内容で 5 分！！！
5 分で全部プレゼンして( プレゼン資料をリアルタイムに手で書いている！ )、会場を笑わせて、時間が余ったからと言ってショートコントまで炸裂させてます。このひとはすごいな....。
スライドはそのままにして、しゃべる内容をもっと絞ろうかしら。「詳細は割愛します」という感じでどうか。
_ [芝居][白南風の空 夢の伽詞]白南風の空 夢の伽詞( しらはえのそら ゆめのときうた ) 3 日目
千秋楽でした。
舞台の演出や演技についてはアンケートに書いたし、宅原さんについての感想は直接本人に言ったので割愛。 おおざっぱなお話はこう。
- 現在不運だ( 主人公「不運だが不幸とは思ってない 」 )
- 前世に不幸があった
- 過去に時間旅行して前世のひとと会った
- 前世の不幸を回避しようとした
- 回避できなかった
- その教訓を活かして現在も続いている前世からの因縁を断ち切る
前世の不幸を回避してヤッホーイ！という話なのかなと思ったけど、前世は救えませんでした。ハッピーエンド好きな私としては前世を救って欲しかったなあ (´ω｀；)
2008-06-17 :-)
_ 朝ったー
0530 起床。
_ [エースコンバット3][椎名豪][中川浩二][中西哲一][辰田朋子][大久保博][柿埜嘉奈子]通勤ったー
エースコンバット3 エレクトロスフィア
ゲーム未プレイ。作曲は以下の方々。
- 椎名豪
- 中川浩二
- 中西哲一
- 辰田朋子
- 大久保博
- 柿埜嘉奈子
戦闘機でばびゅーんと飛ぶゲームらしいですが「アフターバーナー」等のような爽快な曲、疾走感がある曲はありません。けっこう地味です。「車を運転してるときに聴くとヤバイ」ということにはならないので安心して聴けます。全体的な分類はテクノかなあ。テクノも多岐にわたるけど。
B00005F3KK
_ 仕事
0830 出勤。
_ [JNUG][BOF][NetBSD]JNUG BOF の雰囲気が分からないので躊躇している
mixi 方面で BOF の案内等を見かけたのだけど私のような末端の利用者が参加していいものかどうかああでも Japan NetBSD User's Group だからいいのか。つべこべ言わずに行ってみればいいじゃない。
_ 2008/07/05 NetBSD BOF 2008 の「プレゼンテーション資料」なんてないわー
Not Found The requested URL /ja/JP/JNUG/event/20080705BOF/jnug-2008-bof-future.ppt was not found on this server.
_ [C#][.NET][デリゲート][delegate][リダイレクト][標準出力]外部プロセスの標準出力をリアルタイム風味にテキストボックスへ表示する
C#
デリゲートをこねくりまわす。
using System;
using System.Text;
using System.Windows.Forms;
using System.IO;
using System.Diagnostics;
using System.Threading;
namespace ContorolInvoke2
{
public delegate void OutputDelegate(string s);
public partial class Form1 : Form
{
private AsyncIOTester aio;
public Form1()
{
InitializeComponent();
aio = new AsyncIOTester(textBox1, new OutputDelegate(Output));
}
private void button1_Click(object sender, EventArgs e)
{
aio.Run();
}
private void Output(string s)
{
textBox1.AppendText(s);
}
}
public class AsyncIOTester
{
private Stream inputStream;
private byte[] buffer = new byte[128];
private AsyncCallback callBackRead;
private Control outputContorol;
private OutputDelegate outputDelegate;
public AsyncIOTester(Control oContorol, OutputDelegate oDelegate)
{
callBackRead = new AsyncCallback(OnRead);
outputContorol = oContorol;
outputDelegate = oDelegate;
}
public void Run()
{
Thread t = new Thread(new ThreadStart(ExecProc));
t.Start();
}
private void ExecProc()
{
Process p = new Process();
p.StartInfo.FileName = @"C:\Windows\System32\ping.exe";
p.StartInfo.Arguments = "-n 10 localhost";
p.StartInfo.WorkingDirectory = Directory.GetCurrentDirectory();
p.StartInfo.RedirectStandardInput = false;
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.UseShellExecute = false;
p.StartInfo.CreateNoWindow = true;
p.Start();
inputStream = p.StandardOutput.BaseStream;
inputStream.BeginRead(buffer, 0, buffer.Length, callBackRead, null);
p.WaitForExit();
p.Close();
}
void OnRead(IAsyncResult ar)
{
int readByte = inputStream.EndRead(ar);
if (readByte > 0)
{
string s = Encoding.Default.GetString(buffer, 0, readByte);
outputContorol.Invoke(outputDelegate, s);
inputStream.BeginRead(buffer, 0, buffer.Length, callBackRead, null);
}
}
}
}
ref.
- GotDotNet Japan 掲示板 - プロセスの Standard Out のリダイレクト
- プログラミング C# 21.3 非同期IO
4873112648
2009-06-17 :-)
_ 朝ッ
0530 起床
_ [Twitter]アイドルマスターメンバーが Twitter に居るのは周知だと思う
こっちは bot だけど
- 我那覇響 http://twitter.com/ganaha_hibiki
- 菊地真 http://twitter.com/kikuchi_makoto
- 高槻やよい http://twitter.com/takatsuki_yayoi
- 三浦あずさ http://twitter.com/miura_azusa
- 四条貴音 http://twitter.com/shijou_takane
- 秋月律子 http://twitter.com/akizuki_ritsuko
- 水瀬伊織 http://twitter.com/minase_iori
- 星井美希 http://twitter.com/hoshii_miki
- 双海亜美・真美 http://twitter.com/futami_ami_mami
- 天海春香 http://twitter.com/amami_haruka
- 如月千早 http://twitter.com/kisa_chihaya
- 萩原雪歩 http://twitter.com/hagiwara_yukiho
_ [Ruby]ファイル名の SJIS 丸数字を (1) などに変換する
もうちょっとマシなやり方は無いんだろか。
#!/usr/bin/ruby -Ks
require 'fileutils'
def main( argv )
Dir.glob( '*' ){ |f|
src = f.dup
f.gsub!( /\x87\x40/, '(1)' )
f.gsub!( /\x87\x41/, '(2)' )
f.gsub!( /\x87\x42/, '(3)' )
f.gsub!( /\x87\x43/, '(4)' )
f.gsub!( /\x87\x44/, '(5)' )
f.gsub!( /\x87\x45/, '(6)' )
f.gsub!( /\x87\x46/, '(7)' )
f.gsub!( /\x87\x47/, '(8)' )
f.gsub!( /\x87\x48/, '(9)' )
f.gsub!( /\x87\x49/, '(10)' )
f.gsub!( /\x87\x4A/, '(11)' )
f.gsub!( /\x87\x4B/, '(12)' )
f.gsub!( /\x87\x4C/, '(13)' )
f.gsub!( /\x87\x4D/, '(14)' )
f.gsub!( /\x87\x4E/, '(15)' )
f.gsub!( /\x87\x4F/, '(16)' )
f.gsub!( /\x87\x50/, '(17)' )
f.gsub!( /\x87\x51/, '(18)' )
f.gsub!( /\x87\x52/, '(19)' )
f.gsub!( /\x87\x53/, '(20)' )
puts f
FileUtils.mv( src, f ) if src != f
}
end
main( ARGV )
ref.
2010-06-17 :-)
2011-06-17 :-(
_ 夜
1800 突発鶏の会
_ ,
椿姫[ 20051209#p13 ]は文学になっちゃってるのであれば {キャバ嬢,娼婦,飲み屋の店員} に惚れてしまうのはなんら可笑しいことではない
_ [NetBSD][マルチブート][翻訳]making netbsd multiboot-compatible - o'reilly media NetBSD のマルチブート環境を作る
by julio m. merino vidal
03/01/2007
the i386 architecture is full of cruft required to maintain compatibility with old machines that go back as far as the 8086 series. technically speaking, these features aren't necessary anymore because any recent computer based on this architecture uses a full 32-bit operating system that could work perfectly fine without the legacy code. unfortunately, the compatibility hacks remain in place and hurt the development of new software.
i386 アーキテクチャは、8086 シリーズに遡るまでの古いマシンを維持するために cruft required している。技術的な話題としては、このアーキテクチャを基にした最近のあらゆるコンピュータは完全な 32 ビットオペレーティングシステムがレガシーコードが無くても完璧に動作するので、これらの機能はもはや必要とされていない。残念ながらここ( i386 アーキテクチャ )ではこの互換性ハックは生き残り、新しいソフトウェアの開発を悩ませる。
one of the details that has not changed for years is the i386 boot process. it was designed back in the days when computers had only floppy disk drives and machines had limited firmware. since then, the procedure has not suffered any change and it makes some tasks very complex; one of these is the configuration of multiple operating systems (oses) on a single machine.
ここ数年変化がないことのうち 1 つは、i368 ブートプロセスだ。これはコンピュータがフロッピーディスクドライブしか持っておらず、マシンが限られたファームウェアを使っていたころに設計されたものだ。その後、この手続きは苦労して変更されることなく、いくつかの処理はかなり複雑になった。そのうち 1 つは、1 台のマシンに複数のオペレーティングシステムを設定することだ。
the new firmware for intel-based machines, the extensible firmware interface (efi), resolves this issue by providing a more versatile boot process. other architectures have already provided improved firmware with nicer boot mechanisms, including, for example, the ability to load and execute an elf image straight from the machine initialization code. such is the case with openfirmware as shipped in powerpc macintoshes.
インテルベースのマシンの新しいファームウェア the extensible firmware interface (efi) は、多様なブートプロセスによってこの課題を解決した。他のアーキテクチャは、改善されたよりよいブート機構を持ったファームウェアが提供されている。たとえば、ロードする能力があったり、マシンの初期化コードから直接 elf イメージを実行できたりする。powerpc マッキントッシュの openfirmware のようなものだ。
even though alternative firmware implementations exist, the i386 architecture as we known it today will still be with us for a long time. therefore, it would be nice to resolve some of its limitations through software. this is what the multiboot specification attempts to do in the boot area: provide the ability to boot any operating system from a single boot loader, hence simulating an improved firmware.
他のファームウェアでは既に実装されているのに、i386 アーキテクチャでは今日に至るまでいまだに見たことがない。しかし、ソフトウェアの制限を通り抜けるようにした良い解決策がいくつかある。ブート領域でマルチブートするのである。これは、改良ファームウェアでシミュレーションすることにより、単独のブートローダーからあらゆるオペレーティングシステムをブートできるようになる。
i recently modified the netbsd's kernel to become multiboot-compliant. there are many code references in the text, but the main idea behind the essay is to introduce multiboot and show you that a real-world operating system can easily be converted to support this specification. please note that all code references point to the netbsd-4 stable branch to ensure that the code remains consistent with the explanations given here.
NetBSD のカーネルをマルチブートできるようにしてみた。大量のコードリファレンスがこのテキストに存在する。しかし主なアイデアはマルチブートを紹介する文章( 後述 )にあり、実際のオペレーティングシステムを簡単にマルチブート対応に変換することができるようになる。なお、全てのコードリファレンスは netbsd-4 stable ブランチを指しており、ここで説明したことがコードとして首尾一貫して残ることを保証する。
the i386 boot process (i386 ブートプロセス)
the traditional i386 architecture uses a very simple firmware known as the basic input/output system, or bios. the bios is in charge of initializing the hardware after powering up the machine and provides a low-level interface to access it from boot loaders and oses. unfortunately, it has inherited a lot of deficiencies from the past: these services are available from real mode only and they do not provide high-level abstractions for the underlying hardware.
伝統的な i386 アーキテクチャは、the basic input/output system または BIOS と呼ばれるじつに簡単なファームウェアを利用している。BIOS は、マシンの電源を入れたあとにハードウェアを初期化し、ブートローダーや OS がアクセスするための低レベルインターフェースを提供する。やっかいなことに、以下に示すような多くことを継承している。これらのサービスはリアルモードのみで有効であり、ハードウェアを高レベルに抽象化してはいない。
to put things in perspective, the bios is unable to access any on-disk filesystem (not even fat) and therefore cannot directly load any executable such as the os kernel. instead, all the bios does is load the first sector of the selected boot disk into a specific memory location (07c0h:0000h) and transfer the execution control to it. to make things worse, each os kernel has traditionally provided its own boot code tailored to its needs. for example, the old ms-dos os loaded from a fat disk and executed in real mode; on the other hand, newer systems can boot from a large variety of filesystems (fat, ntfs, ext2, and more) and need to run in protected mode from the very beginning because their kernels are too big to fit into the first megabyte of memory (all the memory addressable from real mode).
ここでの見方として、BIOS はディスク上のあらゆるファイルシステムにアクセスできないし( FAT は言うまでもない )、OS カーネルのようにあらゆる実行可能なものは直接接ロードすることができない。その代わり、全ての BIOS は、選択したブートディスクの最初のセクターをメモリ番地 07C0h:0000h にロードし、実行制御 { ってなに }をそこへ転送する。それが失敗した場合、各 OS カーネルは伝統的に自分自身のブートコードを必要なように仕立て上げることを提供する。例えば、古い MS-DOS OS は FAT ディスクかららロードされ、リアルモードで実行される。他に、より新しいシステムでは、様々な大きいファイルシステム( FAT, NTFS, EXT2 など )からブートする。それらのカーネルはメモリの最初のメガバイト( 全てのメモリアドレスはリアルモードに基づく )に格納するにはとても大きいので、しょっぱなからプロテクトモードで動作する必要があるだ。
the fact that each os needs its own boot loader causes a lot of problems when setting up several different systems on a single machine and poses a lot of questions that the user will most likely be unable to answer. what do you install in the mbr? where do you put each boot loader? why do you need to configure each of them independently? why do you need more than one?
OS 自身のブートローダーを使うと 1 つのマシン上でいくつかの異なるシステムを設定するときにたくさんの問題を引き起こすことになり、たくさんの問い合せが出るのだが、ユーザーはたいてい答えられない。MBR は何をインストールしてますか？ ブートローダーはどこに設置していますか？ それらを独立して設定する必要があるのは何故ですか？ 1 つ以上必要なのは何故ですか？
it could be very convenient if there was a generic interface that decoupled the load and bootstrapping of an os kernel from its boot loader. this way, an os developer could focus exclusively on the task at hand and forget about writing a boot loader. similarly, boot loader developers could join forces to write a more complete utility or, alternatively, write their own with minimal code, while being able to boot any os that supported such interfaces (ideally all oses). the good thing is that the grub developers already had this idea in the past and developed such an interface: multiboot.
もしブートローダーによる OS カーネルのブートストラップとロードとを分離する共通インターフェースあるならば、これはとても簡単に出来る。この方法ならば、OS 開発者は手持ちの作業のみに集中できるし、ブートローダーを意識せずに済む。同様に、ブートローダー開発者はもっと完全なユーティリティを書くことに注力するか、インターフェースに対応したあらゆる OS ( 理想的には全ての OS ) がブートできるようになるまでの間はそれら自身の最小限のコードとともに書いたりできる。良いものとして、GRUB 開発者たちは後述するアイデアを既に使っており、マルチブートのインターフェースとして開発されている。
the multiboot specification ( マルチブート詳細 )
the multiboot specification (ms) defines a protocol between boot loaders and os kernels that allows any multiboot-compliant boot loader to load and execute any multiboot-compliant os kernel. this permits the end user to install a single boot loader in his machine and use it to boot any system directly, without having to chain-load different boot utilities.
the multiboot specification (MS) は ブートローダーと OS カーネルとのプロトコルを定義している。これにより、あらゆるマルチブート対応のブートローダーでロードし、あらゆるマルチブート対応の OS カーネルを実行することを許す。この権限は、異なるブートユーティリティを連鎖することなく、エンドユーザーが自分のマシンにブートローダー単体をインストールし、あらゆるシステムをじかにブートできるようにする。
in order to accomplish this abstraction, the ms defines two items:
これを果たすため、MS は 2 つの項目を定義している:
- the multiboot header (mh) (マルチブートヘッダー (HM))
this is a 4-byte aligned data structure located within the first 8 kb of the os kernel image. it provides a magic number used to identify the file as being multiboot-compliant, a set of flags indicating specific kernel needs, and additional fields describing the structure of the binary. the latter are only used if the kernel is in the a.out format (with some exceptions); using elf makes things much simpler and also more versatile.
これは、OS カーネルイメージの最初の 8 KB に 4 バイトアライメントのデータ構造体を配置する。これは、マルチブート対応するためのファイルを見つけるマジックナンバーを提供する。
- the multiboot information structure (mis) (マルチブート情報構造体 (MIS))
this is a data structure constructed by the boot loader and passed to the os kernel as part of the boot process. it includes information such as which disk is the boot disk, a memory map, the kernel parameters, where additional kernel modules are in memory (if loaded at boot time), etc.
これはブートローダーによって生成される構造体で、OS カーネルのブートプロセスの部分として通過する。これには、どれがブートディスクなのか、メモリーマップ、カーネルパラメーター、追加カーネルモジュールのメモリ内での場所( ブート時にロードするならば )等の情報を含む。
there is some interaction between the two structures in the sense that the mh may request the boot loader to set some fields in the mis for a successful boot. if the boot loader cannot fulfill the kernel's needs, the load will fail gracefully.
ブート成功時にブートローダーが MIS 内のいくつかのフィールドを設定するように MH が 要求する、というように、2 つの構造体の間には多少の作用がある。もしブートローダーがカーネルの要求を満たせないならば、ロードは綺麗に失敗するだろう。
if you're making good use of these two structures, it's trivial to write a simple binary file that acts as an os kernel - that is, a binary that is able to run standalone on the machine without any other os. see the boot.s, kernel.c, and related files that form the example kernel distributed alongside grub in the docs directory.
もしあなたがこれら 2 つの構造体を良く使えるならば、それは、OS カーネルのような単純なバイナリファイル( それはマシン上で何の OS も無しに独立して走ることが出来るバイナリだ )を書くことは取るに足らないだ。boot.s, kernel.c や、たとえば docs ディレクトリ内の GRUB と一緒に配布されたカーネルなど、関連するファイルを読むとよい。
it is also interesting to note that a multiboot-compliant boot loader will enter protected mode and set up a preliminary gdt for a flat memory model, so the kernel needn't do this by itself. of course, the kernel will have to reload the gdt with values of its own later in the initialization process, but the one set up by the boot loader is enough to get started. in some sense, it's possible to write the os kernel as if the real mode did not exist at all, as happens on other (saner) platforms.
マルチブート対応のブートローダーがプロテクトモードに入り、フラットメモリモデルのための予備 GDT を設定することについて記すことはとても興味深いことだ。だからカーネルは、カーネル自身がおこなう必要がない。もちろん、カーネルは、初期化後にカーネル自身の値と一緒に GDT をリロードできなくてはならないだろう。しかしブートローダーによるセットアップについては、すでに始めることができる。ある意味、それは、まるでリアルモードが全てに存在しないような OS カーネルを書くことを可能にすることであり、他の( たしかな )プラットフォームが発生するようなものだ。
----------------------------------------------------------------------------------------------
_ [NetBSD][マルチブート][翻訳]making netbsd multiboot-compatible - o'reilly media NetBSD のマルチブート環境を作る(2)
the netbsd/i386 boot process (NetBSD/i386 のブートプロセス )
netbsd/i386 uses a two-stage boot loader. the first stage gets installed into a known physical location-typically, the first sector of the hard disk or partition in which the system is installed and spans over some other reserved free space in the filesystem. this little program, which is generally limited in size, has the required knowledge to read the second stage boot loader and transfer the execution control to it; this one installs into the root filesystem as /boot, so its physical location may vary across reboots: there is nothing in the filesystem that binds a file to specific disk blocks.
[[NetBSD/i386|http://www.netbsd.org/ports/i386/] は 2 ステージブートローダーを使っている。第 1 ステージは既知のインストール済みの物理配置を取得する。システム内のハードディスクかパーティションの最初のセクターはインストール済みであり、ファイルシステム内のいくつかの他の予約済み自由領域にわたっている。この小さいプログラムは、一般的にはサイズ制限されたものである。このプログラムは、第 2 ステージブートローダーを読み込み、それへ実行制御を転送するために必要な情報を持っている。これは root ファイルシステムの /boot へインストールする。そしてそれは、物理配置が再起動をまたいで変更されるだろう。ファイルシステムにディスクブロックの詳細に結び付けられたファイルは無いのである。
once the second stage boot loader receives control, it enters the flat protected mode (no paging, segments spanning the whole memory space), loads the kernel from disk, and runs it; it also accepts user input to choose which kernel to boot and which options to pass to it, if any. this loader also passes boot-time information to the kernel by means of the bootinfo framework. simply put, this is a table that contains information, all gathered by the boot loader, about the machine and execution environment, including:
第 2 ステージブートローダーが制御を受け取ったとき、フラットプロテクトモードに入っている( ページングは無く、セグメントはメモリ領域全体をまたいでいる )。ディスクからカーネルをロードし、走らせる。ブートさせるカーネルや、通過するためのオプション( あれば )を選択するためのユーザー入力も受け付ける。このローダーは、bootinfo フレームワークによるカーネルへのブート時の情報も通過させる。簡単に言うと、これは、以下に示すマシンや実行環境についてのブートローダーからの全ての情報を収集したものからなるテーブルである。
- amount of available memory
- the boot device
- the kernel's filename
- where the console is attached (e.g., serial line, local video card)
- 有効メモリの統計
- ブートデバイス
- カーネルのファイル名
- コンソールとして割り当てられたもの ( 例: シリアル線、ローカルビデオカード )
the src/sys/arch/x86/include/bootinfo.h file holds the complete list of possible values for bootinfo items. bootinfo is similar to the mis, although the information it includes is slightly different and, in some specific cases, more complete. in fact, this was one of the main headaches when adapting the netbsd kernel to support multiboot.
src/sys/arch/x86/include/bootinfo.h ファイルは、bootinfo アイテムとして利用可能な完璧なリストを持っている。bootinfo は MIS に似ている。この情報に含まれるものは少し違うが、いくつかの場合においてはまったく完璧だ。実際、これは、NetBSD カーネルがマルチブート対応を追加するときの主な頭痛の種のうちの 1 つであった。
later on, the kernel gets the execution control and proceeds by:
その後、カーネルは実行制御を取得し、以下を処理する:
- storing the boot information (bootinfo or mis) in a safe place. see the native_loader function in src/sys/arch/i386/i386/machdep.c.
- detecting the cpu model in use (e.g., 386, 486, pentium).
- setting up a preliminary page directory and the corresponding page tables to remap the kernel's virtual addresses above 0xc01000000.
- enabling memory paging and jumping to high memory.
- continuing to boot and processing the boot information during its initialization.
- 安全な場所にブート情報( bootinfo または MIS )を保存する。src/sys/arch/i386/i386/machdep.c の native_loader 関数を参照
- 使用している CPU モデルを発見する( 例: 386, 486, pentium )
- 予備のページディレクトリをセットアップし、整合されたページテーブルをカーネルの仮想アドレス 0xc01000000 以降に再配置する.
- メモリーページングを有効にし、高メモリへジャンプする
- 引き続きブートし、初期化中のブート情報を処理する
one tricky thing is that the netbsd kernel runs, by design, at very high memory addresses (0xc0100000 and higher) for efficiency reasons: doing this allows the mapping of the kernel inside the processes' virtual address spaces without interferences. however, as mentioned earlier, the boot loader does not enable paging so it is impossible for it to put the kernel at such high addresses (unless the machine has lots of physical memory, but that is not the idea).
効率化のため{ ???? }、かなり高いメモリアドレス ( 0xc0100000 とかそれ以上 )において、設計により NetBSD カーネルが走るときに 1 つトリッキーなことがある。干渉がないカーネル内のプロセスの仮想アドレス領域を配置することを許可している。しかし、先に触れたように、ブートローダーはページングを有効にしない だから 高アドレスのようなところ( マシンがたくさんの物理メモリを積んでいない場合は例外だ )にカーネルを配置するのが不可能である。
the elf file format resolves this issue: each section in the image (text, data, bss, and so on) specifies which address is its starting virtual address, but also specifies its physical load address. the netbsd kernel's linker script takes advantage of this to generate an elf image mapped over 0xc0100000 but placed at the 0x00100000 physical address. note that the address is not 0x00000000 to ensure that the kernel does not overwrite any bios code and/or data stored below the first megabyte (the only address space accessible from real mode) when loaded.
ELF ファイルフォーマットは以下の問題を解決する。イメージ内の各セクション(text、data、bss とかいろいろ)は、アドレスが仮想アドレスから開始するように指定する。物理ロードアドレスも指定する。NetBSD カーネルのリンカースクリプトは、0x00100000 の物理アドレスに配置されている ELF イメージを 0xc0100000 以降に配置することについて優位性がある。なお、アドレスは 0x00000000 ではなく、カーネルがロード時に、あらゆる BIOS コードや最初の 1 メガバイトより下にあるデータストアを上書きしない( このアドレス領域だけはリアルモードからアクセスされる ) ことを保証する。
before paging is enabled, the kernel code is critical because it must be careful to not use the raw addresses generated by the linker (as they point to unavailable memory positions). the reloc macro resolves this by converting a given virtual address to its corresponding physical location. fortunately, once paging works, no more problems appear and this is basically a non-issue.
ページングが有効になる前はカーネルコードはクリティカルである。なぜならばそれはリンカが生成した生アドレス( 無効メモリ位置へのポインタのように )を使わないように注意しなければならないからだ。reloc マクロは、与えられた仮想アドレスから、一致する物理位置へ変換することによりこれを解決する。幸運にも、一度ページングが作用すれば、これ以上問題は現れないし、これは基本的には問題ではないのである。
making netbsd multiboot-compliant ( NetBSD をマルチブート対応にする )
due to some limitations in the native netbsd boot loader, i needed to boot netbsd using grub in a spare machine i used for kernel testing. when doing so, i found that native netbsd boot support in grub is very rudimentary, and even broken in several situations. for example, it does not set up the ksyms correctly, so ddb(4) backtraces are very difficult to understand. in addition, the upstream code does not support passing boot-time options to the kernel, but fortunately pkgsrc includes some local patches to resolve this issue.
NetBSD のネイティブなブートローダーにはいくつか制限がある。NetBSD を GRUB を使ってブートさせるために予備のマシンを用意し、カーネルをテストした。それをおこなったところ、GRUB 対応の NetBSD のネイティブなブート( ローダー? ) は、とても原始的であることが分かり、いくつかの場面でよく壊れた。たとえば、ブートローダーは ksysms を正しくセットアップしないので ddb(4) のバックトレースを理解するのにものすごく苦労する。さらに、アップストリームコード{ 最新のコード?? } はカーネルへのブート時オプションに対応していない。しかし幸運にもこの問題を解決するためのいくつかのローカルパッチが pkgsrc に含まれている。
there were two different solutions to my problems: fix grub to include full support for native netbsd boots or make the netbsd kernel multiboot-compliant. i chose the latter because i personally like the idea behind multiboot: it is more in the line of defining an abstract interface between two different system components. more importantly, though, is that changing the netbsd kernel alone has the advantage that the code in grub will not rot: the grub developers are the main developers of the multiboot specification and, because it has no netbsd-specific bits in it, they don't need to have a netbsd system available to ensure it is supported.
私の問題には 2 つの異なった解決策がある。GRUB をネイティブな NetBSD ブートローダーに完全に対応させるか、NetBSD カーネルをマルチブート対応させるかだ。私は後者を選んだ。なぜなら、前述のマルチブートのアイデアが個人的には好きだからだ。それは、2 つの異なるシステムコンポーネント間の抽象インターフェースにもっとコードを定義するものだ。もっと重要なことは、NetBSD カーネル単体を変更することは GRUB にあるコード対する優位性を無くすことはないだろうということだ。GRUB 開発者はマルチブート仕様の主な開発者であり、それゆえ、NetBSD の仕様には踏み込んでいない。彼らは NetBSD 対応を保証するために NetBSD システムを有効にする必要がないのである。{ NetBSD に特別に対応する必要がない、という感じか???? }
the first step was to define some high-level data structures to represent and manage the mh and the mis from within the kernel - something easy thanks to the detailed documentation about them. the results are in src/sys/arch/i386/include/multiboot.h.
最初のステップは、カーネル内の MH と MIS を表現したり管理するためのいくつかの高レベルデータ構造を定義することだった。それらについての詳細なドキュメントがあるのはありがたい。成果物は src/sys/arch/i386/include/multiboot.h にある。
then, the obvious move was to add an mh to the kernel so that grub could recognize it. to ensure that it was within the first 8kb of the image, i added it in the text section of src/sys/arch/i386/i386/locore.s alongside the kernel's entry point.
その後、明確な移動はカーネルに MH を追加したことだ。なので、GRUB は見分けが出来るようになった。それを保証するために、イメージの最初の 8 KB に収めた。カーネルのエントリーポイントの近くにある src/sys/arch/i386/i386/locore.s の text セクションに追加した。
this was not easy at all: the kernel's linker script had a bug that made the sections' physical addresses point to the virtual addresses. this forced me to use the address fields in the mh to indicate where to load the file, but grub was not honoring them for elf files. i had to come up with a fix for grub until a fellow developer, pavel cahyna, fixed the problem from its root: he rewrote the linker script to generate the appropriate physical addresses. nowadays, those extra fields in the mh are not used, and a mainstream grub image (distributed in virtually any gnu/linux distribution) can boot a netbsd kernel.
これは、以下のすべてにおいて簡単ではなかった。カーネルのリンカスクリプトには、セクションの物理アドレスが仮想アドレスを指すというバグがあった。これは私に、ファイルをロードするところでの MH のアドレス領域を使うことを強要した{???????????}。しかし GRUB はそれらの ELF 領域を受け入れていなかった {???????????}。GRUB の特別開発者 pavel cahyna がそれの root からの問題を適用するまでの間は GRUB を修正しておくことにした。彼は適切な物理アドレスを生成するためにリンカ―スクリプトを書き直した。今日では、それらの MH の特別領域は使われていないし、主流の GRUB イメージでは NetBSD カーネルがブート出来るようになっている( あらゆる仮想 GNU/Linux 配布物内の配布物においては )。
with the kernel recognized as a multiboot binary, i had to add the necessary code to parse the mis during boot and convert it to the native bootinfo format to minimize changes in the overall kernel. keep in mind that i was just adding another entry point to the kernel, not removing the old one, so both needed to coexist. this was tricky because of the virtual address space change that happens during bootstrap, as explained earlier: some mis handling needed to happen before the kernel enabled paging to avoid corrupting important information (basically, the ksyms).
マルチブートバイナリとして認められたカーネルにおいて、ブートしている間の MIS を解析し、カーネル全体を多少変更しネイティブな bootinfo 形式へ変換に必要なコードを追加した。私はカーネルに他のエントリポイントを追加しただけであり、エントリポイントを置き換えたわけではない。それらは同時に存在する必要があるのだ。ということを覚えておいてほしい。これはトリッキーだ。なぜならば前述したように、ブートストラップの間に仮想アドレス空間を変更するからだ。いくつかの MIS ハンドリングは、重要な情報( 基本的には ksysms )の欠落を回避するためのカーネル有効ページングが発生する前に必要となるからだ。
the c code that handles this is rather delicate and, therefore, i kept it as short as possible. once the kernel has enabled paging, the real mis parsing is done and the kernel continues its boot procedure. you can see all of this in the src/sys/arch/i386/i386/multiboot.c source file.
ハンドルする C コードは、これは多少 微妙であるんだが、なるべく短く出来るように保った。一度カーネルが有効ページングしたら、リアル MIS 解析は完了し、カーネルは自身のブート手続きを続ける。src/sys/arch/i386/i386/multiboot.c ソースファイルで全てを見ることができる。
at last, i would like to comment on another area that was difficult to manage. the native boot loader loads the netbsd kernel and stores it in memory following a specific memory layout: the kernel is first, followed by an integer that registers how many symbols the kernel has, followed by a minimal elf image that contains the kernel's symbol and string tables. when using grub, these tables load in different and unpredictable locations.
最後に、私は管理するのが難しい他の領域についてコメントしたい。ネイティブブートローダーは、NetBSD カーネルをロードし、以下に示すメモリ配置へ設置する。カーネルは最初にある。次に、カーネルがどれだけのシンボルを持っているかの整数値がある。次に、カーネルシンボルと文字列テーブルを含んだ最低限の ELF イメージがある。GRUB を使う場合、これらのテーブルは異なる場所、予測できない場所からロードされる。
a first step in resolving this problem was to reserve some space in the kernel to copy the symbols table to the appropriate place on the fly, but this proved to be a very ugly hack. a recent fix moved the symbols table to just after the kernel (taking care not to overwrite it or other important information during the move). the kernel also has a specific function to initialize the ksyms global table based on a memory region (not necessarily a complete elf image). you can see this in the ksyms_init_explicit function defined in src/sys/kern/kern_ksyms.c.
この問題を解決するための最初の手順は、カーネルがシンボルテーブルを適切な場所へダイレクトにコピーできるように、いくらかの領域を予約することだ。しかしこのやりかたは実に酷い hack だ。関連した fix はシンボルテーブルを、ちょうどカーネルの後ろへ移動する( 移動させている間にカーネルや重要な情報を上書きしないように注意 )。カーネルは、メモリ領域をベースにした ksyms グローバルテーブル( 必ずしも ELF イメージではない )を初期化するための特別な関数も持っている。ksyms_init_explicit 関数の定義は src/sys/kern/kern_ksyms.c で見れる。
conclusion ( 終わりに )
if all operating systems supported the multiboot specification, users would be happier than they are now: a very advanced boot loader supporting all operating systems would most likely exist, and its installation could be trivial. plus, these users would not need to care about the installation of an os disabling another os.
すべてのオペレーティングシステムがマルチブート対応したならば、利用者はいまよりも幸せになるだろう。ブートローダーがかなり進歩してすべてのオペレーティングシステムに対応ことがもっともありがたいことである。そしてそれは、インストール作業が取るに足らないことになるだろう。さらに、これらの利用者は、OS インストール作業で他の OS を無効にすることに注意する必要がなくなるだろう。
personally, i found the process of making the netbsd kernel multiboot-compliant to be a very interesting and instructive task. furthermore, because almost all linux distributions nowadays install grub by default, it is now a lot easier to set up a dual-boot machine with both linux and netbsd. further steps involve splitting the kernel in two different sections within the elf binary in order to map each of them at separate virtual addresses. this could simplify some of the issues that arise in the code that runs before paging is enabled.
個人的にはマルチブート対応 NetBSD カーネルを作成する作業はとても面白かったし、タメになった。そのうえ、いまどきのほとんどすべての Linux ディストリビューションは既定で GRUB をインストールするので、今や Linux と NetBSD の両方でデュアルブートマシンをセットアップすることはとても簡単である。さらに先のステップとしては、されたカーネル、分割された仮想アドレスの各々へマップするための ELF バイナリ内の 2 つの異なるセクションで、カーネルを分割することだ。これはページングが有効になる前に走るコードで発生するいくつかのシンプルな課題で出来る。
now it is your turn to adapt your favorite operating system to this protocol and attempt to get your modifications into the mainstream sources!
次はあなたの番だ。このプロトコルにあなたの好きなオペレーティングシステムを適合させ、あなたの改造をメインストリームのソースにも試してみよう。
julio m. merino vidal studies computer science at the fib faculty in barcelona, spain.
2012-06-17 :-)
2014-06-17 :-(
_ 午後
1300 デバッグしTARI
_ すくすくスク水
スクラム の原典があるというのでたどり着いたが会員登録しないと全文読めないので会員登録した。
The New New Product Development Game - Harvard Business Review
2015-06-17 :-(
2016-06-17 :-)
_ [ガルパン]ガールズアンドパンツァー テレビシリーズ12話一挙放映を見てきた
＠イオンシネマ港北ニュータウン ULTIRA
18:00～23:30 という長丁場。一挙放映というのは随所で様々な作品でやっているが、初めて見る。
こうしてあらためてテレビシリーズを見返してみると、劇場版にはテレビシリーズをオマージュした場面が多々あることがわかる。大洗女子学園の生徒たちの成長は大きいし、バレー部チームの急成長ぶりが半端ない。
そしてやはり劇場版のクオリティは狂気の沙汰だ(褒め)。とくに 3D CG は凄まじいクオリティなのだな。まあテレビ用の画質を劇場用の大スクリーンで見れば粗さが目立つのは当たり前だし、劇場の大スクリーンでも見れるようなクオリティで劇場版が作られているので比較にならんのだけど、それにしても劇場版がどれだけ作りこまれているのかをあらためて実感せざるをえない。
これでまた劇場版を見るのが楽しみになった。
2017-06-17 :-)
_ [艦これ][富士急ハイランド][瑞雲ハイランド]「艦これ」鎮守府瑞雲祭りin富士急ハイランド泊地 へ行ってきました
＠富士急ハイランド
なぜ瑞雲なのか。その謎を確かめるために我々は現地へと向かった。
大月駅
大月駅からすでに準備万端である。
ラッピング列車があるというのでせっかくだから乗ることにした。時刻表はこちら 【お知らせ】「艦これ」鎮守府瑞雲祭りin富士急ハイランド祭りとのコラボ企画のご案内 - 富士山に一番近い鉄道 富士急行線
車内は艦これ一色だった。
日向と最上
これがラッピングだ。日向と最上以外はとくに新しいイラストは無かったし金剛の牛丼コラボイラスト等なぜこのイラストを選んだのか、さらに謎は深まるばかりだった。
富士急ハイランド
富士急ハイランドは瑞雲ハイランドとなりました(バカが作る日本地図風に)
おひる
艦これコラボカレーがあるので注文してみた。第六駆逐隊、金剛、足柄のカレーの3種類がある(たしか)。これは第六駆逐隊のカレーである。右上にはゼリーが載っている。
食堂には連装砲ちゃんが居た。
瑞雲
除幕式は撮影禁止(声優が登場するため)。ブリドカットセーラ恵美が終始セリフを噛んでいたのが貴重な体験だった。声優の挨拶の後、KADOKAWAの代表取締役と富士急ハイランド代表取締役の挨拶があった。瑞雲お披露目は2社の首脳陣が挨拶に来るほどの出来事なのである。
これが瑞雲だ。
鎮守府「瑞雲」観閲式スペシャルステージ
声優のトークショーである。
外側だけ撮影した。
なおここでもブリドカットセーラ恵美がいろいろやらかしていた。可愛い。
主役の日向の声をあてている大坪由佳によると、結局なぜ瑞雲なのか分からないようだった。
日向のイラストレーターも謎の反応をしめしていた。
ママに「船のゲームなのになんで飛行機作ったの？」って言われた
— しばふ (@shibafu482) 2017年6月17日
艦娘音頭
ステージ終了後に瑞雲を囲んで「艦娘音頭」を踊った。これは、瑞雲完成と無事を祈って、艦娘と提督たちによる祈りの歌である。
いえゆい のぼめの れんみり よじゅよご はさてかなえ くたまえ
( 設定/【祈りの歌】 - ファイナルファンタジー用語辞典 Wiki* )
なお私は踊りをマスターしていないので舞台上の声優(誰だ。前半は左隅に居た。後半「瑞雲音頭」のときは右隅にいた)を見ながら踊っていた。彼女はかなりキレキレの動きをしていた。あの動作には惚れた。でも誰だか分からない。
艦娘パネル
富士急ハイランド園内のいたるところに艦娘たちのパネルがある。セリフは瑞雲ハイランドにちなんだものとなっている。
本日の主役たちだ(瑞雲を積める艦娘)
ダイソンさんこと戦艦棲姫。これを見た幼女が「わあ！深海棲艦だ！」とはしゃいでいたんだが、なぜ知っている(R18です)。
あいにく私は帰りのバスの時間が迫っていたので艦娘パネルはコンプリートできず。7月にもイベントがあるのでそのときにリトライしよう。
2018-06-17 :-)
_ 一日中ぐったりしていました
平日労の疲れがとれません。
_ プリキュアを見ました
新たなプリキュアが誕生しました。
これでプリキュアオールスターズを見れば堀江由衣(魔法つかいプリキュア！)と田村ゆかり(HUGっと！プリキュア)のプリキュアを見ることができます。
_ [git]git reabse
素人なので git rebase がいまいち実感できなかったので手元で試しました。
テキトーに github リポジトリを作って(作る必要性はないけど) GitHub Desktop でブランチとその履歴がビジュアルで見れるのでこいつで見ながら git コマンドを 1 つずつ確認しながら進めるとよいですね。
ref. Git - リベース
2019-06-17 :-|
_ ,
帰宅してから進撃の巨人、ガンダム THE ORIGIN、キャロル＆チューズデイを見ました。
_ [艦これ]艦これ 2019春イベント「発動！友軍救援「第二次ハワイ作戦」 E5 北太平洋ハワイ諸島南東沖
丙クリア。丙はゲージ 2 は大破撤退なしでストレート撃破したのでストレスなく進みました。
- ゲージ1
- ルートギミック解除
- ゲージ2
という流れです。
ゲージ1
水上打撃部隊で行きました。
ルートギミック
【春イベ】E-5 ルート出現ギミック 波濤の先に――【第二次ハワイ作戦】 | ぜかましねっと艦これ！
丙なのでこれだけ
- 水上打撃部隊
- Eマス航空優勢（防空）【甲乙丙丁】
- 空母機動部隊
- XマスS勝利【甲乙丙丁】
- ※乙難易度でA勝利解除の報告有り。要追試
- 輸送連合
- VマスB勝利以上【甲乙】C敗北以上【丙】
- 基地防空
- 防空時に航空優勢【甲乙丙】
Eマス航空優勢 水上打撃部隊
艦隊制空値 868
基地航空隊は対潜を B マスへ。他は退避。
XマスS勝利 空母機動部隊
制空値 747
K→M のために水母が必要。
道中支援あり。艦隊の砲撃戦開始前に終わりました。
基地航空隊
- 第一 Xマス
- 第二 Kマス
- 第三 Cマス
Vマス C敗北以上(丙) 輸送連合
【春イベ】E-5 ルート出現ギミック 波濤の先に――【第二次ハワイ作戦】 | ぜかましねっと艦これ！
L→Nの固定は以下”何れか”の条件を満たすことで可能になると考えられています。
- 索敵：33式で30以下にする
- 編成に水母または補給艦を採用する
- 編成に航巡2を採用する
とのことなんですが索敵値 30 以下について 艦これ - 艦隊編成ツール で計算するとかなり低レベル艦娘を入れないと索敵値 30 以下にならないですね...。高レベル艦娘を編成すると何も装備させなくても索敵値 30 超えます。
航空戦艦x2 と航巡x2 で L→N いけるという話題を見かけたのでやってみました。固定できました。なお索敵値は 86 。分岐点係数 1.0 です。
道中支援あり。道中は航空優勢。
基地航空隊は
- 第一 Hマス
- 第二 Vマス
- 第三 Bマス
基地防空
基地空襲されるまで空母機動部隊でテキトーに出撃します。
制空値 482
これで航空優勢でした。
ゲージ2
削りも破壊もこれで行きました。
艦隊制空値 572 盛りすぎか。
基地航空隊は全部隊ボス集中。
2020-06-17 :-|
_ 労
ストレージ労。udev 完全に理解した。
_ [水瀬しあ]水瀬しあ配信を見ていた
朝と夜。
《SHOWROOMにて配信中》
— 水瀬しあ🏖️ポケモン楽しみすぎて前歯抜けた (@minase_shia) June 16, 2020
僕は明け方に『ミスミソウ』をみたよおはよぅね( 'ཫ' )https://t.co/zvwQlOvDKl
《SHOWROOMにて配信中》
— 水瀬しあ🏖️ポケモン楽しみすぎて前歯抜けた (@minase_shia) June 17, 2020
ダークポケモンなら任せてください。https://t.co/lehyE8aK1H
2022-06-17 :-(
_ ちょっと休憩
飯を食べるために和堂に行ってみたら今日からコラボカフェが開催されていた。
BL だそうです。 女性客がめちゃたくさん居ました。
フードもドリンクもメニューはコラボカフェ特化のためコラボメニューのみ。
コーヒーを飲んで AKIRA を読んで帰ってきました。
あとさすがに店員さんに顔を覚えられたらしい。
2023-06-17 :-)
_ 日誌
0900 起床
部屋掃除
コーヒーを飲むなど
おひる。ラーメン。
庭の雑草がすごかったので引っこ抜いた。
ジョジョの奇妙な冒険 第6部 ストーンオーシャン を見始めた。dアニメストアで配信開始されたので。週刊少年ジャンプでの連載時も読んでたはずだけどほぼ覚えていない。
コーヒーを飲むなど
おやつ。文明堂のどら焼き。佐世保土産。
艦これ三越コラボの最上のやつが届いた
リッジレーサー7オンラインバトルをやるなど。今日は始終チームバトルでした。
_ kの字 [人間どーでしょーたいまー(言ってて空しい]
_ みわ [どーでしょー業務お疲れ様です]
_ ちゃぴ [全部用件を聞いた後に、「もう一度お名前宜しいですか？」と聞いて、繋いだ先で同じことを言わせることは多々ありますが(^..]