awslinuxにgit最新をインストール

yum installだとgit 1.7.1が入り、テンションだだ下がりなので、最新のgitをgzファイルからインストールします。

# git install
# 依存ライブラリインストール
$ sudo yum -y install gcc curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker autoconf

# インストール場所に移動
$ cd /usr/local/src/

# ダウンロード対象を確認(https://mirrors.edge.kernel.org/pub/software/scm/git/)
# 今回は git-2.19.2.tar.gzを使う
$ sudo wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.19.2.tar.gz

# ファイル解凍
$ sudo tar xzvf git-2.12.2.tar.gz

# 不要ファイル削除
$ sudo rm -rf git-2.19.2.tar.gz

# 移動してmake
$ cd git-2.19.2
$ sudo make prefix=/usr/local all
$ sudo make prefix=/usr/local install

# git version確認
$ git –version
git version 2.19.2

ふぅ

vagrantでamazon linuxの環境構築

virtual box, vagrantをダウンロード&インストールします。

# ディレクトリ作成
$ mkdir awslinux
$ cd awslinux

# vagrant init
$ vagrant init mvbcoding/awslinux
$ ls
Vagrantfile

vagrantfileのポートフォワーディングのコメントアウト削除

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  config.vm.network "private_network", ip: "192.168.33.10"

# 少し時間がかかります
$ vagrant up

$ vagrant status
Current machine states:

default running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.

# ssh接続
mac:awslinux mac$ vagrant ssh

__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/
29 package(s) needed for security, out of 38 available
Run “sudo yum update” to apply all updates.
Amazon Linux version 2018.03 is available.
[vagrant@localhost ~]$

きゃー

Instance does not have a volume attached at root (/dev/xvda)

Instance does not have a volume attached at root (/dev/xvda)
え?そんなばかな?
よく見たら、EBSのattacheが/xvdaディレクトリのところ、/sfd になってますね。

Attachment information
i-*:/dev/sdf (attached)

attachする際にも書かれています。

Linux Devices: /dev/sdf through /dev/sdp

centOSの/devには、sdfは見当たらないので、Amazon Linuxのみでしょうか?
/devは?
>UNIXやPOSIX準拠OS(Linux等)で、コンピューターに接続されたデバイス(マウスやキーボード、ディスク等)のスペシャルファイルが置かれるディレクトリ。

/xvdaにattachして、instanceをstartすると、アラートが消えます^^

EXEファイルのセクション

セクションにはデータサイズ、RVAなどが保存される
L ネイティブコード、リソース情報、デバッグ情報など
L 読み込み専用領域、再配置情報、インポート関数、エクスポート関数など

なるほど、ソースコードだけでなく、ソフトウェア一式ってイメージだな

typedef struct _IMAGE_SECTION_HEADER {
	BYTE Name[IMAGE_SIZEOF_SHORT_NAME];
	union {
		DWORD PhysicalAddress:
		DWORD VirtualSize;
	}
	DWORD VirtualAddress; // セクションサイズ
	DWORD SizeOfRawData; // セクション位置
	DWORD PointerToRawData;
	DWORD PointerToRelocations; //再配置エントリ情報
	DWORD PointerToLinenumbers; //行番号
	WORD NumberOfRelocations; //再配置エントリ
	WORD NumberOfLinenumbers;
	DWORD Characteristics; // セクション特性
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADERS;

Nameはセクション名
.text, .data, .idata, .edata, .rsrc, .debug, .reloc, .tls

.text, .data, .rsrcなどの各セクションはIMAGE_SECTION_HEADER構造体の後に配置。やっとか。

インポートは外部DLLと動作リンクを行う
リソースセクション(.rsrc)では、実行に直接関係ない特徴的なデータを管理
 L データ型、ID、言語

結構気の遠くなるようなことやってるなー
あれ、でもメモリのポインタってC言語だとソースの中で指定するはずだけど、PointerToRawDataでIMAGE_SECTION_HEADER構造体で指定している?
それと、ネイティブコードのセクションは構造化されるのだろうか?それとも、1つのセクションに纏められるのだろうか?データ処理で考えると、.textセクション、.dataセクション、.rsrcセクションなど各セクション内部で構造化された方が効率的に見えるが。。
ああああ、メモリかー

EXEファイルのPEヘッダ

IMAGE_NT_HEADERS32に定義

typedef struct _IMAGE_NT_HEADERS {
	DWORD Signature;
	IMAGE_FILE_HEADER FileHeader;
	IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADER32, *PIMAGE_NT_HEADERS32;

PE headerにもSignature
4byte? 32bitOSを意志的している

IMAGE_FILE_HEADER構造体

typedef struct _IMAGE_FILE_HEADERS {
	WORD Machine;
	WORD NumberOfSections;
	DWORD TimeDataStamp;
	DWORD PointerToSymbols;
	DWORD NumberOfSymbols;
	WORD SizeOfOptionalHeader;
	WORD Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_NT_HEADERS;

Machineはそれぞれフラグがあう
unknown:0x0 あらゆるマシンタイプ
I386:0x14c Intel386以降
R3000: 0x162
R4000: 0x166 MIPS(r)リトルエンディアン
R10000: 0x168
….

NumberOfSections: 保持するセクション数
TimeDataStamp: 作成された日時
PointerToSymbols, NumberOfSymbols:シンボルテーブルの位置、数
SizeOfOptionalHeader: 構造体サイズ保持
Characteristics:ファイズ属性値
 IMAGE_FILE_EXECUTABLE: 0x0002
IMAGE_FILE_LINE_NUMS_STRIPPED: 0x0004

IMAGE_OPTIONAL_HEADER32構造体も同様に定義される
 Magic,MajorLinkerVersion, SizeOfCode, SizeOfInitializedData,
SizeOfInitializedData, SizeOfUnitializedData,AddressOfEntryPoint, BaseifCode, BaseOfData, ImageBase, …

IMAGE_DATA_DIRECTORY構造体はRVA, Size

PE Headerにはターゲットマシン、アライメント情報、セクション情報、メモリサイズ情報などが格納されており、OSがメモリにロードして実行する際に書き込まれる

OS側では書き込まれた内容を元にメモリで実行する
ツールを使用すればコンパイル時に自動生成される
第一印象項目が多いなと思ったが、exeファイルの共有フォーマットと考えると妥当か

EXEファイルの内部構造

Windowsの実行ファイルEXEファイルは、通常Visual C++, Visual Basic, Delphiなどのコンパイラが自動生成する
L ほとんどがデータサイズ、ファイル、メモリを指し示すオフセット値で構成されている

MS DOSはマイクロソフトが開発したパソコン用OS
sublimeで開くとバイナリコードでどのように書かれているかわかりません。
 L x86に対応する機械語。アセンブラではない。

MZシグネチャはEXEファイルを裏付けるデータ

EXEファイルが動くマシン
– Intel 386以降(Windows)
– MIPS(r)
– Alpha AXP(tm)
– Motorola 68000
– Power PC
– 日立SH3, SH4

リソース箇所にデータを格納する

PEヘッダ(Portable Executable)
EXEファイルの先頭部分の情報

EXEファイルのロード方法
MicrosoftのOSが、MZシグネチャ、マシンタイプ、ネイティブコードなどの情報をもとにEXEファイルをメモリ上にロードして実行する
1. シグネチャ、マシンタイプを確認
2. EXEイメージをメモリ上にコピー
3. PEヘッダ記載データを元にEXEイメージの初期化
4. PEヘッダで指定されたスタートポイントからプログラム実行
なるほど、ディスクに保存したexeファイルをメモリ上に読み込んで、1行ずつ処理していくのね。

EXEファイルイメージは実行前にプロセスメモリの任意の場所にロードされる。メモリの先頭位置をイメージベースという。
RVA(Relative Virtual Address)とはイメージベースからの相対オフセット値
ファイルポインタで読み込み対象となるデータ位置を指定し、RVAでプロセスメモリ上のデータを指し示す

イメージベース + RVA = データアドレス

EXEファイル先頭
IMAGE_DOS_HEADER …MS-DOSで認識可能なデータフォーマット
MS-DOS用スタブ …ネイティブコードを保存できるスペース
NULL空間 … PEヘッダの先頭位置は8バイト境界
PEヘッダ

なるほど、*.exeと*.pkgではソースコードは一緒だけど単純に拡張子だけ異なるって訳ではないのね。当たり前か。
EXEファイルがMS-DOS用のヘッダやデータフォーマットということは、一つのソフトでもOSが変われば当然、ファイルの中身が違うってことですな。

OSごとのインストールファイル

zipファイルなどのアーカイブファイルを展開した場合、アプリケーション管理ができない、インストール・アンインストールの設定が自動的にできない、などの制限があるため、インストーラがインストールする

Windows
1.exe形式のインストーラ
2.msi形式のインストーラ
 L リソース情報だけを持っており、インストールはWindows Installerで行う
 L Visual Studioを利用すれば、msiを利用したexe形式としてインストーラを作成できる

OS X
1.appファイル
2.dmg(ディスクイメージファイル)
3.pkg(パッケージファイル)
 L 動作に必要なパッケージも同時にインストール
 L パッケージ管理システム Homebrew

Ubuntu
1. apt
L debファイルからインストール

CentOS
1. rpm

OSごとにインストールファイルやその仕組みが異なることは分かった。
で、これ全部C言語で書いて、buildする必要あるの??

Androidのアーキテクチャ

AndroidのカーネルもLinuxなのね。
アプリケーションフレームワーク、標準フレームワークなどは様々な技術が使用されている

https://android.googlesource.com/

あれ、なんだgoogle gitって?
こちらでやられてるんだ。

スパコン

スパコンは多数のノード(cpuとメモリ)をネットワークで繋げたもの
典型的なノードは数万ノード(京は8万)
※88128CPU(705024コア) 70万コアってことは1コア9スレッド?
パイプライン方式で処理を高速化
チューニングは作用反作用無視、条件分岐削除、相互作用粒子ソード、除算削除
OSはlinuxが多い
開発言語はFortran, C/C++

中国の「神威太湖之光」。1秒間に9.3京回の計算
中国はCPUも内製

現在の主な用途は、軍事、量子力学、天気予報、気象研究、計算化学、物理シミュレーションなどか。

GPU

ビデオカード、グラフィックカード、グラフィックボードと呼び方は多数
ビデオチップをGPUと呼ぶ。ビデオメモリもある

macだと、グラフィックスに、Intel Iris Plus Graphics 640 1536 MB と記載がある
これはCPU一体型のGPUなので、独立型より性能は劣る

GPU
グラフィック演算処理、並列演算処理(スーパースカラ)が得意
CPUが3〜5の並列処理のところ、GPUは512も
コア数もCPUよりGPUの方が多い、 eg.5120
消費電力が高い
500Mhz~650Mhzあれば綺麗な画像で楽しめる

VRAM(ビデオメモリ)
 映像データを一時的に保存
 RAMと同様、容量、速度が重要。128〜258MB, 1Ghz~1.8Ghzあれば十分
メモリバス幅は128〜256bit

ビデオカードスロットとバスには 1) AGP(転送速度が2.128GB/S)と 2) PCIエクスプレスX16(主流、4GB/S) の2タイプがある

ビデオカードには、DVI-I端子(デジタル・アナログ)、B-sub15ピンのVGA端子(アナログ)、DVI-D(デジタル)などの端子がある
TV出力端子(S端子)はテレビに表示

グラフィックボードのチップメーカーはNVIDIA、AMDなど
NVIDIAはよく聞きますね。あれ、AMDって、CPUだけでなく、GPUもやってるの?

MSI GeForce GTX 1660Ti Gaming X
MSI GeForce GTX 1060 GAMING X 6G
Nvidia GeForce RTX 2080 8GB GDDR6 – Founders Edition
 L VRAMの容量が大きいほど描画が綺麗になりやすい
 L GeForceはゲームを目的とすると、動作保証が取れているということ