タグ

ブックマーク / gihyo.jp (76)

  • xzパッケージに仕込まれた3年がかりのバックドア、スケール直前に見つけたのはMicrosoftの開発者 | gihyo.jp

    Linux Daily Topics xzパッケージに仕込まれた3年がかりのバックドア⁠⁠、スケール直前に見つけたのはMicrosoftの開発者 “アップストリームのxzリポジトリとxz tarballsはバックドア化されている(The upstream xz repository and the xz tarballs have been backdoored)⁠”―2024年3月29日、Microsoftに所属する開発者 Andres Freundが「Openwall.com」メーリングリストに投稿したポストは世界中のオープンソース関係者に衝撃を与えた。 backdoor in upstream xz/liblzma leading to ssh server compromise -oss-security 主要なLinuxディストリビューションにはほぼ含まれているデータ圧縮プログラ

    xzパッケージに仕込まれた3年がかりのバックドア、スケール直前に見つけたのはMicrosoftの開発者 | gihyo.jp
  • 第801回 続・USBメモリ型SSD選手権!長時間の書き込みにも強いデバイスはどれだ | gihyo.jp

    第三種目 限界突破8GB走(書き込み部門) 第一種目の8GB走(シーケンシャル書き込み部門)では、NVMe SSDUSBメモリSSDの間であまり差がつかず、360MB/sあたりに限界があるように見受けられました(図2、図3⁠)⁠。 図2 USBメモリSSDは、従来型USBメモリ(茶色の線)に比べて8GBの書き込みに必要な時間(横軸)が格段に短かかった 図3 しかし、NVMe SSDUSBメモリSSDの間では最高速度(縦軸)の面であまり差はつかず、360MB/s付近に天井があるように見受けられた そこで第三種目では限界の突破を試みます。速度の壁はSSD自体の性能に起因するものではなく、テストに使用していたUSBポートが5Gbpsまでにしか対応していないことが原因と考えられます。 特にノートPCにおいては、USB Type-CポートとType-Aポートの両方が搭載されている場合に、T

    第801回 続・USBメモリ型SSD選手権!長時間の書き込みにも強いデバイスはどれだ | gihyo.jp
  • 第772回 サーバー上で動くRSSリーダーであるFreshRSS | gihyo.jp

    前回はUbuntuデスクトップで動くRSSリーダーであるNewsFlashを紹介しました。今回はサーバー上で動作し、任意のウェブブラウザーで閲覧可能なRSSリーダーである「FreshRSS」について紹介しましょう。 図1 Web UIながら、テーマが豊富でコンパクトにまとめて表示できるFreshRSS 拡張機能も備えたFreshRSS RSSリーダー(フィードアグリゲーター)については前回も紹介しましたが、簡単に説明すると「RSSに対応したサイトの更新通知を受け取り、その内容を閲覧できる仕組み」です。スマートフォンで言うところの「ニュースアプリ」に近いものだと思っておけば良いでしょう。 ニュースアプリはローカルで動かしてインターネット越しにデータを集めます。それに対してFreshRSSや第266回で紹介したTiny Tiny RSSなどは、サーバー側でRSSのフィードデータを定期的に収集し

    第772回 サーバー上で動くRSSリーダーであるFreshRSS | gihyo.jp
  • 簡単で強力!誰でも始められる情報整理ツール「RemNote」を始めよう | gihyo.jp

    学習している内容や日々の考え事など、さまざまな情報を入力しながら自然に整理していくパーソナル・ナレッジ・マネージメント(PKM)ツールが注目されています。 しかし便利ではあるものの使い方が難しかったり、マニアックな設定が要求されたりするPKMツールが多い中、高機能なのに簡単に利用できるRemNoteが、最近モバイルアプリも登場して頭一つ抜けた存在になってきたように思います。そこで稿では初心者向けにRemNoteの使い方の紹介を通して、PKMの基的な考え方について深めてみます。 情報が複雑になってきたら、ツールも進化しなければいけない 忘れてしまっては困ることがあると、私たちはメモをとります。買い物でそろえるもの、テレビで耳にしたお得な情報、来週の予定、ちょっとした考え事。どんなことであっても私たちはメモをとります。 手段は紙でもスマートフォンでも変わりません。ふだんは意識しないほど当た

    簡単で強力!誰でも始められる情報整理ツール「RemNote」を始めよう | gihyo.jp
  • 第8回 価値を高めるプロダクトマネジメント | gihyo.jp

    コーナーでは技術へのタッチポイントを増やすことを目標に、各分野で活躍されている方をお迎えします。 今回はエンジニアと一緒に製品の価値を高めるプロダクトマネジメントをテーマに小城さんにインタビューします。 【話し手】 小城 久美子(KOSHIRO Kumiko)プロダクトマネジメントの体系化によって成功の再現性を高めたいエンジニア出身プロダクトマネージャー。書籍『プロダクトマネジメントのすべて』共著者、コミュニティ「プロダクト筋トレ」主催者。 Twitter @ozyozyo URL https://note.com/ozyozyo 価値を届ける仕事 日高: 小城さんはプロダクトマネージャーとして、またアドバイザーとしても活躍されていますよね。 小城: 今はプロダクトマネジメントを学問としてとらえたいと考えています。世の中にある成功と失敗から学んで、巨人の肩の上に立って成功に早く近付けるよ

    第8回 価値を高めるプロダクトマネジメント | gihyo.jp
  • Linux 6.1の注目機能「MGLRU」―メモリ管理に取り入れられたエイジングシステム | gihyo.jp

    Linus Torvaldsは12月11日(米国時間⁠)⁠、前週の告知どおりに「Linux 6.1」の正式リリースをアナウンスした。 Linux 6.1 -Linus Torvalds Linux 6.1はメインライン開発ではじめてRustを採用したことが大きな話題となったが、そのほかにもユーザ空間におけるメモリサニタイザーツールに似た動的エラー検出の「KMSAN」やB-treeベースのデータ構造「Maple Tree⁠」⁠、AMDの新しいPMFドライバのサポートなど多くのアップデートが行われている。Googleの開発者がメインラインへのマージを提案してきた「MGLRU(Multi-generational LRU⁠)⁠」もそのひとつで、古参のカーネル開発者であるAndrew MortonもMGLRUのメインライン化をバックアップしてきた。 Linuxカーネルではメモリ管理に「LRU(Le

    Linux 6.1の注目機能「MGLRU」―メモリ管理に取り入れられたエイジングシステム | gihyo.jp
  • 第704回 高機能でMarkdownや作図もサポートするWiki.js | gihyo.jp

    Wiki.jsはNode.jsベースのWikiシステムです。モダンな作りとスタイリッシュなデザインで、「⁠とりあえずWikiだけあれば良い」という用途には最善な選択肢のひとつでしょう。今回はそんなWiki.jsをUbuntuにデプロイしてみます。 あなたのWikiはどこから? 一般的に「Wiki(ウィキ⁠)⁠」と言えば「Wikipedia」を暗黙的に意味することが多い昨今の状況ですが、連載の読者ならおそらく誰でもご存知のように、現在ではウィキソフトウェアで動いている、ウェブブラウザーで複数のユーザーが共同で編集可能なコンテンツ管理システムの総称です。 生のHTMLを書くのに疲れた人にとって、Wikiの「人に優しいマークアップ言語[1]⁠」は魅力的に映り、現在では非常に多くの環境で様々なWikiが活用されています。その最も成功した例が、Wikipediaを支えているMediaWikiでしょ

    第704回 高機能でMarkdownや作図もサポートするWiki.js | gihyo.jp
  • 007 Change the Game ―アメリカンフットボールの世界はAWSでどう変わるのか | gihyo.jp

    「明日(12/5)は私からエキサイティングなアナウンスをするから楽しみにしていてほしい」―AWS re:Invent 2019のプレスカンファレンス終了時にアンディ・ジャシー(Andy Jassy)CEOは報道陣に向かってこう言いました。re:Inventでは毎年、アンディが世界各国から集まった200名ほどの報道陣向けにQ&A形式のプレスカンファレンスを行いますが、昨年(2018年)からはそれとは別にアンディによる"緊急会見"的な発表の場が設けられるようになりました。ちなみに昨年は人工衛星とのデータ通信をフルマネージドサービスとして提供する「AWS Ground Station」を発表しています。 はたして今年の"エキサイティング"な発表とは何だったのでしょうか。12月5日、会見に登壇したアンディが発表したのは米国でもっとも人気のあるスポーツ、アメリカンフットボールのプロフェッショナルリー

    007 Change the Game ―アメリカンフットボールの世界はAWSでどう変わるのか | gihyo.jp
  • モバイル・クラウド時代の新たなオフィスソフトへ、LibreOffice Conference2019 Almería, Spainレポート | gihyo.jp

    モバイル・クラウド時代の新たなオフィスソフトへ、LibreOffice Conference2019 Almería, Spainレポート LibreOffice Conference(通称LibOCon)は、オープンソースのオフィスソフトであるLibreOfficeの年次カンファレンスで、例年(決まっているわけではありませんが)ヨーロッパ圏で開催されています。プロジェクトの多くの開発者、貢献者、ユーザーが一同に介して、さまざまな議論を行います。 今年2019年は9月10日〜13日の日程[1]で、スペインのアルメリア(Almería)で行われました。アルメリアはスペイン・アンダルシア地方、地中海に面する美しい小都市で、オープンソース的にはデスクトップ環境KDEの年次カンファレンスAkademyや、同じくGNOMEの年次カンファレンスGUADECをホストしてきました。 今年のLibOConの

    モバイル・クラウド時代の新たなオフィスソフトへ、LibreOffice Conference2019 Almería, Spainレポート | gihyo.jp
    vcc
    vcc 2019/10/15
    “LibreOffice OnlineサーバーはLibreOfficeをLibreOfficeKitというC++のヘッダライブラリで起動し,レンダリング結果を256x256のタイルに分割してWebSocket経由でフロントに送信します。フロント側はLeafletでこれらを並べて描画します。”
  • 第2回 Oracleの汎用仮想マシン「GraalVM」の現状と課題[c1jp] | gihyo.jp

    2019年9月16~19日にかけての4日間、米サンフランシスコのMoscone CenterにおいてOracle主催の技術カンファレンス「Oracle Code One 2019」が開催されました。Oracle Code Oneは2年前までは「JavaOne」の名称で開催されていたもので、Javaを中心とした開発者向けのセッションやブース展示、交流会などが行われる年次イベントです。 今年のCode Oneで話題の中心となっていたのは、2018年にOracleがリリースした「GraalVM」です。GraalVMは、Java仮想マシン(以下、JVM)およびJIT(Just-in-Time)/AOT(Ahead-of-Time)コンパイラの技術を利用して作成された多言語対応の汎用仮想マシンです。昨年のCode Oneレポートでも『【Oracle Code Oneレポート】Oracleが開発中の仮

    第2回 Oracleの汎用仮想マシン「GraalVM」の現状と課題[c1jp] | gihyo.jp
  • 【Oracle Code Oneレポート】Oracleが開発中の仮想マシン「GraalVM」で何ができるか | gihyo.jp

    新たな歴史の1ページ~Oracle Code One 2018現地レポート 【Oracle Code Oneレポート】Oracleが開発中の仮想マシン「GraalVM」で何ができるか 2018年10月22日から25日にかけての4日間、米サンフランシスコのMoscone CenterにおいてOracle主催の開発者向けイベント「Oracle Code One 2018」が開催されました。これは、これまでは「JavaOne Conference」として開催されていたイベントの後継となるものです。名称が変更された背景には、対象となる技術の裾野を広げてエンジニア同士のコラボレーションを促進しようという目的があります。多言語対応という時代の流れを取り入れた形と言えます。 Oracle自身、多言語対応の鍵となるさまざま技術を開発していますが、その1つに「GraalVM」があります。これはJava技術

    【Oracle Code Oneレポート】Oracleが開発中の仮想マシン「GraalVM」で何ができるか | gihyo.jp
  • 第537回 Standard Notesでメモを取る | gihyo.jp

    今回はEnd-to-Endの暗号化に対応し、拡張機能も備えたFLOSSなメモサービスであるStandard Notesを紹介します。 シンプルなWebベースのメモサービス「Standard Notes」 Ubuntuにおけるメモツールとしては直近だと第530回でQOwnNotesが、第536回でJoplinが紹介されていました。これらはいずれも実際にメモを保存する場所としてNextcloudなどの外部サービスやローカルストレージを利用し、そのデスクトップクライアントとして動作するタイプのアプリケーションです。よって利用するためにはクライアントをインストールする必要があります。 たとえば保存先がNextcloudの場合、NextcloudそのものにWeb UIがあるためWebブラウザーがあればメモを編集することも可能です。ただし元々はファイル共有のためのサービスであるため、単純なメモサービス

    第537回 Standard Notesでメモを取る | gihyo.jp
  • 第8回 無駄な英語勉強:継続は力なり―大器晩成エンジニアを目指して|gihyo.jp … 技術評論社

    IT業界は比較的英語が必要とされる。ドキュメントは英語で書かれていることが多く、多くのニュースは海外からやってくる。プログラマー英語の必要性を感じやすい職業と言えるだろう。 そのようなわけで、筆者も細々と10年以上英語を勉強してきた。いつかシリコンバレーで働いてみたいと勉強し、幸運なことに数年前に、ぼろぼろの英語力で何とか面接を突破してアメリカ企業に就職。サンフランシスコに4年ほど住み、現在では東京に戻った。日々の仕事をこなす程度の英語は話せるようになった。帰国子女でもない自分が試行錯誤して何とか仕事英語が使えるようになったのだ。ふりかえればうまくいった勉強方法もあれば、無駄だったものもある。そんな経験をもとに、今回は英語の勉強方法を紹介したいと思う。 目標 まず目標を明確に絞ろう。目標があれば、優先順位を付けやすくなる。目標は「日にいながら、外資系企業の面接に必要とされる程度の英語

    第8回 無駄な英語勉強:継続は力なり―大器晩成エンジニアを目指して|gihyo.jp … 技術評論社
  • データセンター向け水冷サーバ「Triton」に見るDellのアプローチ | gihyo.jp

    Dellは今から1年ほど前、2016年6月に液冷のラックサイズのサーバシステム「Triton」(⁠写真1)を発表しました[1]⁠。eBay向けのサーバとしても話題になったので、コンクリート壁の部屋に置かれたラックの写真を覚えている人も多いでしょう。 写真1 ラボに設置されていたTritonラック 筆者はこの記事を読んで、それがDellの自社開発であることに興味を持ちました。Dellがサーバ向けの尖った技術開発で目立った記憶と言えば、まず2010年のFlexMem、つまりXeonプロセッサのソケットに装着するQPIインターフェースのメモリコントローラ[2]です。 しかしそれ以外の事例はあまり記憶になく、どちらかと言うとDellは「標準技術を採用する」会社という印象があります。 それがデータセンター事業者向けに独自開発を行い、eBayのような大規模ユーザが採用したと聞けばとても興味が湧きます。

    データセンター向け水冷サーバ「Triton」に見るDellのアプローチ | gihyo.jp
  • 第3回 GUIツールBaculumを使ってバックアップを簡単にする | gihyo.jp

    CentOS7で使用するポートを解放するコマンドは以下になります。 # firewall-cmd --permanent --add-service=bacula success # firewall-cmd --permanent --add-port=9095/tcp success # firewall-cmd --reload success リポジトリ追加 まずBaculum用のリポジトリを追加します。 viエディタなどで以下の様にbaculum.repoファイルを作成し/etc/yum.repos.d配下に配置します。 # cd /etc/yum.repos.d # vi baculum.repo [baculumrepo] name=Baculum CentOS repository baseurl=http://bacula.org/downloads/baculum/ce

    第3回 GUIツールBaculumを使ってバックアップを簡単にする | gihyo.jp
  • 第58回 APFS - Appleファイルシステム開発中 | gihyo.jp

    APFS - Apple File System Appleは2016年6月13日から17日にかけて開催されたWWDC16において、新しいファイルシステム「APFS - Apple File System」を開発中であることを発表しました。この新しいファイルシステムはmacOS、tvOS、iOS、watchOSなど同社が開発しているプロダクトで共通的に利用するファイルシステムとされており、現在利用されているHFS+を置き換えるものと考えられています。開発は2014年にはじまり、2018年ごろを目処にプロダクトへの投入が予定されています。 公開された技術文書を読む限りでは、APFSはZFSからいくつかの機能や概念を抜いたものに似ています。ZFSからいくつかの機能を抜いて、基的にAppleプロダクトで利用するフラッシュストレージを効率よく利用できる機能を追加したもの、といったような内容です。

    第58回 APFS - Appleファイルシステム開発中 | gihyo.jp
    vcc
    vcc 2017/01/07
    APFSの暗号化機能はマルチキー機能がモバイルデバイスやエンタープライズでの用途を想定したもののにように見えます。この機能を実現するためにAPFSの開発がはじまった。
  • GitLabのこれまでとこれから | gihyo.jp

    あけましておめでとうございます。株式会社Ruby開発の佐藤です。 近年、GitHubを利用したソーシャルコーディングが注目を集めています。GitHubを利用するとエンジニア同士の共同作業をスムーズに進められるため、ソフトウェア開発の生産性を向上させる効果が期待できます。そのため、オープンソースソフトウェア開発での利用にとどまらず、通常業務でGitHubを利用する企業が増えています。 そこで稿では、GitHubの競合として注目が高まっているGitLabについて紹介します。 GitLabとは GitLabは、GitLab社が開発しているRuby on Rails製のGitホスティングソフトウェアです。GitLabには無料で利用可能なオープンソースソフトウェアのCommunity Edition(以下CE)と、利用にライセンスが必要なプロプライエタリソフトウェアのEnterprise Edit

    GitLabのこれまでとこれから | gihyo.jp
  • 第2章 カンファレンス向け高密度無線LANの作り方―成功のカギは電波特性を活かすこと | gihyo.jp

    イーサネットでは、たとえばアップリンク1Gbpsのスイッチに収容できる端末の合計スループットは、余程のことがない限り大まかに1Gbpsであろうと予測できます。しかし、無線LANの場合は電波状況が理想的ではないことが多く、性能が予測しづらくなります。これはおもに、空間の状況が多様であることと、半二重であることによります。 ここでは、非常に単純化したモデルとして、1つの無線LANチャネルを5台の端末で共有して利用することを考えます。時間で区切って、それぞれの端末が順にデータを転送しますが、ある一瞬に注目すれば特定の端末とAPが1対1でチャネルを占有しています(図3⁠)⁠。 図3 1つのチャネルを複数台の端末で共有(5台の端末に100KBずつ転送すると仮定)(⁠注2) 実際には、占有時間は通信内容によってまちまちです(図4⁠)⁠。無線LAN独自の制御フレームのため、転送すべきデータがなくとも通信

    第2章 カンファレンス向け高密度無線LANの作り方―成功のカギは電波特性を活かすこと | gihyo.jp
  • 第7回 TCPとUDPの違い、深層の真相 | gihyo.jp

    TCPとUDPはOSIのレイヤ4(トランスポートプロトコル)であり、よく以下のように説明されていますよね。 ●TCP ・信頼性が高い ・コネクション型プロトコルである ・ウインドウ制御、再送制御、輻輳(ふくそう)制御を行う ●UDP ・コネクションレス型プロトコル ・信頼性を確保する仕組みがない ・処理が簡単で遅延が少ない しかし、これらの説明には重要な視点が欠けていると思います。 データを「ストリーム」として扱うTCPと、「データグラム」を処理するUDPという考え方です。 トランスポートプロトコルとは? まずは、そもそもTCPやUDPなどのトランスポートプログラムがなぜ必要なのかを考えてみましょう。 ふつう、私たちが利用しているPCやサーバーでは、同じコンピュータの上で複数のアプリケーションが動作していますよね。アウトルックでメールを書きながら、ブラウザでホームページを見たりすることがで

    第7回 TCPとUDPの違い、深層の真相 | gihyo.jp
    vcc
    vcc 2016/10/11
    UDPが作られたのは,TCP/IPが考案されてから15年後。「音声」や「映像」などのリアルタイム通信のため「何もしない」トランスポートプロトコルであるUDPを作った。
  • 第84回 Linuxの成長過程をふりかえる[その3] | gihyo.jp

    この結果をソースコード全体に占める各ディレクトリの割合に換算し、扇型グラフに描いたのが図2です。図2では、内側から1.1.13、1.1.52、1.1.93の順になっています。 図2 linux-1.1シリーズのディレクトリ構成 この表と図で目に付くのは1.1.52から現われているarchディレクトリです。archディレクトリは1.1.52の段階では72KBほどと小さいものの、1.1.93では1280KBまで増加し、ソースコード全体の1割強を占めるようになっています。 このディレクトリにはlinuxが対応しているそれぞれのCPU専用のコードが収められています。具体的には、元々サポートしているi386以外に、alpha、mips、sparcの各ディレクトリが追加されています。 $ ls linux-1.1.93/arch/ alpha/ i386/ mips/ sparc/ archディレクト

    第84回 Linuxの成長過程をふりかえる[その3] | gihyo.jp
    vcc
    vcc 2016/08/04
    Linuxの開発者たちが採用したのは「ドライバ類をモジュールとして用意し,必要に応じて動的に組み込む」というモジュールカーネルのアイデアです。