NetBSD Advent Calendar 2018 13日目の記事です。 今日はNetBSDのカーネルビルド環境を手早く用意する手順を紹介しようと思います。 NetBSD Advent Calendarを書いていると、実験用に手早くNetBSDのカーネルビルド環境が欲しくなる時があります。 NetBSDインストールは配布パッケージも小さいことから文字通りものの数分で仮想マシン上にインストールできてしまいます。そこにカーネルのビルド環境を構築すれば準備万端なのですが、その手順が手元のメモに埋もれていました。 そこで今日の記事では、自分の備忘録を兼ねたNetBSDカーネルビルド環境の構築手順になります。 ワンライナーでNetBSDのカーネルビルド環境構築 実際にカーネルビルド環境を構築するワンライナーは以下になります。これをNetBSD環境上でrootとして実行して数分待つと、カーネルビル
この記事は、 NetBSD Advent Calendar 2018の20日目の記事です。 はじめに MIPSの 命令セットアーキテクチャーと実装が オープンソースになるような時代が来るとは思っていませんでした。 これもRISC-Vへの期待に影響があるのかもしれません。 Chiselと言うハードウェア記述言語は、そのRISC-Vの代表的な実装である Rocket chip の多くの部分を書くのに使われているものです。 今回は、Rocket chipは大規模過ぎるので、Chiselのチュートリアルである Chisel TutorialsのChiselコードをVerilogに変換して、 verilatorでのシミュレーション実行もしてみたいと思います。 私はこれからChiselで書いてみたい回路があるのですが、 NetBSDで生活して良くあるのは、そもそも環境が整わない、整ったと思ったら誤作動
前提として、/bin/sh は、デフォルトでは、RHEL系の場合bashシェル、Debian系の場合dashシェルへのsymlinkになっています。この2つのシェルの挙動は細かいところで結構異なります。そもそもの思想として、dashシェルはPOSIX互換を目指す軽量なシェルであり、bashは拡張された高機能なシェル。なのでbash前提で書かれたシェルスクリプトがdashでは動かない、みたいなことはよくあります。そういう感じで困ることがままありますが今回もそういう話。 例えば % sh -c "sleep 100" のようなコマンドを実行した場合、呼び出し元の子プロセスが sh になり、その更に子プロセスが sleep になると直感的には思うでしょう。つまり以下のような具合。 . \_ sh -c sleep 100 \_ sleep 100 しかし、 sh の実体が bash である場合な
cmd.exe の引数の扱いがあまりにもカオスだったのでちょっと頑張って調べてみた。 本来ならここは公式の資料に当たるのが正しいアプローチだと思うけど、どうしても公式の資料が見つからなかったので、色々試して推測してみることに。 断片的な資料は見付けたけど、完全じゃない。一応URL貼っておく。Windows Server 2003 のヘルプだけど、恐らくそんなに変わらないと思う。 コマンド シェルの概要 コマンド リダイレクト演算子を使用する なので、以下で述べる内容は間違いを含む可能性があります。というか正確さは一切保証されないのであしからず。 検証方法 以下のような引数をただ表示するだけの簡単な C のプログラムを用意した。仮に args.exe とでもしておく。 #include <stdio.h> int main(int argc, char const* argv[]) { in
Mackerelプロダクトマネージャーの id:Songmu です。この記事は、Mackerel Advent Calendar 2018 の19日目の記事です。 さて、ご存知の通り、mackerel-agentのプラグイン実行やアクション実行はコマンドライン形式の文字列で記述します。例えば以下のような形です。 [plugin.metrics.accesslog] command = "mackerel-plugin-accesslog /etc/nginx/access.log" ターミナルで試したコマンドをそのままmackerel-agent.confに書けるのでわかりやすいですね。 コマンドの配列指定とそれのススメ 実は、この command ですが、文字列の他に配列で指定することも可能です。例えば以下のような具合です。 [plugin.metrics.accesslog] comm
この記事は Linux Advent Calendar 2018 の20日目の記事として書かれた. ここではLinux kerenlにおけるEFI Variableのコードをみていく. EFI Variableとは UEFIでは,EFI varibale(EFI変数)というものが存在する. これは不揮発性メモリ(NVRAM)に値が書き込まれるため, 電源を切っても値が失われることなく保存される. EFI Variableは起動時の起動の順番などが保存される. UEFIにはEFI Variablesへの読み書きを行うための機能が Runtime Servicesに存在する. このため後述するように,OSの起動後もEFI Variableが Runtime Servicesを通して利用可能となっている. 関連する関数は具体的には以下の4つである. GetVariables GetNextVar
あなたのシステムはきちんと動いていると言えますか? 本書は、システムのどの部分をどのように監視すべきか、また監視をどのように改善していくべきかについて解説する書籍です。 前半で監視のベストプラクティス、デザインパターン/アンチパターンを示して、監視の基本原則を詳しく説明し、後半でフロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティの各テーマで強力な監視の基盤を設計して実装するための方法を示します。 監視対象が変化し、システムアーキテクチャが進化する中で、従来から変わらない監視の基本を示しながら、時代に合った監視の実践を解説する本書は、監視についての理解を深めたいエンジニア必携の一冊です。日本語版では、松木雅幸(@songmu)氏による監視SaaSの導入や活用方法を付録として収録しています。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載して
マイクロソフト、Windows Sandbox発表。デスクトップアプリを分離した環境で安全に実行可能に Windows Sandboxはデスクトップアプリケーションを通常の環境とは分離された環境で安全に実行可能です。発表が行われたブログから説明を引用します。 At Microsoft we regularly encounter these situations, so we developed Windows Sandbox: an isolated, temporary, desktop environment where you can run untrusted software without the fear of lasting impact to your PC. Any software installed in Windows Sandbox stays only in
2018年12月19日に行われた「IVS2018 Winter Kanazawa」のセッション「IVS DOJO」で、さくらインターネット株式会社・田中邦裕氏が登壇。27歳で会社を上場させたという輝かしい記録の裏には、数々の失敗があったと語る田中氏。傾いた会社を立て直すに至ったきっかけとはなんだったのか。心がけた“3つの心持ち”について、その意味を明らかにします。 ロボットで生計を立てることを夢見ていた学生時代 田中邦裕氏:みなさん、こんにちは。 さっきまで(の登壇者が)たくさんお話しされてたので、このあとどう繋ごうか大変心配しておりまして。3人目まではまじめなセッションで、4人目(の私)から笑いのセッションだということなんですけれども……この会場を見る限り、笑う雰囲気がまったくしなくて、大変出鼻をくじかれております。 田中と申します、どうぞよろしくお願いします。 (会場拍手) 22年前に
本田技研工業とドワンゴが共同開発したスマホアプリ「osoba(オソバ)」に起用されたバーチャルアイドル「初音ミク」のビジュアルが披露されました。デザインを手がけたのは漫画家、矢吹健太朗さんです。 本田技研工業とドワンゴが開発する「osoba」に起用された初音ミクのビジュアル。デザインは漫画家、矢吹健太朗が手がける (全3枚)フォトギャラリーで見る osobaは本田技研工業とドワンゴが共同プロジェクトとして開発を進めているユーザーサポートアプリで、「VOCALOID」などで人気を集めているバーチャルアイドル「初音ミク」を、音声によるサポートとコミュニケーションを担当するキャラクターとして起用。2019年1月に軽スポーツ「S660」を対応車種として、iOS向けに配信される予定となっています。 今回披露されたビジュアルは「ToLOVEる」などで知られる人気漫画家、矢吹健太朗さんがデザインを手がけ
「あなたは入社15年目の管理職です。あなたには部下が10人います。1人をリストラしなければならない状況になりました。管理職のあなたは、誰からリストラしますか?」 という設問を出し、学生がそれぞれ回答メモを書いたあと、グループディスカッションした。ある女子大での授業の一環。人の能力のあるなしを見極めるのは難しい。だから部下のこれまでの業績を勘案・熟慮して、いちばん業績があがっていない人をリストラせざるを得ないという答えが学生から導かれるだろうと、設問を考えた時に想定していた。 しかしその女子学生たちの「答え」は180度ちがっていた。「最も能力の高い人をリストラする」という「答え」が圧倒的だった。この結果をもとに、女子学生たちとディスカッションした。なぜそう考えたのか、彼女たちはこう考えた ─ 能力の高い人間はいつかこの職場を捨てるだろう。彼らを職場に引き留め、気をつかって大事にしたにもかかわ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く