You can access the English version in the lower part of the page.

1.はじめに

こんにちは、OpenChainのAutomotive Chairや
このアドベントカレンダーを企画しているPromotion SGリーダーを務めさせて頂いている遠藤です。
今回の主役はShaneさんですので、自己紹介は別の機会（6日）にさせて頂きます。

今年のAdvent CalenderのテーマはOpenChain SpecのISO化ですので、
本日はOpenChainの中の人である、
General ManagerのShaneさんにQ&A形式でメッセージを頂きましたので、お楽しみください。

2.Shaneさんからのメッセージ

Q: OpenChain SpecのISO化おめでとうございます！率直なご感想をお聞かせください。

A: オープンソースコンプライアンスは、オープンソースである限り存在するものです。
しかし、OpenChainプロジェクトがSpecを提供する前は、
高品質のコンプライアンスに関する単一の客観的な基準はありませんでした。
人々と企業は最善を尽くし、しばしば良い仕事をしましたが、彼らは孤立して働いていました。

グローバルなサプライチェーンは相互に関連しており、企業は相互に依存しています。
そこで、コンプライアンスを適切に行うための明確な方法を1つ作成する必要がありました。
OpenChainは、これが短くて理解しやすい仕様で実行できることを証明しました。

OpenChain Specの最初のバージョンがリリースされて5年が経過しましたが、
本年、Specは広く使用されている業界標準から正式なISO国際標準に変貌を遂げました。
これは、特にオープンソースやオープンソースライセンスの管理に精通していない業界においても、
販売と調達のスタッフをオープンソースの議論に参加してもらうことが容易になることを意味します。

ISO標準としてのOpenChainは、オープンソースの企業での使用を恒久的に変えていくものです。
時間の経過とともに、オープンソースを使用して製品やソリューションを作成するすべての企業が、
ISO標準を使用するようになるでしょう。
ISO9001や14001と同じくらい一般的になると思います。

このISO標準により、オープンソースがソフトウェアを含むあらゆる製品またはソリューションに
とって快適で信頼できる選択肢になることを可能にすなるだろうというのが私の率直な感想です。
この標準はサプライチェーンをより効率的にするのに役立ちます。
これにより、リソース管理と問題解決に数百万ドルを節約できます。
このインパクトは大きいでしょう。

Q: ShaneさんはOpenChainの設立から関わっていると思いますが、Specを作ることになった経緯を教えてください。

A: 2015年の時点で、オープンソースが非常に成功したことは明らかでした。
それは約20年間市場に存在していましたが、特に2005年から2015年の間に非常に大きな発展を遂げました。
オープンソースは、データセンターから携帯電話、エアコンに至るまで、あらゆるものに利用されるようになりました。
このテクノロジーの影響は驚くべきものでした。

ただし、重要な課題が残っている領域が1つありました。
複雑なサプライチェーンでは、企業間でオープンソースを渡し、オープンソースライセンスの要件を一貫して
確実に満たすことが非常に困難でした。
これは悪意によるものではありませんが、各企業が独自の方法でオープンソースコンプライアンスを解決しており、
20社または30社のサプライチェーンがライセンス管理に多くの変動と違いをもたらしたためです。
このような状況では、エラーが頻繁に発生してしまいます。

そこでOpenChainは、組織内のオープンソースをサプライチェーン全体で繰り返し可能な方法で管理するための
単一の明確でリソース効率の高い方法を作成しようというアイデアから生まれました。
一貫性を提供し、一度に1社ずつサプライチェーンへの信頼を高めるために構築されました。
言い換えれば、それは、最良の実世界のソリューションを使用して実世界の問題を具体的に解決するように設計されました。

Q: OpenChain Specのコンセプト、フィロソフィーとはどういうものなのでしょうか？

A: OpenChainは、高品質のオープンソースコンプライアンスプログラムの主要な要件を定義します。
したがって、OpenChainを使用するすべての企業は、特注のソリューションを使用する企業よりも信頼できます。
OpenChainは、あらゆる規模の企業があらゆる市場で使用できるように、
可能な限りシンプルで不可知論的なものになるように注意深く設計されています。
OpenChainは、数百の企業からの数千人時間の経験を7ページの標準に抽出します。
これは、可能な限り最もシンプルでエレガントなソリューションになるように設計されています。

Q: ISO化を契機により多くの人々がOpenChain Specに触れることになると思います。
　 そのような人々にメッセージがあればお願いします。

A:オープンソースは、数十億ドルのサードパーティコードへのアクセスを提供します。
オープンソースライセンスには、明確で合理的な条件がいくつか記載されています。
他の知的財産と同じように、私たちはライセンスに従う必要があります。
ただし、これまで、これを行うための最良のプロセスを特定することは困難でした。
オープンソースライセンスについて詳細な知識を持っている弁護士、プロジェクトリーダー、
エンジニアはほとんどいませんでした。

ウェブサイトなどのパブリックドメインの情報が、異なる用語や意図を示唆している場合があります。
欠けていた部分は、オープンソースコンプライアンスを行うための明確で、シンプルで、信頼性が高く、
効率的なプロセスアプローチでした。

OpenChainはこれを変更します。 ISO標準またはOpenChain2.1を採用して、
高品質のオープンソースコンプライアンスプログラムがあることを知ることができます。

今日、世界中のどの企業もwww.openchainproject.orgにアクセスして、
オープンソースコンプライアンスの国際標準を見つけることができます。
サポートリファレンス資料の閲覧や、無料の自己認証サポート、さらに必要に応じてサードパーティのサービスプロバイダー
のサポートを受けることも可能です。
あなたが誰であるかに関係なく、利用可能なリソースに適した方法で、
Microsoft、Qualcomm、Hitachi、Toyotaと同じプロセスアプローチを構築できます。
これは市場の目覚ましい変化です。
あなたがサプライヤーである場合、これはあなたがこの分野で質の高い知的財産管理を行っていることを示す方法です。
あなたが顧客である場合、これはあなたの調達が高品質のオープンソースコンプライアンスを含むことを確実にする方法です。
何千もの企業がオープンソースでさらに優れた成果を上げるのを支援するためにご参加ください。

3.明日のテーマは・・・

今週行われたLinux Foundation関係のイベントではOpenChainに関するイベントが多く開催されました。
明日は、小泉さんがこれらのイベントをまとめてくれます。
お楽しみに！

1.Introduction

Hello, this is Endo who is Promotion SG leader and Automotive Chair of OpenChain.
Shane is the main of the article, so I will introduce myself on another occasion.

This year's Advent Calendar theme is OpenChain Spec ISO.
So, today, I received a message in Q & A format from Shane, who is a General manager of OpenChain,
Please enjoy it.

2.Message from Shane

Q: Congratulations on ISO conversion of OpenChain Spec!!
Please tell us your frank impressions.

A:Open source compliance has existed as long as open source.
However, until OpenChain there was no single, objective standard for high quality compliance.
People and companies did their best and often did a good job, but they were working in isolation.
The global supply chain is interconnected and companies depend on each other.
It was necessary to create one clear way to do compliance properly.
OpenChain proved this could be done with a short and easy to understand specification.

Now, after almost five years in the market, OpenChain has changed from a widely-used industry standard into a formal ISO International Standard.
This means that it is much easier to include in sales and procurement discussions, especially in industries that are not familiar with open source or in managing open source licenses.
I believe that OpenChain as an ISO standard has permanently changed corporate use of open source.
Over time every company using open source to make products and solutions will be using our ISO standard.
I expect it to become as common as ISO 9001 or 14001.

My frank impression is that this ISO standard will allow open source to become a comfortable, trusted choice for any product or solution containing software.
It will help make the supply chain more efficient.
It will save many millions of dollars in resource management and issue resolution.
The impact will be huge.

Q: Please tell us how the community decided to create Spec.

A: In 2015 it was clear that open source was very successful.
It had existed in the market for about two decades, but especially in the time period between 2005 and 2015 it became ubiquitous.
Open source was in everything from our data centers to our mobile phones to our air conditioners.

The impact of the technology was amazing.
However, there was one area which remained a significant challenge.
In complex supply chains it was quite difficult to pass open source between companies and to consistently, reliably meet the requirements of open source licenses.
This was not due to any ill-intent, but because each company was solving open source compliance in their own way, and a supply chain with 20 or 30 companies meant a lot of variables and differences in license management.
Errors would often occur.

OpenChain was born out of the idea of making a single, clear and resource effective way to manage open source in organizations and in a repeatable manner across the supply chain.
It was built to provide consistency and to increase trust in supply chains, one company at a time.
In other words, it was designed to specifically solve real world problems using the best real world solutions.

Q: What is the OpenChain Spec concept, philosophy?

A: OpenChain defines the key requirements of a quality open source compliance program.
Every company using OpenChain can therefore be trusted more than companies using bespoke solutions. OpenChain is carefully designed to be as simple as possible and as agnostic as possible so that companies of all sizes and in all markets can use it.
OpenChain distills thousands of human-hours of experience from across hundreds of companies into a seven page standard.
It is designed to be the simplest, most elegant solution possible.

Q: I think that many people will meet OpenChain Spec as a result of becoming ISO.
If you have a message for such people,

A:Open source provides access to billions of dollars of third-party code. There are some clear, reasonable conditions described in open source licenses. Just like any intellectual property, we need to follow the licenses. However, in the past identifying the best processes to do this was challenging. There were few lawyers, project leaders and engineers who had detailed knowledge about open source licenses. Sometimes information in the public domain, such as on websites, suggested different terms or intentions. The missing part was a clear, simple, reliable and efficient process approach for doing open source compliance. OpenChain changes this. You can adopt the ISO standard or OpenChain 2.1 and know that you have a quality open source compliance program.
Today any company in the world can go to www.openchainproject.org and find the International Standard for open source compliance, supporting reference material, free self-certification support, and - if they need it - third-party service providers. No matter who you are, you can build out the same process approach as Microsoft or Qualcomm or Hitachi or Toyota in a way that suits your available resources. This is a remarkable change in the market. If you are a supplier, this is a way to show that you have quality intellectual property management in this space. If you are a customer, this is a way to ensure your procurement includes quality open source compliance.
Join us in helping thousands of companies do even better with open source.

3.Tomorrow's theme is ...

Many events related to OpenChain were held at the Linux Foundation Summits this week.
Tomorrow, Koizumi-san will introduce these events’ summary .
Looking forward to!

You can access the English summary in the lower part of the page.

1. はじめに

こんにちは。
一昨日に続いての登場の遠藤です。

改めて自己紹介させて頂きますが、
OpenChainでは、本Advent Calendarを企画しているJapan WG Promotion SGのリーダーや
グローバルではAutomotive Chairを務めさせて頂いています。
本業ではデータビジネス関係の企画・開発を行うチームのマネージャーに最近なりました。
アジャイル開発を勉強して、スクラムマスターの資格(LSM)をとったところです。

趣味は旅行、ガジェット、スポーツ観戦（主にサッカー）です。
今冬は、PS5とGalaxy Note20 Ultraをゲット予定でしたが、
前者は購入できず、後者は楽天からSIMフリーバージョンがなかなか発表されなかっため、
結局パシフィックブルーとカメラ性能に惹かれてiPhone12 Pro Maxを買っちゃいました。
最近はアストロシティミニを購入すべきか悩み中です。
世代的にST-V基板やMODEL2基板のソフトが入っていれば即買いだったんですが。

さて、本日は各企業のOSSコンプラ体制構築進捗状況について共有させて頂きます。
先週一週間でOpenChain標準の概要を説明させていただいたのですが、
皆さん一番気になるのが「他社は実際どこまでやってるの？」ということかなと思います。
Japan WGでは今年そのような疑問に答える調査を行いましたので、調査概要をシェアさせて頂きます。

2. 調査概要

OpenChain Japan WG Promotion SGでは昨年も紹介したように
コミュニティ、企業、政府、メディアなど様々なパートナーとOSSコンプラの重要性の啓発を行ってきました。
そんな中、2020年は学術界と連携し、OSSコンプライアンスについての研究チームを立ち上げました。
まずは、状況把握が重要ということで、国内外企業向けのアンケートを実施し、
59社から回答を得ました。回答者の属性は以下のようになります。
その中で、各社の進捗状況を明らかにするためにアンケート結果の中から
ISO標準とほぼ同じものであるOpenChain Spec2.0の各項目に関連する項目をまとめました。
レポートはGitHubからDLできますので、今回はエッセンスをご紹介いたします。

3. 結果のサマリー

まずは、OpenChain Spec2.0の各項目のうち比較的各社での整備が進んでいる項目について見ていきましょう。

Sec1.1では文書化されたOSSポリシーを社内で周知させていることを要求しています。
調査対象のうち83％が何らかの形でOSSに関するポリシーを用意していることがわかりました。

次に、各社が苦戦している項目について見てきます。

上記のグラフは予算の項目ですが、人員の確保についても同様の傾向がみられます。
これらを分析すると、OSSコンプラの重要性は認知されはじめポリシー等のルール作りは進んでいるものの、
未だリソーセスが潤沢に割かれているという状況ではないことがわかります。

最後に全体のまとめのスライドもみて見てきましょう。

全体を見てみるとリソーセスの他に、
コントリビューションについても課題があることがわかります。
コントリビューションについては今月後半より詳細にご紹介する予定です。
いずれにしてもISO標準の認証取得のためには全ての項目を満足する必要があります。
OpenChainでは各社の認証取得するためのサポートになる情報提供を続けていきます。

4. 明日のテーマは・・・

明日からいよいよISO標準の中身の紹介がはじまります。
第1弾は山田さんから1.1～1.3章についてのご紹介頂きます。
お楽しみに！

1. Introduction

Hello.
I’m Masato ENDO.

At first, I’d like to introduce myself again,
I’m OpenChain Project Automotive Chair and Japan Work Group Promotion Sub Group Leader.
Recently, I became group manager of business planning and system development in my company.
Now, I’m studying agile development agile development

My hobbies are traveling, watching sports (especially soccer), and gadgets.
I planned to get a PS5 and a Galaxy Note20 Ultra this winter. However, I could not get them.
After all, I bought the iPhone12 pro max because I was attracted to Pacific Blue and camera performance.
Recently, I'm wondering if I should buy ASTRO CITY mini.
If the software for the ST-V board and MODEL2 board was included, I bought it without hesitation.

Today, I would like to share the progress of OSS compliance governance construction of each company.
Last week we gave you an overview of the OpenChain standard.
I think everyone is most concerned about "How far are other companies actually doing?"
Japan WG conducted a survey to answer such questions.
So, I will share the survey outline.

2. Summary of the Survey

As introduced last year at OpenChain Japan WG Promotion SG,
we have been raising awareness of the importance of OSS compliance with various partners such as the companies, government, media, and community.
Meanwhile, in 2020, we launched a research team on OSS compliance in collaboration with the academic community.
First of all, since it is important to grasp the situation, we conducted a questionnaire for domestic and foreign companies.
We received responses from 59 companies. The attributes of the respondents are as follows.
In order to clarify the progress of each company, we have summarized the items related to each item of OpenChain Spec 2.0, which is almost the same as the ISO standard.
The report can be downloaded from GitHub, so this time I will introduce the essence.

3. Summary of the result

First, let's take a look at the items that are relatively being developed by each company among the items of OpenChain Spec 2.0.

Sec1.1 requires that documented OSS policies be disseminated internally.
We found that 83% of the surveyed subjects had some form of OSS policy.

Next, let's look at the items that each company is struggling with.

The graph above is for budget items, and the same tendency can be seen for securing personnel.
Analyzing these, we can see that although the importance of OSS compliance has begun to be recognized and rules such as policies are being created, resources are not yet fully allocated.

Finally, let's take a look at the whole summary slide.

Looking at the whole thing, we can see that in addition to resources, there are also issues related to contributions.
We plan to introduce contributions in detail later this month.
In any case, all items must be satisfied in order to obtain ISO standard certification.
OpenChain will continue to provide information that will support the acquisition of certification by each company.

4.Tomorrow's theme is ...

From tomorrow, we will finally start introducing the contents of the ISO standard.
At first, Mr. Yamada will introduce chapters 1.1 to 1.3.
Looking forward to!

はじめに

クロスプラットフォームなフレームワークのFlutterには、
アプリから各プラットフォームのNative機能を呼び出すためのPlatform Channelという仕組みがあります。
AndroidではJava/Kotlin, iOSではObj-C/Swiftの機能を呼び出すことができます。

一方、アプリからC/C++の関数を呼び出すためのdart:ffiという仕組みもあります。
FFIはForeign Function Interfaceの略で、DartからC/C++言語を呼び出す仕組みです。

さて、Flutter on Linuxは(現状)GTKのアプリとして動作します。
つまり、Platform Channelで呼び出される処理もC/C++言語で記述します（詳細はこちら）。

そこで、大きなデータをC/C++言語で処理した場合のパフォーマンスを
Platform Channelの一つであるMethod ChannelとFFIとで比較してみました。

結論

今回測定した条件では、Dart-C間でデータ変換が必要な場合、
Method ChannelとFFIで有意な差は見られませんでした。

一方で、データ変換が不要な場合はFFIだとasTypedListを使って、
Dart/Cの両側からアクセスしつつデータコピーの回数を減らすことができます。
当然データサイズが大きければ大きいほどその効果は大きく、今回の測定条件では約100倍FFIの方が速い結果になりました。

少なくとも大きなデータをDart-C間でやり取りする必要がある場合、
FFIでコピー回数を減らす設計にできないかを考えたほうが良さそうです。

環境

下記環境で実験しました。
Flutterの動作platformはlinuxです。

$ grep 'model name' /proc/cpuinfo | uniq -c
      8 model name  : Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
$ grep MemTotal /proc/meminfo 
MemTotal:       32752704 kB
$ uname -a
Linux chama 5.5.8 #1 SMP Sat Mar 7 22:29:22 JST 2020 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -d
Description:    Ubuntu 18.04.5 LTS
$ flutter --version
Waiting for another flutter command to release the startup lock...
Flutter 1.24.0-8.0.pre.143 • channel master • https://github.com/flutter/flutter
Framework • revision e4d94f7ccd (2 hours ago) • 2020-11-07 12:15:22 +0100
Engine • revision 1e3ceb037f
Tools • Dart 2.12.0 (build 2.12.0-27.0.dev)

計測結果

Dart側で確保したバッファにC/C++側でmemsetしDart側に返す時間を計測しました。
計測に使用したプログラムはこちらに公開しています。
実装は４種類試しています。

• 実装1. Method Channel
• 実装2. FFI (Dart-C間でデータを変換)
• 実装3. FFI (asTypedListを使いDart-C間でバッファを共有)
• 実装4. FFI (C形式でのみバッファを保持)

４つの実装方法での計測結果が以下です。
横軸がmemsetするバッファのサイズ、縦軸がかかった時間(1000回平均)です。
データコピーが発生する実装1/実装2と比較して、データコピーが発生しない実装3/実装4の方が大幅に速いことがわかります。

8MBのmemsetしたときのそれぞれの時間は以下のとおりです。
便宜上[us]単位で表示していますが、少なくとも下二桁ぐらいは測定誤差があると思います。

実装	時間[us]
実装1. Method Channel	23,182
実装2. FFI (Dart-C間でデータを変換)	21,616
実装3. FFI (asTypedListを使いDart-C間でバッファを共有)	251
実装4. FFI (C形式でのみバッファを保持)	261
[参考] 完全C実装	274

参考にdebug版の結果は以下です。
実装2(FFI (Dart-C間でのデータ変換あり）)の時間がrelease版に比べ顕著に長くなっています。
Dartで記述したデータ変換処理のAOTが効いていると考えられます。
このとおり軽く数倍変わるので、Flutterでパフォーマンスを計測する時は忘れずにrelease版にしましょう。
(flutter run --releaseでrelease版を起動できます)

終わりに

ある程度予測していた結果にはなりましたが、
実装してみてasTypedListを知ることができ、またrelease版の効果も肌で感じられたので良かったです。

release版の結果で、512KBのところで明らかに意味有りげに線形性が崩れてるのですが、理由はわかっていません（再現性はあります）。
MethodChannelでもFFIでも起こっているから私の実装バグの可能性は低いと思っているのですが、、、
また暇なときに理由を調べてみたいです。

あと今回は試していませんが、ffiで確保したバッファのアドレスをMethodChannelでやり取りするということも理論上はできると思います。
すでに関連処理をMethodChannelで実装してるんだけど、一部どうしても大きなデータをやり取りする必要が出てきた、
というようなケースではそのような選択もあろうかと思います。
(クロスプラットフォーム性はなくなるので本当にMethodChannelがいいのか考える必要はあると思いますが)

なお、Flutter on Linux Desktopはアルファ版、dart:ffiはベータ版の機能です。
性能はもちろん、Platform側の実装がGTKであることなどももしかしたら変わるかも知れませんので、ご容赦ください。

参考

MethodChannel class - services library - Dart API
dart:ffi library - Dart API
Is it possible to get pointer of Uint8List instead of allocating then copy · Issue #31 · dart-lang/ffi

DockerでSambaサーバーを立ててみます。

環境

• Chromebox Series 3
  • Wi-Fiアダプタを除去し、USB3.0アダプタ ¹に換装
  • システムドライブ: SunEastのmsata 128GB
    • Ubuntu 20.04
  • データドライブ: ADATA HV620

構築

dperson/samba　が有名らしいので、これを使います。

https://hub.docker.com/r/dperson/samba

dockerを入れていない場合は、好きな方法でインストールしてください。

sudo snap install docker

コンテナを作ります。

sudo docker create -it -p 139:139 -p 445:445 --name smbsrv -v 共有したいパス:/path1 dperson/samba \
            -p -r\
            -u "ユーザー名;パスワード" \
            -s "share;/path1;yes;no;no;ユーザー名" 

コンテナを起動させます。

sudo docker start smbsrv

うまくいけば、以下のようなログが表示されます。

# docker logs smbsrv
Added user ユーザー名.
smbd version 4.12.2 started.
Copyright Andrew Tridgell and the Samba Team 1992-2020
daemon_ready: daemon 'smbd' finished starting up and ready to serve connections

以下のメッセージは、オプションがおかしかったときに表示されます。
適切に書き直して、作り直してください。

The 'command' (if provided and valid) will be run instead of samba

docker createの部分について簡単な説明

• Docker自体のオプションはイメージ名「dperson/samba」より前に、dperson/sambaのオプションはイメージ名より後ろに書きます。
• -sオプションは、 「共有フォルダ名;Docker内のSambaのアクセス場所;browseableか（ネットワークコンピューターで表示をするか);readonlyか(読み取り専用か);guestか（ゲストユーザーを認めるか);アクセス可能なユーザーリスト(,区切り)」という意味です。
• Windowsでは、「\サーバーのIPアドレス\share」でアクセスできます。
• -r オプションはゴミ箱の無効化です

Windowsからのアクセス

ネットワークの場所の追加をして、ユーザー名とパスワードを入力するだけです。

その他

CrystalDiskMarkをやってみました。1ギガビットイーサネットです。

HDD

ext4でフォーマット済み。

SSD

ext4でフォーマット済み。

参考

https://www.atmarkit.co.jp/ait/articles/0005/22/news008.html

---

1. SATA電源が必要です。USB給電のケーブルを使いました。 ↩

はじめに

• Linuxの学習を進めていきたい初学者です
• 時短になりそうなショートカットを、手を動かして確認するついでにメモしただけの記事です
• よくばらずに、絶対使える！ってやつを押さえていきたいです

画面すっきり系

• control + c

  • 実行中のコマンドを強制終了する

• control + l

  • 画面をクリアに出来る
  • ログが溜まって、すっきりしたい時に使える
  • 厳密には、入力待ちの行が一番上に来てるだけ

カーソル移動系

矢印キーまで手を動かさなくて済む

• control + a
  • 行の先頭に移動する
  • atama(頭), アルファベットの先頭
• control + e
  • 行の最後に移動する
  • end
• control + f
  • 一文字進む
  • forward
• control + b
  • 一文字戻る
  • back
• esc + f
  • 一単語次へ進む
• esc + b
  • 一単語手前へ戻る

編集

一文字削除

• control + h
  • backspaceの代わり
  • hidari
• control + d
  • deleteの代わり

一気に削除

• control + u
  • 行頭まで削除する
• control + k
  • 行末まで削除する
• control + w
  • 手前にある単語を削除する
  • word
• control + y
  • 最後に削除した内容を挿入
  • 切り取り→貼り付けで使える？

履歴

矢印キー使わなくても良くなる

• control + p
  • 一つ前のコマンドを表示
  • previous
• control + n
  • 次のコマンドを表示

まとめ

• 随時追記予定です（検索系などは、まだ使う機会が少ないので）
• とりあえず矢印キーは封印します。

参考資料

こちらのUdemy講座で紹介されたものを参考にさせて頂きました。
もう怖くないLinuxコマンド。手を動かしながらLinuxコマンドラインを5日間で身に付けよう