並び順

ブックマーク数

期間指定

  • から
  • まで

241 - 280 件 / 554件

新着順 人気順

*nixの検索結果241 - 280 件 / 554件

  • WSLがコマンド一発でインストール可能に/2021年7月Cパッチを適用済みの「Windows 10 バージョン 2004」以降で

      WSLがコマンド一発でインストール可能に/2021年7月Cパッチを適用済みの「Windows 10 バージョン 2004」以降で
    • 由来で覚えるlinux用語集 - Qiita

      随時更新予定。。。 ls = list | list segments(コメント欄参照) ln = link mv = move cd = change directory cp = copy rm = remove mkdir = make directory rmdir = remove directory chown = change owner chmod = change mode cat = catenate || concatenate tac = catの逆コマンド(ファイルを逆から出力) grep = "g/RE/p" || globally search a regular expression and print ping = 潜水艦などで使われるアクティブソナーの発する音波 sh = shell bash = Bourne again shell su = subs

        由来で覚えるlinux用語集 - Qiita
      • zshでPATHが壊れないようにPATHに新しいディレクトリを通す - Acme::AnaTofuZ->new;

        TL;DR 特に順番は気にしないとき path+=('/hoo/bar/baz'); 最初にいれたいとき path=('/hoo/bar/baz' $path) PATH通そうとして壊れるヤツ UNIXを使っている上で避けて通れないのが環境変数$PATHでしょう。 :区切りにディレクトリを列挙して、列挙されているディレクトリ直下に置かれているバイナリファイルをコマンドとして使えるようにするアレですね。 そんな$PATHに新しいディレクトリを追加しようとして、ついつい次のような事故がよく置きます。 export PATH="/hoo/bar/baz" こうしてしまうと最初から$PATHに設定していたデータが吹っ飛んで、PATHの中身が/hoo/bar/bazだけになってしまいます。こうなるとlsとかのコマンドが使えなくなる訳ですね。 zshだと$pathで配列として扱える この問題は何が原因

          zshでPATHが壊れないようにPATHに新しいディレクトリを通す - Acme::AnaTofuZ->new;
        • なぜシェルスクリプトはPOSIX準拠でも環境依存が激しいのか? 〜POSIXの問題点とその解決策の案〜 - Qiita

          なぜシェルスクリプトはPOSIX準拠でも環境依存が激しいのか? 〜POSIXの問題点とその解決策の案〜ShellScriptBashshellPOSIX まえがき この記事は「シェルスクリプトで高い移植性と生産性を両立させるシリーズ」の第一弾です。移植性と生産性を両立させるための前提知識として POSIX コマンドの問題点について解説します。第二弾では高い移植性と互換性を実現させるための考え方、そして第三弾、第四弾ではそれを実現するシェルスクリプトの具体的な実装テクニックを紹介します。第五弾では現実的な問題と回避方法について解説する予定ですがまだ具体的な内容は決まっていません。第五弾はその前に「シェルスクリプト入門(仮)」の記事を書こうと思ってるので少し遅くなると思います。もし興味がある方は記事をストックしていると更新時に通知されると思います。 2021-07-11 追記 記事が長くなった

            なぜシェルスクリプトはPOSIX準拠でも環境依存が激しいのか? 〜POSIXの問題点とその解決策の案〜 - Qiita
          • Webブラウザーで「Debian」Linuxが動く! WebAssembly製のx86仮想マシン「WebVM」/バイナリそのまま・再コンパイルなし。完全にクライアント側だけで動作

              Webブラウザーで「Debian」Linuxが動く! WebAssembly製のx86仮想マシン「WebVM」/バイナリそのまま・再コンパイルなし。完全にクライアント側だけで動作
            • GitHub - dnobori/DN-Win32DiskImagerRenewal: このリポジトリは、Windows 上での USB メモリ / SD カードイメージ書き込みツールのデファクト・スタンダードとなっている Win32 Disk Imager について、以下の点を改良した 「Win32 Disk Imager Renewal」 の デジタル署名済みの EXE 単体で動作する Win32 / x64 / ARM64 版バイナリ とソースコードを配布するためのものである。(1) PC 上で G

              しかし、原版の Win32 Disk Imager には、以下の問題点があった。 Google Drive との相性問題。 Google Drive クライアントアプリケーションを稼働させている Windows 環境では、Win32 Disk Imager の起動時に、エラーが発生し、正常に利用できない。 この問題は、Google Drive の仮想ドライブ機能 (G:\ 等) が有効になっている場合に発生する。 Google 社は、オープンソースの Dokan (Windows 用 FUSE ドライバ) を改造した Windows NT カーネル用デバイスドライバを用いて Google Drive の仮想ドライブを実装している。しかし、この仮想デバイスドライバと Win32 Disk Imager とは相性が悪く、Win32 Disk Imager の起動時のデバイス列挙時にエラーが発生

                GitHub - dnobori/DN-Win32DiskImagerRenewal: このリポジトリは、Windows 上での USB メモリ / SD カードイメージ書き込みツールのデファクト・スタンダードとなっている Win32 Disk Imager について、以下の点を改良した 「Win32 Disk Imager Renewal」 の デジタル署名済みの EXE 単体で動作する Win32 / x64 / ARM64 版バイナリ とソースコードを配布するためのものである。(1) PC 上で G
              • コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート]

                コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート] こんにちは、NTTの徳永です。本稿では、コンテナユーザなら誰もが使っていると言っても過言ではない、コンテナランタイムの筆頭「runc」に注目し、その概要を仕様と実装の両面から俯瞰します。本稿は私が主催者の一人として参加した「Container Runtime Meetup #1」で発表した内容をベースにしています。詳しい内容は発表資料もぜひご参照ください。 コンテナランタイムとはKubernetes等のコンテナオーケストレータを用いてアプリケーションをコンテナ(Pod)として実行するとき、実際にコンテナの作成をしているのは誰でしょうか。実はKubernetesはコンテナを直接触らず、あるソフトウェアを用います。まさにそれがコンテナランタイム(以降、ランタ

                  コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート]
                • Pythonのthreadingとmultiprocessingを完全理解 - Qiita

                  現代の主なOSと言ったら、Mac OS,UNIX,Linux,Windowsなどがあります。これらのOSは「マルチタスク」機能をサポートしています。 マルチタスクとは?と思うかもしれませんが、例えばブラウザーを立ち上げて、音楽聴きながら、Wordでレポートを書くというシチュエーションでは、少なくとも3つのタスクが同時進行しています。そして、表のタスク以外に、裏ではOS関連の様々なタスクがこっそり動いています。 マルチコアのCPUで、マルチタスクが処理できるのは理解しやすいですが、シングルコアのCPUでもマルチタスクが可能です。OSはそれぞれのタスクを交替に実行しています。例えば、タスク1を0.01秒、タスク2を0.01秒、タスク3を0.01秒、タスク1を0.01秒......繰り返して実行していきます。CPUは速いので、ほぼ同時進行のように感じます。この交替実行のことをしばしば「並行処理(

                    Pythonのthreadingとmultiprocessingを完全理解 - Qiita
                  • 「UNIXという考え方」を読み直して、考えたこと - Magnolia Tech

                    UNIXという考え方―その設計思想と哲学 作者:Mike Gancarz発売日: 2001/02/01メディア: 単行本 前回エントリで紹介した「リモートワークの達人 (ハヤカワ文庫NF)」は何度も読み返すべき本として紹介してもらったのだけど、その時に同時に上がったのが「UNIXという考え方」という本。 確かにこの本は自分も何度も読み直している。 なぜおなじ本、しかも技術書を読み返す必要が有るのだろう。 もうそこに書かれていることは分かっている。特に古い本ならなおさらだ。 この「UNIXという考え方」という本は、原著が1996年に出版され、日本でも2001年に出版された非常に古い本だ。 まだLinuxは2.0の時代、商用UNIXの方が信頼度が高いとされていた時代。 もう書かれていることは何度も語られている、語り尽くされている。 それでも今でも読むべき技術書の上位に位置したままランクを落とさ

                      「UNIXという考え方」を読み直して、考えたこと - Magnolia Tech
                    • WebVM - Linux virtualization in WebAssembly

                      __ __ _ __ ____ __ \ \ / /__| |_\ \ / / \/ | \ \/\/ / -_) '_ \ V /| |\/| | \_/\_/\___|_.__/\_/ |_| |_|

                        WebVM - Linux virtualization in WebAssembly
                      • Win32 Disk Imager Renewal (Google Drive 相性問題解決、単一バイナリ、デジタル署名版) - by dnobori - Qiita

                        Win32 Disk Imager Renewal (Google Drive 相性問題解決、単一バイナリ、デジタル署名版) - by dnoboriWindowsUSBWin32APIGoogleDriveSDカード by 登 大遊, 2022/11/19, Quiita 第二投稿記事 Git リポジトリ https://github.com/dnobori/DN-Win32DiskImagerRenewal は、Windows 上での USB メモリ / SD カードイメージ書き込みツールのデファクト・スタンダードとなっている Win32 Disk Imager について、以下の点を改良した 「Win32 Disk Imager Renewal」 の デジタル署名済みの EXE 単体で動作する Win32 / x64 / ARM64 版バイナリ とソースコードを配布するためのものである

                          Win32 Disk Imager Renewal (Google Drive 相性問題解決、単一バイナリ、デジタル署名版) - by dnobori - Qiita
                        • 【POSIX準拠】set -o pipefailを使おう!ただしdash、テメーはダメだ - Qiita

                          はじめに set -o pipefail は POSIX で標準化されているシェルオプションです。パイプラインにおけるエラーを確実に検出するために、シェルスクリプトでは基本的に使うようにしましょう。 某コメントより “set -o pipefail は標準化されました” っていってここ何年かの標準化を無邪気に正当化できるのいいなと思う(目の前のターミナルを見ながら) どのシェルを今使っているのか聞きたいですね。商用 Unix を含む主流の環境で、すでに何年(十数年、数十年)も前から set -o pipefail は実装済みなんですが? おそらくシェルの事をよく知らないで言ってるのでしょう。私は標準化の有無は関係なく実際のシェルのことを調べ尽くして言ってるわけで無邪気に正当化とか失礼な話です。標準化とか気にしてるから何年(十数年、数十年)も前に実装された便利な機能が使えないんですよ。自業自

                            【POSIX準拠】set -o pipefailを使おう!ただしdash、テメーはダメだ - Qiita
                          • Bash初心者からエキスパートになるためのコマンドとヒント101 - Qiita

                            以下はAndrewによる記事、101 Bash Commands and Tips for Beginners to Expertsの日本語訳です。 一部を除き、上から順にコマンドを打って確かめることができるようになっています。 読むだけではなく、実際に打って試してみることで理解が早まることでしょう。 101 Bash Commands and Tips for Beginners to Experts 一年前まで、私はもっぱらMacOSとUbuntuのふたつのOSで作業をしていました。 両OSにおいて、私のデフォルトシェルはbashです。 過去6、7年ほどbashで仕事をしているため、bashがどのように動作するか、ある程度は理解しているつもりです。 従って、bashを始めたばかりの人にとって一般的で有用なコマンドについて、いくつか解説していきたいと思います。 また、bashについて知っ

                              Bash初心者からエキスパートになるためのコマンドとヒント101 - Qiita
                            • システムコールを速く漏れなくフックする方法 | IIJ Engineers Blog

                              ptrace、Syscall User Dispatch:カーネルが提供している ptrace や Syscall User Dispatch のような機能は、ユーザ空間でシステムコールのフックを実装するために利用できます。ですが、これらを利用すると、元のユーザ空間プログラム内部でのシステムコール呼び出しのコストが大きくなり、結果として、性能が大きく劣化してしまいます。(要件1を満たせない) eBPF :eBPF のようなカーネル内の関数へフックを適用できる仕組みもありますが、eBPF は XDP のような場合を除くと、基本的にカーネルの挙動を変更するためには利用できないため、カーネル機能をユーザ空間でエミュレートする、といった用途には適していません。(要件5を満たせない) ライブラリ関数の置き換え:標準ライブラリ(libc 等)は、沢山のシステムコールのラッパーライブラリ関数を実装してお

                                システムコールを速く漏れなくフックする方法 | IIJ Engineers Blog
                              • パイプに関係するさまざまなバッファ、ちゃんと意識していますか? - Qiita

                                はじめに コマンドをパイプでつなげた時、各コマンドの間にはいくつかのバッファが存在します。そのバッファについてちゃんと意識しているでしょうか? バッファの存在によって各コマンドの実行には分かりづらい変化があります。そのバッファを知らないと罠にハマってしまう・・・かもしれません。 プロセス間のパイプ通信のバッファ まずプロセス間のパイプ通信に存在しているバッファです。多くのコマンドは行単位でデータを処理しますが、一般的にパイプでつなげた各コマンドはそれぞれ処理速度が異なります。処理がすぐに終わるコマンドもあれば時間がかかるコマンドもあります。各コマンドは並列で動作可能ですが必ずしも並列で動作するわけではありません。 一般論としてパイプライン全体の処理にかかる実時間はパイプでつながったコマンドの中で一番遅いコマンドに足を引っ張られます。いくら並列で動作可能と言ってもデータが到着しなければ処理す

                                  パイプに関係するさまざまなバッファ、ちゃんと意識していますか? - Qiita
                                • Unixコマンドはネット企業になり、OSSはSaaSになった | Coral Capital

                                  全てのUnixコマンドはいずれネット企業になる、grepはGoogleになり、rsyncはDropboxに、manはStackOverflow、cronはIFTTT――。 この予言めいた言葉を、私は米国VCのAndreessen Horowitzパートナー、クリス・ディクソン氏のツイートで知りました。2014年のツイートですが、これがディクソン氏のオリジナルなのか、それとも良く言われていることなのか、ちょっと分かりません。ただ、UnixやLinuxを触ったことがある人であれば、この法則が驚くほど良く成り立っているように思えるのではないでしょうか(最近の若手ソフトウェア・エンジニアはあまりコマンドラインに触れないそうですが)。 この予言がすごいのは、30〜40年の隔たりがあっても類似性が成立していることです。Unixコマンドの多くは1980年〜1990年代には多くのシステムで実装され、利用さ

                                    Unixコマンドはネット企業になり、OSSはSaaSになった | Coral Capital
                                  • シェルスクリプトを学ぶ人のための「新しいUNIX哲学」 〜 ソフトウェアツールという考え方 - Qiita

                                    はじめに 「UNIX 哲学 (Unix philosophy)」とは、一つの大きなシステムを、独立した小さなソフトウェアの集まりとして作るという考え方です。UNIX のように大きく複雑なものをシンプルに作るための考え方で、技術的な用語で説明するならば、大きなシステムをモジュール化された構成可能なプログラム設計で開発するということです。 UNIX 哲学に公式の定義は存在しません。ケン・トンプソンを始めとする UNIX の創始者が UNIX の開発を通して示したソフトウェア開発の考え方が UNIX 哲学と言われるようになり、それを他の人が独自に解釈して解説したものが UNIX 哲学として知られています。UNIX 哲学と呼ばれているものが複数あって、それぞれで異なっているのはそのためです。UNIX 哲学の本質的な考え方は今も通じるものですが、これまでの UNIX 哲学の解説の多くは古い技術を元に

                                      シェルスクリプトを学ぶ人のための「新しいUNIX哲学」 〜 ソフトウェアツールという考え方 - Qiita
                                    • Windows 11、デフォルトでTarファイルの作成が可能に。これでWindowsはTarファイルの解凍と作成の両方に対応へ

                                      Windows 11、デフォルトでTarファイルの作成が可能に。これでWindowsはTarファイルの解凍と作成の両方に対応へ 次のWindows 11の大型アップデートで、Tarファイルの作成にデフォルトで対応予定であることが明らかになりました。 現在開発中のWindows 11β版で、ファイルエクスプローラーのコンテキストメニューにTarファイルに圧縮するメニューが追加されると、同社のブログ「Announcing Windows 11 Insider Preview Build 22635.3640 (Beta Channel)」で発表されました。 Tarファイルは複数のファイルを1つにまとめることができるファイル形式です。Tarという名称は磁気テープにデータを保存する「テープアーカイブ」(Tape Archive)から由来することからも分かるとおり、古くからUNIXでよく使われてきま

                                        Windows 11、デフォルトでTarファイルの作成が可能に。これでWindowsはTarファイルの解凍と作成の両方に対応へ
                                      • シェルスクリプトの [ は /bin/[ と言ったり [ "x$var" = "xval" ] と書く人はオジサン - Qiita

                                        # Ubuntu 20.04 の bash での実行結果 # シェルから [ が何として見えているか $ type [ [ is a shell builtin # PATH から見つかる全ての [ コマンドを出力する # 補足 zsh では which がシェルビルトインコマンドで、シェルビルトイン版の [ も出力される $ which -a [ /usr/bin/[ /bin/[ $ type [[ [[ is a shell keyword # zsh では [[ をパターンとして認識してしまうのでダブルクォートが必要 $ type "[[" [[ is a reserved word ちなみに [ の外部コマンド版が /usr/bin/ と /bin/ の両方にあるのは Ubuntu 20.04 では /bin が /usr/bin へのシンボリックリンクになっているからです。Ub

                                          シェルスクリプトの [ は /bin/[ と言ったり [ "x$var" = "xval" ] と書く人はオジサン - Qiita
                                        • Mackerel をファイルシステムにした - Unengineered Weblog

                                          この記事ははてなエンジニア Advent Calendar 2023の 12月36日 2024年1月5日の記事です。 developer.hatenastaff.com Mackerel をファイルシステムにしてみましょう。 Mackerel でファイルシステムを監視するのではありません。 Mackerel をファイルシステムにするのです。 じゃん mackerelfs と言います。よろしくおねがいします。 github.com /home/rmatsuoka/mackerel ディレクトリに mackerelfs をマウントしましょう(マウントの方法は後半説明します。)最初は ctl ファイルだけがあります。 $ ls -l total 0 --w--w--w- 1 rmatsuoka rmatsuoka 0 Jul 14 2042 ctl さて Mackerel を操作するときは AP

                                            Mackerel をファイルシステムにした - Unengineered Weblog
                                          • コアを多数搭載するCPUは「POSIX」によって能力を制限されているとの指摘

                                            by Rudolf Schuba UNIX系のOSに共通する機能の呼び出し方法などを定めたPOSIXは、「POSIXに準拠するならばどんな環境でも動作する」ことを保証する規格です。POSIXは長年移植可能なアプリケーションの開発を支えてきましたが、システム管理者のチャールズ・フィッシャー氏は「POSIXがマルチコアCPUの能力を制限する要因となっている」と指摘し、「xargs」コマンドを例として具体的な説明を行っています。 Parallel shells with xargs: Utilize all your cpu cores on UNIX and Windows | Linux Journal https://www.linuxjournal.com/content/parallel-shells-xargs-utilize-all-your-cpu-cores-unix-and-

                                              コアを多数搭載するCPUは「POSIX」によって能力を制限されているとの指摘
                                            • ((🐑++)) on Twitter: "パケットが帰ってくるとピングーが出てくるpingコマンドを作りました 楽しいwww https://t.co/VxeVtIt2IB #golang #cli #ping https://t.co/KoLlEou9Ou"

                                              パケットが帰ってくるとピングーが出てくるpingコマンドを作りました 楽しいwww https://t.co/VxeVtIt2IB #golang #cli #ping https://t.co/KoLlEou9Ou

                                                ((🐑++)) on Twitter: "パケットが帰ってくるとピングーが出てくるpingコマンドを作りました 楽しいwww https://t.co/VxeVtIt2IB #golang #cli #ping https://t.co/KoLlEou9Ou"
                                              • systemdエッセンシャル / systemd-intro

                                                RHEL8 で systemd の出力やログを読んで理解できないときに、どこを調べたらいいか見当がつくようになることを目標として、systemdの基本的な考え方や、調べるときに中心になりそうなトピックを紹介する資料。RHEL 8を想定しています。

                                                  systemdエッセンシャル / systemd-intro
                                                • A4用紙40枚で1969年から2022年までのUNIXの歴史「Unix History」を一望してみた

                                                  歴史上初めて高水準言語で書かれたOSで、現代OSの始祖とも呼ばれる「UNIX」の50年以上にわたる歴史を時系列で示した「UNIX History」を、コンピュータの歴史を研究するÉric Lévénez氏が公開しています。A4用紙に印刷することも可能とのことで、実際にプリントしてその歴史の長さを感じてみました。 UNIX History https://www.levenez.com/unix/ UNIX HistoryのA4印刷版は、PDFファイルのリンクが上記サイトに置かれています。「A4」のリンクをクリックしてダウンロード。 というわけで、このA4印刷版のPDFファイルを実際にプリンターで印刷してみました。 A4用紙で40枚。 40枚をつなげるため、右端だけ仕上がりサイズに合わせてカット。 セロハンテープでつなげていきます。 40枚すべてを並べて見たところ。A4用紙40枚をつなげると

                                                    A4用紙40枚で1969年から2022年までのUNIXの歴史「Unix History」を一望してみた
                                                  • 本の虫: 500マイル以上離れた場所にメールが送れないのだが

                                                    著者:江添亮 ブログ: http://cpplover.blogspot.jp/ メール: boostcpp@gmail.com Twitter: https://twitter.com/EzoeRyou GitHub: https://github.com/EzoeRyou アマゾンの江添のほしい物リストを著者に送るとブログ記事のネタになる 筆者にブログのネタになる品物を直接送りたい場合、住所をメールで質問してください。 http://web.mit.edu/jemorris/humor/500-miles From: Trey Harris <trey@sage.org> 今から私が書く話は、起こりようのない問題についてだ。この話を広く一般に公開してしまうのは惜しい。というのも、いい酒の話のネタになるからだ。この物語は、退屈な詳細や問題を隠すために、多少事実を変えていて、物語を面白く脚

                                                    • 増補改訂版!Webやコンピュータのすべてがわかる文句なしの教本「教養としてのコンピューターサイエンス講義」 第2版 カーニハン |TAKASU Masakazu

                                                      カーニハン先生が、大学1年生と未来の大統領に向けて、コンピュータのすべてを紐解くプログラマーならみんな知ってる、C言語のカーニハン先生が、プリンストン大学の文系の学生向けにコンピュータについての一般教養を教える本書は、2020年に出版された第1版が、すでにベストセラーになっている。あらゆるプログラムで最初にテストされる「hello world」を最初に言ったのはカーニハンとリッチーの書いた入門書と言われている。世界で一番有名な人の一人で、今も現役で学生向けにコンピュータとは何かを、毎年資料をアップデートしながら教えている。 まえがきのあらゆる人も、大統領も、この本の内容ぐらいは知っておくべきで、非専門家に向けて書いたという姿勢は素晴らしいし、内容はそのとおりのものだ。 当時書いた書評ブログもはてブ450と大ヒットした。この本の良さは、ブログに書いたとおりだ。↓ (おかげさまで、第2版は献本

                                                        増補改訂版!Webやコンピュータのすべてがわかる文句なしの教本「教養としてのコンピューターサイエンス講義」 第2版 カーニハン |TAKASU Masakazu
                                                      • 【Ubuntu日和】 【第12回】ショートカットとByobuを駆使して、UbuntuのCLI操作を効率化しよう

                                                          【Ubuntu日和】 【第12回】ショートカットとByobuを駆使して、UbuntuのCLI操作を効率化しよう
                                                        • anyenvをやめて、asdfに移行した - 半空洞男女関係

                                                          Apple Siliconの載ったMacBookAirが届いた。せっかくの機会なのでdotfilesを整理したり、周辺環境を整備しているが、プログラミング環境を整備してくれるanyenvをやめて、asdfに移行した。 Start using asdf instead of anyenv · mactkg/dotfiles@94d515d · GitHub 同僚がanyenvの代わりにasdfを紹介していたのがきっかけでasdfを知ったのだが、asdfはshell scriptとして書かれていて、結構レスポンスがいい。anyenvは結構起動時間などに時間がかかっていて、微妙にストレスを感じていたので、asdfの軽さに満足している。 移行に関しては anyenv から asdf に移行した - a.out の記事を参考にした。この記事にあるように、あらゆるアプリケーションのバージョン切り替えを

                                                            anyenvをやめて、asdfに移行した - 半空洞男女関係
                                                          • mount コマンドはもう古い? findmnt を使おう

                                                            「このディレクトリって何のファイルシステム?」とか「マウントオプションは?」を確認するときに、手癖で mount コマンドを実行してるけど、 $ mount proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel) devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=4096k,nr_inodes=118922,mode=755) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm typ

                                                              mount コマンドはもう古い? findmnt を使おう
                                                            • iselegant | Masaya ARAI on Twitter: "定期的に見る機会があるこの一覧、Linux系perfコマンドがひと目で分かるだけでなく、カーネルの構造についても復習できるので本当によい。 https://t.co/aNf5POIvYO https://t.co/9VgTyInybF"

                                                              定期的に見る機会があるこの一覧、Linux系perfコマンドがひと目で分かるだけでなく、カーネルの構造についても復習できるので本当によい。 https://t.co/aNf5POIvYO https://t.co/9VgTyInybF

                                                                iselegant | Masaya ARAI on Twitter: "定期的に見る機会があるこの一覧、Linux系perfコマンドがひと目で分かるだけでなく、カーネルの構造についても復習できるので本当によい。 https://t.co/aNf5POIvYO https://t.co/9VgTyInybF"
                                                              • もしもvimを使っているときに記憶喪失になったら…

                                                                ここはどこだ 「あれ、なんの作業をしてたっけ?」 彼の名前はkoutarn、しがないタッチタイピング虚無僧。 今日も元気にお経を唱えながらコーディングをしていたのですが、 度重なるデスマーチのせいで軽く記憶を無くしてしまったようです。 「vimで作業をしていたんだけど基本的な操作方法以外思いだせない…」 おっと、彼はvimという 素晴しいエディタ で作業をしていたようですね。 ご都合主義なこの状況から彼と一緒にvimの操作方法を思い出してみましょう。 この記事の対象の方 ✅ この記事は以下の人を想定して書いています。 もの忘れが激しい人 vimって便利なんだけど覚える事が多いんだよなーって人 🚨 逆にこんな人は読んでもあまり意味がないかもしれません ガチで記憶をなくしている人 一度見たものは絶対に忘れないタイプの人 基本的なキーマップを思いだそう 「あれ、これデフォルトのキー設定と違うぞ

                                                                  もしもvimを使っているときに記憶喪失になったら…
                                                                • 無料でcronの設定を簡単に作成しカレンダーで可視化できる「Cron job editor」 - GIGAZINE

                                                                  cronはUnix系オペレーティングシステムのジョブ管理ツールで、タスクをスケジュール指定して定期的に実行させることが可能ですが、スケジュール指定の際に使用するcron式をすぐに読み取るのは難しいものです。「Cron job editor」はcron式を人間が読み取りやすいカレンダー形式に可視化してくれるサイトとのことなので、実際にどんな感じで使えるのか確かめてみました。 Cron job editor: multiple cron jobs, calendar view, AWS & Vercel cron support | CronTool https://tool.crontap.com/cronjob-debugger サイトにアクセスすると下図の画面になりました。左上にはUNIX系OSの「crontab」の仕様と、秒・年・ワイルドカードなどを加えた「拡張cron式」の仕様のどち

                                                                    無料でcronの設定を簡単に作成しカレンダーで可視化できる「Cron job editor」 - GIGAZINE
                                                                  • 遂にLinuxカーネルにRust言語のコードが取り込まれるとな - YAMDAS現更新履歴

                                                                    venturebeat.com 「Linux をてがけて30年経った今なお、リーナス・トーバルズは自身が作ったオープンソースのオペレーティングシステムとそれがこれからもたらすイノベーションの見通しに夢中である」という文章で始まる記事だが、先日開催された Open Source Summit North America を取材した記事である。 いろいろ読みどころはあるだろうが、やはりもっとも目を惹くのは、「Rust is coming to Linux」の見出しである。 実は、ワタシもこの話題を何度かこのブログで取り上げている。 Rustこそがシステムプログラミングの未来(で、C言語はもはやアセンブリ相当)なら、Rustで書かれたドライバのコードをLinuxカーネルは受け入れるべきなのか? - YAMDAS現更新履歴 2020年はLinuxカーネルにおけるRust元年になるか? - YAMD

                                                                      遂にLinuxカーネルにRust言語のコードが取り込まれるとな - YAMDAS現更新履歴
                                                                    • shell.how - How this shell command works?

                                                                      Explain shell commands using next-generation autocomplete from Fig.io

                                                                        shell.how - How this shell command works?
                                                                      • GitHub - ibraheemdev/modern-unix: A collection of modern/faster/saner alternatives to common unix commands.

                                                                        You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                                          GitHub - ibraheemdev/modern-unix: A collection of modern/faster/saner alternatives to common unix commands.
                                                                        • API越しでタイムスタンプをやりとりする時のフォーマットをどうするべきか - その手の平は尻もつかめるさ

                                                                          APIのリクエストにせよレスポンスにせよ、タイムスタンプを利用するというのはよくある話です。 この時、そのタイムスタンプのフォーマットをどうするのが良いのかという話題です。IDLを使って縛るというというのは良い考えだと思いますが、IDLを使うにせよフォーマットについては決めなくてはならないので。 1. 文字列を使う これあんま良くないと思うんですよね……というのも、とあるAPIを触っている時に「タイムスタンプはRFC3339です」というフィールドがあったんですけれどRFC3339ではないフォーマットで返却されたり受け入れられたりしたのであまり信用ができない…… まあフォーマットが不正というのは極端な例かもしれないですが、仮にフォーマットが不正だと多くの場合 strptime() や time.Parse() なんかの時刻文字列のparserが正しく動かず (良いケースだとエラーが上がる、悪

                                                                            API越しでタイムスタンプをやりとりする時のフォーマットをどうするべきか - その手の平は尻もつかめるさ
                                                                          • (ほぼ)無からのトラブルシューティング技法 - Qiita

                                                                            闇の魔術に対する防衛術 Advent Calendar 2019 16日目の記事です。 イントロダクション デプロイ自動化、コンテナ型仮想化、マイクロサービス化などが進み、トラブルシューティングの難易度が意図せず上がっているケースがあります。 日常の開発作業でアプリケーションの設定やアクセス経路をほとんど意識しない コンテナが軽量すぎて ps や netstat すら入っていない Infrastructure as Code (なおドキュメントは存在しない) ログ管理の基盤はあるが、欲しいログが収集されていないか、ログ以外を調べたいので役に立たない 今回は、こうしたケースで 対象システムに熟知していなくても トラブルシューティングを進めていく方法について取り上げます。 スタート あなたは Linux サーバへの SSH ログインに必要な情報を入手し、ログインに成功しました。なんと root

                                                                              (ほぼ)無からのトラブルシューティング技法 - Qiita
                                                                            • タイムゾーン呪いの書 (実装編)

                                                                              「タイムゾーン呪いの書」は、もともと 2018年に Qiita に投稿した記事でしたが、大幅な改訂を 2021年におこない、同時にこちらの Zenn に引っ越してきました。この改訂で記事全体が長大になったので、「知識編」・「実装編」・「Java 編」と記事を分けることにしました。 この「実装編」は、導入にあたる「知識編」の続きとなる第二部です。おもに Software Design 誌の 2018年 12月号に寄稿した内容をベースにしていますが、修正した内容もかなりあります。本記事全体を通して「知識編」を読んでいることを前提にしているので、ご注意ください。旧 Qiita 版にあった Java 特有の内容は、第三部にあたる「Java 編」にあります。 はじめに 先の「知識編」では、この時刻とタイムゾーンという厄介な概念について一般的な知識を紹介してきました。さて、ではこの知識を具体的に実装に

                                                                                タイムゾーン呪いの書 (実装編)
                                                                              • ファイルの編集と置き換えの違い または シェルスクリプトの安全な置き換え - mrwk update

                                                                                この記事の目的 unixでのファイルの編集と置き換えの違いをまとめます。 unix系OSでのファイルの編集と置き換えの違いについて説明する。 シェルスクリプトの編集により事故が起きる仕組みを理解する。 安全な置き換えの手順を理解する。 ファイル名→inode→ファイル実体の対応づけ UNIX系OSのファイルシステムは、「ファイル名→ファイル実体」という対応関係ではなく、間にinodeを挟んだ「ファイル名 → inode → ファイル実体」という対応づけを行っています。 inodeを経由した対応関係のイメージ 「ファイル名→inode」の対応づけは、ディレクトリエントリにより行われます。 ディレクトリ内でファイル名とinode番号の対応づけが行われていて、ls -iなどで確認できます。 「inode→ファイル実体」の対応づけは、ファイルシステム内部で行われ、ユーザからは隠されます。 inod

                                                                                  ファイルの編集と置き換えの違い または シェルスクリプトの安全な置き換え - mrwk update
                                                                                • 『UNIXという考え方―その設計思想と哲学』を読んだ - 30歳からのプログラミング

                                                                                  UNIX やそのツールはどのような考えに基づいて作られているのか解説した本。 UNIX が開発されていくなかで培われていった文化や考え方について書かれている。 www.ohmsha.co.jp UNIX が具体的にどのように動いているのかではなく、 UNIX はなぜそのように動いているのか、ということが主題。 そのため、 UNIX に限らずソフトウェア開発全般に適用できるような内容になっている。ソフトウェアだけでなく「ものを作る」こと全般に応用できる内容も多いかもしれない。 私も、現時点では UNIX そのものに対する熱意や探究心はあまりないので、 UNIX について知るためではなく開発の参考になる考え方がないかと思って読んだ。 9 つの定理が紹介されているのだが、まず思ったのは、「言うは易く行うは難し」という感じの定理ばかりだなということ。 例えばシンプルに保て、小ささを維持しろ、という

                                                                                    『UNIXという考え方―その設計思想と哲学』を読んだ - 30歳からのプログラミング

                                                                                  新着記事