Docker Part2©2ch.net

LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker
http://mao.2ch.net/test/read.cgi/linux/1374861492/

>>563
なるほど。
そのうちDockerホスト専用のディス鳥がでるかもね

そんなもんとっくの昔からあるよ
で最近になってKVMの上でコンテナ動かすのがバズってきたのは、AWSがコンテナ専用の "KVMホスト" OSをリリースしたことに端を発している
これは小数の大きな仮想マシンでクラスタを組んでその上で沢山のコンテナを動かすという従来のやり方とは考え方が大きく違っていて、
コンテナの数だけKVM上で軽量なVMを立ち上げてその中でコンテナを隔離して動かすの
でコンテナは本当に単なるパッケージ化技術と成り下がる
コンテナによる分離はセキュリティ面でガバガバであり使い物にならない玩具である、というのがITビジネス界の結論というわけ

> というのがITビジネス界の結論というわけ

という結論を語ってる所はITビジネス界には無いんで
安心して、生暖かく見てやってくださいｗ

コンテナごとにセキュリティソフト入れてますます重くなる未来

そういや仮想マシンごとにセキュリティソフト買ってるらしいな

パッケージソフトをウッキウキでクラウドで動かそうとしたら、
ライセンスがコピー単位でオンプレと何ら変わらない運用をするしかないというのはよくある話

だからソフトウェア自体を売るんじゃなくて
クラウドサービスとして売る方向になってるのでは？

そしてそれにはコンテナが適してるわけだよね

>>565
>パッケージ化技術と成り下がる

いいたい事はわかるが、成り下がってはないと思う。

>>570
自分で構築、保守してこそのコンテナの有難味だと思う

だからDockerはアプリ開発者が
自分のアプリを配布するのに使うものなんだよ

アプリ開発してないやつにとっては豚に真珠

>>574
えー俺にも技術分けて下さいよ
dockerでドヤ顔したい

仮想化環境であるが、仮想マシンではない。
仮想化環境であるが、アプリではない。
dockerはコンテナ型の仮想化環境を作成するソフトです。
それ以上でもそれ以下でもないだろ。

>>576
アプリの組み合わせ（=環境）をコンテナにまとめるのもありですよね
その場合、127.0.0.1で内部でアプリを連携させるのも良いですよね。

>>577
そうそう、VMみたいにして使うときは目的に合わせてカスタムすればいい。
目的を定めて既存のサービスに組み合わせてdockerファイルを書く。
例えば開発環境にするなら同期をとファイル群をローカルネットワークのgitにするとかね。
dockerはクラウドと連携すると割と柔軟に何でもできる。
環境依存のファイルをクラウドに置いておく発想で。

dockerは本来はアイソレーションやシステムリソース有効活用も担ってたはずでしょ
例のFirecracker的な思想だとそこはコンテナから切り離そうってことだよね
ここまでくると仮想化環境というより単なるポータブルなVMのディスクイメージと考えたほうが素直だと思うわ

>>579
いや、環境だよ。どのPCでも同じ環境を再現できるってこと。javaの発想に近い。
静的なファイルだけ突っ込むってとこはいい理解だけど、それが環境なんだよ。

dockerfileって環境構築用のバッチファイルみたいなものだと理解しても良い？

コンテナのコンソールを使って順に環境構築したものをコミットしてイメージ作る場合と比べてどんなメリットがあるかな。
仕上がりのイメージファイルの容量が少なくなったりする？

>>581
chrootに依存してるって意味なら同じだろうけど、ディストリのパッケージに依存してるからそれが違うかな。
コマンド手打ちでも構築できるけど、不便だろ。

マイクロVMが主流になるならもうコンテナいらなくね？
カーネルだけホストのものを使うことって無駄な環境依存を増やしてるだけで、従来のコンテナ技術との互換性以外にはもはやメリットがないような
環境依存部分を吸収するのはそれこそ本質的にはハイパーバイザー型仮想化の方が遥かに得意なわけだし

そういうの解決するために各企業が新しいコンテナ技術生み出してる
gvisorみたいにコンテナとVMの中間みたいな物とかね

KataContainersもgvisorと似たような思想だな
やり方はだいぶ違うみたいだが

コンテナ型仮想化は初詮は捻じ曲がった過渡期のワークアラウンドだったってことだな
VMが重いのが問題なら軽くすればよい、それができないのは技術が未熟だっただけ
浸透し切る前に正しい方向に戻ってくれそうでよかった

>>582
dockerfile作る時も手打では？
しかもレスポンスが直ちに得られないので、
試行錯誤に時間がかかりそうに思う。

いまば、プログラム買いてその場で実行できるBASICインタプリタと、
cコンパイラを通す必要のあるC言語みたいな違いがあると思うんだけど。
一度完璧に書いてしまえば、後者の方がいいに決まっているけどね。

>>583
各VMごとにOSレベルのメモリ割り当てがいるから、
大量のメモリを消費するのでは？

コンテナを動かすためのサーバーを管理したくないけど
AWS Fargateはまだまだ高い

Lambdaで無理やりやるとか
つか安ければイイならSpotFleet以外の選択肢が（ｒｙ

Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある

CRIだよね？>ORI

>>588
firecrackerの場合1VMあたり5MBらしい。

>>587
あー、そういう見方あるか。chroot手打ちしなくていいってことだよ。
言いたいことはjvmとlinuxカーネルが実行環境に含まれてるってことよ。
linux環境じゃなくてもdockerは公式環境があるから。

>>591
やっとdocker-composeわかりかけて
きたとこなのに(>_<)

>>595
いやいや、docker理解できないと使えないから安心して
そもそも、個人開発でkuburnetes必要なくない？

なんで個人開発限定？
そもそも個人開発でdockerなんか何に使うの？
コンテナ仮想化って個別にインフラを面倒見れないほどアプリがポコポコ作られるような組織で使うもんだろ
PaaSへのデプロイに使うくらいか？

>>591
> Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある

KubernetsってDockerを使うんだけど、なんで役割終えたの？

>583
> マイクロVMが主流になるならもうコンテナいらなくね？

またいつもの仮想マシンとアプリケーションコンテナをごっちゃにしてるやつだなw

マイクロVMが主流になったとして、じゃあどうやってこそにアプリをデプロイするんだ？
マイクロVMにRailsの実行環境入れ込むんか？
ローカルの開発マシンで動いているものを、そのままマイクロVMで動かすにはどうするんだ？
そういった問題が解決できてないだろ

コンテナは仮想マシンと組みあわせて使うということが全くわかってない
コンテナがあるからこそ、VMはマイクロで十分になったというのに
コンテナのおかげやで？マイクロVMが登場したのは

>>581
> コンテナのコンソールを使って順に環境構築したものをコミットしてイメージ作る場合と比べてどんなメリットがあるかな。

依存パッケージの更新とか手動でやりたくなくないだろ
お前は旧式のやり方しかしてないかもしれんがな、
こちとらDockerfileで1日に何度もイメージをビルドしてるんや
アプリが更新するたびにイメージ作り直してるし
カーネルや依存パッケージにセキュリティ対応が入ったら、
それを取り入れてまたアプリのイメージを作り直すんだよ

>>586
> コンテナ型仮想化は初詮は捻じ曲がった過渡期のワークアラウンドだったってことだな

マイクロVMがなにをそぎ落としてるのか知らんの？
様々なコマンドが入ってないんだが。
各言語の実行環境はもちろんのことpsコマンドすら入ってないだろうな
マイクロVMではサーバーは起動していない。NFSサーバーになる機能すらないだろう
パッケージマネージャーもないだろう。必要ないからね

マイクロVMはDockerコンテナを動かすのに必要な
最小限の機能まで縮小しているし、Dockerコンテナを動かすこと以外を
やることを想定してないから、単体では何も使えない

それわかってるのか？

>>599
君こそコンテナ仮想化とパッケージとしてのコンテナを混同してない？
>>583は前者のことを言っていて、従来のLinuxカーネルを共有したハック(現在一般的にコンテナ仮想化と呼ばれるもの)がもはや役割を終えつつあるのは事実だ
一方でパッケージとしてのコンテナはもちろん必要だけど、それ自体はもはや仮想化技術でも何でもなく、文字通り単なるアーカイブだ

>>602
> それ自体はもはや仮想化技術でも何でもなく

「仮想化技術ではない」というのは具体的に
何ができないっていってんの？

それをお前が言えば、お前が間違ってることがはっきりするよ

「仮想化」という言葉の正しい意味をわかってないやつは、
仮想メモリと聞くと、ソフトウェアでメモリを作ることだって勘違いするからな
>>602はそのパターン

パッケージとしてのコンテナとか意味不明だし
仮想化しなければ、可搬性は実現できないだろうが
仮想化せずにどうやって、他のマシンで動かすことができるというのか

っていっても理解できないんだろうなw

>>583
> マイクロVMが主流になるならもうコンテナいらなくね？

apt-getもyumもついてこないよ
systemdも入ってないよ
libなんたらパッケージも入ってないよ
例えばnginxを動かそうと思っても、パッケージないし
パッケージの依存関係を解決してくれたりしないよ

コンテナ使わないでどうやってサービス動かす気？
苦労する気？

だからパッケージングとしてのコンテナを否定してるわけじゃないんだけど、そんなに難しいこと言ってるかなあ
少なくともマイクロVMでコンテナを実行するのは従来の定義上はコンテナ仮想化とは呼べないでしょ
そして、せっかくマイクロVMによって遥かに高度な仮想化が実現可能になったのに、
依然としてホストのカーネルを使っていたのでは可搬性はdockerと同程度の低い水準のままだ
従来のコンテナ仮想化の仕組みを大きく見直す時期に来てるんだよ

>>599
マイクロVMって普通の仮想マシンとどう違うの？
>>593
OSは入れなくていいのか？

>>607
> 少なくともマイクロVMでコンテナを実行するのは従来の定義上はコンテナ仮想化とは呼べないでしょ
呼べるんだけど？

仮想化したコンテナを動かしてるんだから
コンテナ仮想化に決まってる

仮想化しなかったら、その仮想マシンでしか動かないものになるんだけど？
やっぱり仮想化の意味を知らないようだね

>>608
> http://www.atmarkit.co.jp/ait/articles/1811/27/news146.html
ここに簡潔に書いてある

> Firecrackerは最低限の機能だけを搭載したマイクロVM
> 　FirecrackerはKVM上で動作。その上で動くコンテナなどのために、
> ネットワーク／ストレージを中心としたシンプルなI/Oインタフェースを提供する。


> OSは入れなくていいのか？
通常のディストリではカーネルとユーザーランドを含めてOSとなるのだが
マイクロVMはカーネル（とメンテナンス用のわずかなツール）のみの提供と考えていい。

コンテナを動かすことしかしないのだから、
マイクロVMに（コンテナ以外）のものを入れる必要がない
逆に言えば、コンテナ以外を動かすのは不可能に近い。

>>607
> そして、せっかくマイクロVMによって遥かに高度な仮想化が実現可能になったのに、
> 依然としてホストのカーネルを使っていたのでは可搬性はdockerと同程度の低い水準のままだ

意味不明。マイクロVMはKVM（仮想マシンエミュレータ）で動く
コンテナ専用のディストリの一種に過ぎない

マイクロVMのカーネル＝ホストのカーネル
マイクロVM上のコンテナ＝マイクロVMのカーネルを使う

どちらも同じカーネルを使うことにななってるんだが？

ホストのカーネルってなんだよ？

マイクロVMは可搬性が高いわけじゃない
これは単なるディストリの過ぎないんだから

マイクロVMを他のPCで動かそうと思ったら
仮想マシンエミュレータが必要になる

Dockerコンテナは仮想化されてるから、
マイクロVMでも通常のLinuxでも動かすことができる。
コンテナ（＝アプリ）が仮想化されてるから、
例えばローカルのLinuxマシンで複数のコンテナを起動することだってできる
そしてそのコンテナをそのまま変更せずに、マイクロVMで動かすこともできる。
"コンテナをそのまま変更せずに" ってところが重要。

マイクロVMで動かす時は、ポート番号を変更したり、
CPUの割り当て数を変更したりできる
"コンテナをそのまま変更せずに"
これができるのは、"仮想化されている"から

>>607は仮想化をプロセス分離の技術の名前だとでも思っているかのようだw

"メモリの"仮想化は、ハードウェアのメモリをエミュレータで
エミュレートするものでもないし、プロセス分離の技術でもない
メモリの仮想化は物理的なメモリ配置を隠して、どういうハードウェアでも同じように見せることを言う

もちろん"PCの"仮想化はハードウェアをソフトウェアでエミュレートすること
同じ仮想化でも、"何の"仮想化であるかで意味が違う。

マイクロVMというのはディストリの名前なので何も仮想化してない
仮想化しているのはエミュレータ（KVM）の方
もちろんこの場合の仮想化とは"PCの"仮想化

そして（Dockerの）コンテナが提供するのは、アプリケーション実行環境の仮想化

UbuntuでもマイクロVMでもCentOSでも同じLinuxであれば
どこでも同じように動かせるようにするアプリケーション実行環境の仮想化は
コンテナが提供している。このアプリケーションの仮想化がなければ
ディストリごとに専用に、セットアップ手順を書かないといけない、
aptを使ったりyumを使ったり。コンテナでアプリケーション実行環境の仮想化を手に入れたことで
Dockerを使うだけで簡単にコンテナを動かせるようになった。
そうすることで、ディストリ専用（例マイクロVM専用）のセットアップ手順を
作らなくて良くなったからこそ、マイクロVMという軽量のディストリができたんだよ

>>598
KubernetsでDockerは使えるけど必須ではなくなったからな
将来的には使われなくなるでしょ

VM+カーネルの上でコンテナ(アプリケーション+ユーザーランド)が動くような形になっていくのかな。

>>615
マイクロVMが一般的になれば次第にカーネルはコンテナ側に寄っていく形になるよ
VMベースの仮想化に移行すれば、特殊なバージョンのカーネルやLinux以外のコンテナを動かそうという試みはビジネスの要請によって確実に出てくる
ちょうど言語処理系が辿った道と同じで、最初は完全にホスト側によって使用するランタイムが決められていたのが
アプリ側の設定ファイルに基いてランタイムを選択するようになり、最終的にはアプリケーションに吸収される

そんな銀の弾丸があるなら
もっとAWS Fargateを安くしろや！

めんどくさいから結論が出て使いやすいソリューションが出てきたらでいいや

まーたいつものガイジ2匹がレスバ繰り返してたのかよ
よく飽きねぇなぁ

>>614
知ってる知ってる。rktとかいうやつな
あれどうなったんだ？w

結局、Docker以外も使えると言う状況に満足して
終わりなんだよ。本気出してないからDocker以外普及しない

>>615

> VM+カーネルの上でコンテナ(アプリケーション+ユーザーランド)が動くような形になっていくのかな。

そういうこと、マイクロVMは何かの機能を搭載するのではなく
コンテナに任せることで限りなく機能を削減する方向を目指してる。

だからマイクロVMがコンテナになることはありえない。
マイクロVMはコンテナを使うという前提

>>616って結局コンテナを使いますって言ってるだけだよ。
マイクロVM関係ない。だってマイクロじゃないVMでもできることなんだから
マイクロVMは単に今のVMを置き換えるもので軽いってだけでしかない。

それ以外は今と全く変わないわけだから、コンテナ使いますよねって話

「Kubernetes」に深刻な脆弱性
https://japan.zdnet.com/article/35129584/
> この脆弱性は深刻なものであり、共通脆弱性評価システム（CVSS）による深刻度は9.8（最大値は10.0）となっている。

dockerの特色はリソースを節約しつつ環境を切り分けて管理しやすくするってことだから
docker動かすだけの鯖やVMならカーネルだけ乗っててdockerの依存関係だけインスコできるパッケージがあればいいって発想から
ディストリとかvmも小さいものや、専用のものを使いましょうってだけの話だろ。
リソースを気にしなくてすむのなら普通のlinux鯖で動かせばいい。

>>620
rktは違うわ

>>624
それな。WinnyとかP2P世代のバカは仮想マシンを
「ウイルスに感染しても安全」な技術だと思ってる。（もちろん間違い）
ここで仮想化をセキュリティのためのものと思ってる奴がそうだろう

仮想マシン（VM）と仮想化は別のもの
仮想マシンは"ハードウェアを"仮想化したもの
コンテナはハードウェアを仮想化してないので、明らかに違うものを仮想化してるんだが
仮想マシンで仮想化してるから、コンテナで仮想化する意味がないという理屈のようだ

マルチテナントを考慮せよ
やり直し

>>626
お前も、Docker世代のバカと呼ばれるんだろうな

>>626
さすがに頭悪すぎ
どんなハッカーやウィルスをもってしても、VM内から同一ホスト上の別の客のVMに正当な方法を介さずにアクセスできてはならない
これがAWSが仮想化技術に対して要求する最低限のセキュリティだよ
クラウドベンダー各社がDockerをサポートし始めてもなかなかFargateのようなサーバーレスサービスが出なかった理由もそこにある
つまり、Dockerだけでは従来のハイパーバイザー型仮想化と同等の分離水準を実現できなかったんだよ
FaaSやCaaSの先駆者であるAWSがマイクロVMを必要としたのはそういう背景がある

>どんなハッカーやウィルスをもってしても、VM内から同一ホスト上の別の客のVMに正当な方法を介さずにアクセスできてはならない
こういうのまるっとガン無視して犬糞の鳥間バージョン間各種パッチ適用ごとの糞そのものの互換性のなさを
思考停止してとりまお気楽極楽に乗り越えて便利に使いましょいっていうのがドッカー（）だと思ってたんだがｗ

>FaaSやCaaSの先駆者であるAWSがマイクロVMを必要
どこまでいっても業者のツゴーってコトだよなｗｗｗ

>>631
企業内の専有クラスタでもコンテナが乗っ取られたときの影響範囲とか部門間のアクセス制御とかあるからね
ｳｪｰｲwww系Webからビジネスへと足を踏み入れた途端に、Docker世代のバカには想像もできない複雑で広大な世界が広がっている

頭の悪さは

> つまり、Dockerだけでは従来のハイパーバイザー型仮想化と同等の分離水準を実現できなかったんだよ

この一文に集約されてる。

Dockerはもともとハイパーバイザー型仮想化と同等の分離水準を
実現するためのものではない。それがわかってないと自白したようなもんだ

それからもう一つ言うと、コンテナ間の分離機能というのは
カーネルが搭載しているコンテナの機能を使ってるだけなので
Dockerの問題じゃないんだわ。カーネルの問題

最初から俺が言ってるように「Dockerは仮想マシンと組み合わせて使うもの」
なんだから、そういう分離は仮想マシンでやるからいいんだよ。

DockerはDockerの本質であるアプリケーション実行環境の仮想化に
特化すれば良い。こればかりは仮想マシンでは実現できないんだから。

結局いつもの、Dockerを理解してない or 仮想マシンの代わりだと思ってる
理解の浅いやつが叫んでるだけでしたね。

>>632
solarisはdockerやるって言ってたけど今のところ見送りだからな
流石に長くOSやってるトコロはセキュリティに関する意識が全然違う
>>633
>Dockerはもともとハイパーバイザー型仮想化と同等の分離水準を
>実現するためのものではない。
ありとあらゆるトコロに地雷のように埋まってる腐れOSSの非互換性を解決するための
単なるお遊びレベルのコンテナシェア取り合戦なんだよなｗ
分かる分かるｗｗ
>>634
>カーネルが搭載しているコンテナの機能を使ってるだけなので
>Dockerの問題じゃないんだわ。カーネルの問題

いやいやいや下のレイヤに何を選ぶかはドッカ〜の実装の問題だろｗ
カーネルの責任に転嫁するのはさすがに無責任極まりないｗｗｗ
まぁOSS界隈のやり取りらしくて大変結構なんだがｗｗｗ

>>637
だから下のレイヤー（コンテナ機能）に問題があるってことですよねw

Linuxカーネル標準のコンテナ機能以外に
コンテナってありましたっけ？
それともDockerが選んだLinuxに問題があると言いたいのかな？w

Solarisはもう未来ないから・・・

米オラクルがSolaris関連の従業員をほぼ全員レイオフしたとの報道（追記あり）
https://www.publickey1.jp/blog/17/solaris.html

>>638
分離したいなら仮想マシン使えは現状そうするしかないんだが
>FaaSやCaaSの先駆者であるAWSがマイクロVMを必要としたのはそういう背景がある
何度も言うように業者のツゴーでそう言ってるバヤイじゃないってコトだろ
課金も絡むだろうからクラウド（）に縛られてる情弱貧乏ユーザーどもにとっても死活問題だろうし
>>638>>639
>Dockerが選んだLinuxに問題があると言いたいのかな
問題アリアリだからドッカ〜が必要になったんだろｗｗｗ
つかソコをトボケてどうしたいのさ
犬糞ageっすか？ｗ

>>640
安価なゴミ産廃で置き換えられていくのがITの歴史そのものだからやむを得んだろうな
まぁ今でもボラクルだけではなく不治痛からも買えるのでレガシーユーザーは困らん>solaris

つかドッカーのコンテナランタイムってドッカーさんちの自作ちゃうの？

>>641
だからさ、なんで分離するとか言う話してんの？

Dockerは分離するためのものじゃないんだが？
やっぱりわかってないよね

>>641
> 問題アリアリだからドッカ〜が必要になったんだろｗｗｗ

違うよ？ やっぱりわかってないね。お前の書き込みが証拠だよ。

仮想マシンとか分離の話なんか一言も出てこないからさw

「コンテナはデプロイと運用を再発明する」、レッドハットがコンテナ戦略を説明
https://cloud.watch.impress.co.jp/docs/news/1013903.html

　Dockerは、アプリケーション単位でコンテナを作ってパッケージ化する技術だ。
アプリケーションに状態を持たせずにスケールさせるクラウドネィテイブな手法や、
1つのシステムを単機能のサービスの組合せで作るマイクロサービス、
開発・デプロイ・運用のサイクルを早くまわすDevOpsといった、
新しい方式と特に相性がいいと言われている。

　アプリケーションをコンテナ化する価値として岡下氏は、アプリのデプロイと
運用に統一手法がとれ、シンプルにできることを挙げた。

>>642
> 安価なゴミ産廃で置き換えられていくのがITの歴史そのものだからやむを得んだろうな

その理屈で言うとSolarisもその「安価なゴミ産廃」として
作られたものですからねw
いままでSolarisというゴミ産廃に置き換えられていった。

えぇ、お前の理屈だとそうなるって話です。

>>643を読む限りコンテナランタイムの機能もどうせわかってないんだろうな
プロセスの分離とかをしてるのはコンテナランタイムではない
カーネルの機能を呼び出しているだけ

>>644
だから業者のツゴーだって言ってるじゃん
客がソレに全力で振り回されてる状況なんだが
まぁ尼損は今のところ王様の商売やってんなとは思うね
>>645
少なくとも数ある商用UNIXにはドッカーみたいなゴミはどこにも存在しない
犬糞のお陰で今までなかった問題が発生したのでそれを解決するやむを得ない戯術偽術の類だよ
>>647
>その理屈で言うとSolarisもその「安価なゴミ産廃」として
>作られたものですからねw
そらそうよｗ
ただ犬糞よりは断然筋がイイ
出自を見れば分かるだろ
>>644
>プロセスの分離とかをしてるのはコンテナランタイムではない
そりゃそーだろ
つかドッカーで全部のプロセスがルート扱いで動いちゃってるのはカーネルの責任！とかいう言い分かよｗ

> つかドッカーで全部のプロセスがルート扱いで動いちゃってるのはカーネルの責任！とかいう言い分かよｗ

普通に実行ユーザーを指定すればそのユーザーでコンテナが動作しますが？

どーせソコまで安全側に倒しておかずに動かすこと優先でやってんだろ
ルートでは動かないように小細工されてるツールだけやむを得ず一般ユーザーで動かすとかさぁ
動いたらハイ！終わり！ｗ
コレが一般的なデブオプス（）のスタイルだろ

>>649
> そらそうよｗ
> ただ犬糞よりは断然筋がイイ

Solarisはクソでした。あなたの理屈通りでした。
でもあんたの理屈は、あんたには適用されるが、
俺には適用されない。LinuxよりもSolarisはクソ

>>649
> だから業者のツゴーだって言ってるじゃん
> 客がソレに全力で振り回されてる状況なんだが

お前が振り回されてるのはわかったが、
俺は別に振り回されてない。

Solarisの先行きが不安定なのに焦ってるのか？

>LinuxよりもSolarisはクソ
まぁその気持ちも分からんではないね
初心者ほどとっつきやすいモノがよく見える
デパートで売ってる服よかユニクロの服の方が好きなタイプだろ？ｗ

>>651
お前が適当な知識でやってるから、
それしかできないと思ってるのでは？w

>>654
いいものが好きなんでLinuxが好きなんですよ。それだけです。
言われてみれば服もブランドに限らずいいものが好きだし、それと同じなんだろうな。

>>653
>Solarisの先行きが不安定なのに焦ってるのか？
ソコも業者のツゴーゆえ割り切らざるを得ない
筋の悪いドッカーも犬糞とクラウド延命のための一環だ
精々頑張ってくれｗ

Solarisでびっくりしたのがようやく11になってから
ksh93が標準になったこと

それまでksh88やそれよりも古いBourne Shellがデフォルト
今2018年やで1988年って

>>675
お前大変やな。
全部業者に依存してるからそうなるんやで

>>656
イイモノじゃなくて道に落ちてる出所不明なモノを拾い食いして
腹に当たったか平気だったかレポしてるのに近いなと思うねｗ
まぁコレはOSS全般に言えることだけどな
多数が狂ってればマトモな感覚のヤツがキチガイ扱いされても当然ではある

業者の都合でLinux導入できないんだよ。でもそれがいいんだよ。
クラウドも導入できないんだよ。でもそのほうがいいんだよ
あのぶどうは酸っぱくてまずいんだよ

こんなところかね

>>658
フツーにユーザー作ったら標準でbashが動いたと思ったけど>solaris 11.4
今useradd試してみたけど間違いなく/usr/bin/bashが入ってきた
つかユーザーが過去に書いたスクリプトの互換性まで考えれば
下手にシステム付属のシェルは弄れない
>>659
オレに向けたレスか？ちょっと落ち着けよｗ
自分でコンテナ仮想化からOSカーネルまで全部書いてるのかね
凄い労力だなｗ
つかOSSの中身が業者がかりじゃないと思ってるとか何か純粋な人なんだなｗ

>>661
心配しなくても大丈夫
ちゃんと犬糞も使ってるからｗ
ただ檻に入れた上でごく限定的な用途でしか使う気しねえけどな