那覇レポート

こんな残念な記事を書くことになるとは思いませんでしたが... TLTR; grubに入れない環境ではpreupgradeコマンドの次に進めない 前回 触れたように fedora 9〜16では、次のバージョンにアップグレード(アップデート？)するために、 preupgradeコマンドが使えます、というよりそれが推奨されています。 fedora 16で具体的にやってみると(前回の繰り返しですが) yum clean all yum update yum upgrade yum install preupgrade preupgrade-cli "Fedora 17 (Beefy Miracle)"  curl "http://mirrors.fedoraproject.org/mirrorlist?path=pub/archive/fedora/linux/releases/17/Fedora/i386/os/" > /var/cache/yum/preupgrade/mirrorlist.txt preupgrade-cli "Fedora 17 (Beefy Miracle)"  ここで grep ^menuentry /boot/grub2/grub.cfg とすると一番上に「Upgrade to Fedora 17」みたいな名前が出てきます。 次回はgrubでこの一番上を選択したいので、 以下コマンドを実行します grub2-set-default 0 これでrebootすると、 grep ^menuentry /boot/grub2/grub.cfg の一番上が起動する...はずなのですが、実際は2番目が起動し、 いつまでもアップグレードタスクは動きません。 このようにリモートではupgradeはできず、マシンの前でgrubを選択しないとなのです... ここまで書いてあるのはsshやtelnetでしかアクセスできない場合の話です。 最近のサーバや、クラウド上のサーバなら画面へのリモートコンソール接続ができるので、 こういうことはないと思います。 参考サイト http://enakai00....

未だにfedora 16(2011年リリース。しかもi386..32bitです)が動いているサーバーがありました。 セキュリティ的にこれはなんとかしないとな...と思い、 ひとまず仮想環境にテスト環境を作り、 最新版のfedoraにアップグレードできるかを検証し始めたのが事の始まりでした。 [検証したかったこと] (1)ちゃんとアップグレードできるか (2)マシンは遠隔地にあるので、ネットワークアクセス越しでできるか という項目でした。 先に言ってしまうと、多分無理でしょう。 grub(OS起動前)でアップグレードを選択する必要があるので(2)は満たせず、 そもそも僕が試した環境ではアップグレード用カーネルさえも出てきてくれませんでした... それだけでなく、そもそもfedora16にまともにネットワークアクセスできなかったことが大きな障壁になりました。 2018年にこんなネタを書いても誰の役にも立ちませんが、 記録として残そうと思います。 [検証の手順] 参考にしたのは以下サイトです。 http://q.hatena.ne.jp/1488282957 コメント欄？の「自己解決しそうです〜」に手順が書いてあります。 コマンドだけ列挙すると yum clean all yum update yum upgrade yum install preupgrade preupgrade-cli "Fedora 17 (Beefy Miracle)"  curl "http://mirrors.fedoraproject.org/mirrorlist?path=pub/archive/fedora/linux/releases/17/Fedora/i386/os/" > /var/cache/yum/preupgrade/mirrorlist.txt preupgrade-cli "Fedora 17 (Beefy Miracle)"  これで再起動すると、 fedora 17用のアップグレードカーネルがgrubで選択できるようになり、 それを選択することでfedora 17へのアップグレード処理が始まります。 fedora 1...

昨日とあるデリのお惣菜屋さんに行きました。 人気店なのか、隣の店の前まで続く列。 別にお惣菜の在庫が出来上がらないから並ぶわけではありません。お惣菜を選んで、それをパックしてお会計を一人ずつやっており、そのスピードが遅いのです。 こういう時思うのは、人の仕事のどこまでが機械で自動化できるのかということです。 人工知能分野の人は言います。将来、現在の数割の仕事を機械がやるようになる、と。 彼らは基本、単純作業は機械で置き換え可能という理論を出してきます。 しかしそれは、作業のインプットやアウトプットが電子化できるのが暗黙の前提で、モノの移動が伴う業務の事を考えていないようです。 amazonオリジナルドラマのパトリオットのセリフであるのですが「物をある地点から他の地点に移動することはとても難しい」のです。 またamazonですが、amazon goという無人店舗の取り組みをしています。 最初に述べた小売店の販売時省力化にはつながるでしょうけど、製品を搬入したり陳列したりするのは、機械には難しそうです。 また、amazonのネット販売の小売業態も、製品の入荷、管理、発送、家までの配送と、ずっと人手が必要なのがお分かりかと思います。 まとめると、人工知能技術で人が頭で「単純な判断」している事は置き換えられるのかもしれませんが、世の中の単純労働の大半は置き換えの見通しすらたっていないという感じでしょうか。

ラップトップというか、ノートPCの新モデルの多くが、2 in 1...つまりキーボードとディスプレイが分離できるモデルになっています。 そんなに人気なのかな？と思って、2-in-1のシェアを調べてみると、なんとどこにも載っていません。 なんですかこれは... 価格コムなんかでみると、値下げ幅が大きく、2in1が安くなっているのはよく見かけます。 まぁ安いのは単に2in1の中には昔ネットブックと呼ばれていたような、 画面が小さくCPUがintel ATOMのような廉価なモデルが多い影響もありますが。 そもそもwindowsはタブレットとして使われるシーンはあまりないと考えています。 保険営業マンなど、訪問営業系の方はよく持っていますが、 タブレットといえば、iPadがデファクトスタンダードになったのは何年も前の話です。 ではなんで、各メーカーがこぞって2in1を出しているのか... それは大人気シリーズMicrosoft Surfaceが2in1だったことに由来すると考えています。 Surface売れてるから、俺たちも2in1だそうぜ、という考えでしょう。 しかしこれは大きく間違っていて、みんなは2in1がほしくてSurfaceを買っているのではないのです。 他のメーカーのPCがゴミしかないので、フラッグシップSurfaceを買っていたわけです。 まぁそもそもPC所有率は下がっていて、特に20代30代は2015年をピークにただ下がりだそうです。 2in1がどうの言っている場合ではなく、PC業界が死んでいくわけですね...

アパート(マンション?)に住んでいますが、 冬の窓際の寒さは格別です。 過去に下記のようなプチプチを窓に貼るようなシート(フィルム?) または、窓の下に置くようなボード と試してきましたが、これがどうも効果が ありません 。 (もしかすると後述のカーテンによる断熱を既に実施済みだからかも...) まず「結露が防げる」とのことですが、防げません。 確かにシートの家の中側はぬれませんが、シートの窓側(接着面)はびしょびしょです。 またサッシ部分もびしょびしょ。 上記シートやボードは、空気の層を作って寒さを防いでくれるという理論はわかります。 しかしそれほど効果が感じられないのが実感でした。 外観が最悪なので、すでにどちらもはがして現在使っていません。 実はウチはそもそもカーテンでの寒さ対策をしています。 カーテンを買う時に ・分厚く ・丈が長い(引きずるくらい) ものを選んでいます。 それでふと思ったのですが... こういうプラスチック？ビニール？製のカーテン って、冷凍倉庫の入り口にも使われていたりするので結構効果あるかもですね。 今度試してみます。

タイトルそのままです。 2010年？くらいからdockerやら色々な仮想化技術が発展してきて、 macやwindowsでLinux動かしたいときは、 もうvirtualboxとかvmwareとかparallelsとか使わない方がいいんだろうなあ... と思うようになりました。 後者御三家は「ホスト型仮想化」と呼ばれ、 OSの上に仮想のハードウェアを作ってその上で別のOSを動かすわけでして、 非常にオーバーヘッドが大きいです。 最近人気のdockerは「コンテナ型仮想化」と呼ばれ、ホスト型よりオーバーヘッドが小さいです。 まあ、docker for windows/docker for macの場合は、 非Linuxプラットフォーム上でLinuxカーネルを動かす？ような作りなので、 docker on Linuxよりはオーバヘッドは大きいと思います。 しかし、流石にホスト型よりは(構造上)軽いです。 と、こういう流れだと「ではdocker for macの使い方」となりそうですが、 実は僕のポンコツmacbook airは、docker for macの必要要件メモリ4GB以上を満たしていません。 つまり使えないんですね。ハイ。 で、もう一つの仮想化技術としてOSが用意しているものがあります。 例えばLinux KVMとかwindowsのHyperVとか、 macOS Yosemiteから採用されたHypervisor.frameworkです。 docker for macは内部でHypervisor.frameworkを使っています。 で、xhyveを使うとHypervisor.frameworkを利用できるとのことですので、macでdockerでubuntuを動かせるようにしてみます。 0. コマンドラインツールのインストール https://nahareport.blogspot.jp/2017/10/iosxcode.html こちらを参考にどうぞ 1. xhyveのインストール https://github.com/mist64/xhyve からgit cloneするか、zipをダウンロードしてきて解凍します cd xhyve  #ディレクトリに移動 make sudo cp b...