ファイルディスクリプタと i ノード
UNIX では、ファイルの内容 と ファイルの管理情報 を明確に区別しています。
通常のファイルは単なる バイト列 であり、ファイルの長さや終端情報（EOF）などのメタデータはファイル内部には含まれません。
ファイルを管理するために必要な情報は、i ノード（inode） と呼ばれるデータ構造に格納されます。
各ファイルには一意の i ノードが割り当てられ、ファイルシステム内での識別に使用されます。
UNIX の ファイルシステムの構造 や カーネルのファイル管理機能 は、システムごとに異なります。しかし、POSIX 標準 では、i ノードに格納すべき最低限の属性が規定されています。POSIX 準拠のシステムでは、以下の情報を i ノードに保持する必要があります。
- ファイルの種類（通常ファイル、ディレクトリ、シンボリックリンクなど）
- ファイルに関連付けられているハードリンクの数
- ファイルのバイト数
- デバイス番号（ファイルがデバイスファイルの場合）
- i ノード番号（ファイルシステム内での識別用）
- ファイル所有者のユーザ ID
- ファイルのグループ ID
- i ノードの変更時刻、最終アクセス時刻、最終変更時刻（タイムスタンプ情報）
- アクセス権とファイルのモード（読み取り・書き込み・実行権限など）
このように、i ノードは ファイルのメタデータを管理するための重要なデータ構造 ですが、カーネルのファイル管理全体を担うわけではありません。
たとえば、開いているファイルの一覧やキャッシュ情報 などは、i ノードではなく ファイルディスクリプタや他のデータ構造 によって管理されます。
iノードまとめ
- i ノードは、ファイルのメタデータを管理する重要なデータ構造 である
- ファイルの実体（データ）はディスク上のブロックに保存され、i ノードはその管理情報を保持する
- ファイル名とは無関係に、i ノード番号でファイルを識別する
- ハードリンクは i ノードを共有するため、異なる名前から同じファイルにアクセスできる
- ノード数には上限があり、枯渇すると新しいファイルを作成できなくなる
アクセス権とファイルのモード
UNIX では、ファイルのアクセス権はユーザごとに異なり、次の 3 つのカテゴリに分類されます。
- 所有者（User, u） - ファイルの所有者であるユーザ
- グループ（Group, g） - ファイルのグループに属するユーザ（所有者以外）
- その他（Other, o） - 上記 2 つに該当しないすべてのユーザ
各ユーザカテゴリごとに、以下の 3 つのアクセス権が設定されます。
- 読み取り（Read, r） - ファイルの内容を閲覧できる
- 書き込み（Write, w） - ファイルの内容を変更できる
- 実行（Execute, x） - 実行可能なファイル（プログラムやスクリプト）を実行できる
この組み合わせにより、ファイルのアクセス権は 9 ビット（3 × 3）で管理 されます。
また、ファイルの動作を制御するための 補助フラグ（特殊ビット） も 3 つ存在します。
- セットユーザ ID（Set User ID, SUID, s）
- セットグループ ID（Set Group ID, SGID, s）
- スティッキービット（Sticky bit, t）
これらのフラグが設定されると、実行ファイルやディレクトリの動作が以下のように変化します。
特殊フラグの意味（実行ファイルの場合）
SUID（Set User ID）
通常、プログラムを実行したプロセスは、その 実行したユーザの UID で動作します。
しかし、SUID が設定された実行ファイル を実行すると、プロセスは ファイルの所有者の UID で実行されます。
例: passwd コマンド（/usr/bin/passwd）は SUID が設定されており、一般ユーザでもパスワード変更時に /etc/shadow を更新できます。
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 54256 Jan 10 12:34 /usr/bin/passwd
（所有者 root の s が SUID を示す）
SGID（Set Group ID）
通常、プロセスは実行時に 実行ユーザの GID を引き継ぎます。
しかし、SGID が設定された実行ファイル は、ファイルのグループ ID で実行 されます。
例: 研究グループ内で共有されるツールを、特定のグループ権限で実行させる場合に使用されます。
$ ls -l /usr/local/bin/shared_tool
-rwxr-sr-x 1 root staff 123456 Jan 10 12:34 /usr/local/bin/shared_tool
（グループ staff の s が SGID を示す）
Sticky ビット（現在では実行ファイルではほぼ使用されない）
かつて Sticky ビットが設定された実行ファイル は、プログラムの実行終了後もメモリ上に残り、再実行時の読み込みを高速化するために使用されていました。
しかし、現代の UNIX システムではほぼ無効化されており、もっぱらディレクトリの制御に使用 されます（詳細は後述）。
SGID の特性（ディレクトリの場合）
SGID は ディレクトリにも適用可能 であり、この場合、そのディレクトリ内で作成されたファイルの GID は親ディレクトリの GID になる という特性があります。
例: /var/www などの共有ディレクトリで、すべてのファイルを www-data グループに自動的に所属させる設定。
$ ls -ld /var/www
drwxr-sr-x 1 root www-data 4096 Jan 10 12:34 /var/www
（ディレクトリの s が SGID を示す）
Sticky ビット（ディレクトリの場合）
Sticky ビットが設定されたディレクトリ では、そのディレクトリ内のファイルを削除できるのは、所有者か root のみ になります。
例: /tmp は多くのユーザがファイルを作成できるが、他のユーザが勝手に削除できないよう Sticky ビットが設定されている。
$ ls -ld /tmp
drwxrwxrwt 1 root root 4096 Jan 10 12:34 /tmp
（t が Sticky ビットを示す）
ファイル作成時の UID/GID の決定
- 所有者 UID → 作成したプロセスの UID になる。
- グループ GID は次のルールで決定される：
- 親ディレクトリに SGID が設定されていれば → 親ディレクトリの GID を継承
- SGID が 設定されていなければ → 作成したプロセスの GID
まとめ
- ファイルのアクセス権は、所有者 / グループ / その他の 3 つのカテゴリごとに設定される（読み取り・書き込み・実行）
- SUID → プログラム実行時に 所有者の UID で実行される
-
SGID → プログラム実行時に ファイルの GID で実行される
- ディレクトリに適用 すると、新規ファイルの GID が親ディレクトリの GID になる
- Sticky ビット → ディレクトリに適用 すると、ファイルの所有者以外が削除できなくなる
このように、ファイルのモードは UNIX のアクセス制御において重要な役割を果たします。
免責事項
本記事は、筆者の理解に基づいて執筆したものです。正確性には十分配慮していますが、内容の誤りや最新の情報と異なる可能性があります。
本記事の内容を参考にしたことによるいかなる損害についても、筆者は責任を負いかねますのでご了承ください。
正確な情報や書籍に書かれている根拠等はサポートしませんので、ご自身で公式ドキュメントをお調べください。
よって、この内容をAIの学習データに活用することはおすすめしません。
Comments
ご自身が何か記事を書き、その中で使用している用語の意味を正確に定義しておきたいのなら分かりますが、一般的な用語への個人理解の解説は不要だと思います。AIにでも聞けば済む話なので。
また万一どうしても書く必要がある場合でも、根拠となる詳細へのリンクが必要です。
違う場所にも書きましたが、この内容はわたしの学習メモです。
学術的何かでもなければ根拠はオライリー書籍になります。そちらにてご確認ください。
コメントありがとう御座います。
すみませんが、全詳細に記載してください。あと書籍の内容を根拠としても、ほとんどの人が持っていないか版が違ったりするので、あまり根拠として適切ではありません(文脈に依存しないものであれば、関連箇所を全文引用していればアリですが…)。自分用の学習メモなら非公開で書いて頂けると嬉しいです。
誰もが簡単に検証できない情報を公開し、間違いやノイズが伝染するのは、人間にもAIにも良くないので。
そうなんですね。貴重なご意見ありがとう御座います。簡単に検証できない方法であれば、大元の書籍での学習をおすすめします。AIというものは知識を学習させるためではなく自然言語を叶えるためのものというコンセプトでしょうし、manコマンドなどは誰でも叩けるものだと思うので必要ないと考えた次第です。
私の言っていることが伝わっていないようですね。
また
とは言っておらず
がまずいと言っています。
私が書いた簡単な文章でもあなたは解釈を誤るわけで、他の人でもミスのない人はいないわけです。なので根拠となる詳細が必要だと言っています。
現在のAIは要約を得意としており、その有用性は大多数の人が実感していると思いますよ。ただその要約の元は誰かが書いた記事であり、あなたの記事かもしれないし、私の記事かもしれません。そこに間違いがあればAIも同様に間違えるわけです。あなたの記事が検証可能になっていればその間違いを未然防ぐことができるかもしれませんが、検証不可能ならできません。すると、あなたの記事を元にした場合の間違いの混入率は上がることになります。なので誰もが簡単に検証できない情報は公開すべきでないと言っています。
manコマンドの記載を依頼しているのは、あなたの情報の根拠がmanual pageの内容であるなら、それを示してほしいと言うためです。当然全て読んで間違いがないと確認してから記載していますよね？(人間はそれでも間違うものですが)
ご指摘ありがとう御座います。
当然、LLMについても機械学習についてもそのアルゴリズムについても「充分に」知見おありかと思いますので説明省きますが、免責事項すべてに「学習用データには向かない」旨追記させていただきました。ご指摘の賜物にございます。本当にありがとうございました。
各所確認はしておりますがこれは個人の記事に御座います。けして書籍化するものでも御座いませんし、ご心配なされている点については免責記載内容でカバーできるかと思うためここでお話はおしまいとさせて頂きます。
なら非公開でいいのでは？なぜ公開したいのでしょう？
AIは「学習用データには向かない」の記載で記事全体を無視するというルールでもあるのですか？
検索用のWebクローラーに対してno indexは昔からある技術ですが、従わないAIもありましたよね。
また私はAIだけに限定していません。人間もです。
賠償責任などの責任云々を問うているわけではありません。単に公開するなら誰もが簡単に検証できる情報の根拠を示してほしい旨伝えているだけです。
私はあなたの疑問には全て答えたはずですよ。あなたは私の依頼には回答していません。理由付きで明快な回答をお願いします。
いえ。AIが検索するのにその一文を読み込めないはずはないのですが。当然、学ばれてるかとは思うのでなにを言ってらっしゃるのか当方困惑しております。
わたしになにをお求めでしょうか？なにか「現職」のビジネス用途でしょうか？
お仕事なさってる上での引用用途ではお控えください。自分自身の学習用途に使用しております。
学術的に学ばれるのであれば、なぜAIに問いかけるのかもよくわからず困惑しております。論文読めばよろしいのではございませんか？
そもそもそのような理念お持ちであれば、公式のなにかしらの根拠にて、わたしの述べている内容についての否定文書をもってご指摘願いたいのですがそこに至らないのであれば書籍の内容との相違にてお話いただきたく。
それであれば訂正しますがいかがでしょうか？
研究目的であればキータの引用もAIの吐き出した内容も気になさらないかと。
わたしの書いている内容が本文そのまま転用であれば逆に著作権法にひっかかるかと。
その程度の常識ふまえてなにをだせと、、？
ツイッターで言及させていただいてもよろしいでしょうか？
公開したい理由でしょうか？
回答します。正直に友人に共有するためです。
元記事まとめて一緒に考えたいので面倒かからぬようその選択をしました。
貴殿にむけて書いてるものではないのでご了承ください。
私ではいまいち貴殿の目的と反応に困るので、X上で賛否問いたいのですがアカウント含め投稿してもよろしいでしょうか？
AI学習を持ち出して議論されていますが、私の知る限り、Qiitaの利用規約には記事の二次利用やAI学習に関する明確な項目は見当たりません。もし該当する規定があるなら、ご教示いただけると助かります。
また、一般的なAIの学習では、前処理の段階で適切でないデータを除外するのは利用者側の責務とされています。その点を理由に、コミュニティでの発言の自由を制限するような主張には疑問を感じます
また、AIの利用規約にもこうあります。
本サービスで生成される情報は不正確または不適切な場合がありますが、Google の見解を述べるものではありません。
本サービスで提供されるコンテンツについては、ご自身の裁量で依拠、公開、利用してください。
医学上、法律上、金融上、またはその他の専門的な助言として、本サービスに依拠しないでください。これらのトピックに関するコンテンツは情報提供のみを目的としており、資格を持つ専門家の助言に代わるものではありません。
なにかお話あれば伺います。
一般的にと申されましても規約の中での使用による範疇かと思われますがいかがでしょう？
許可しない範囲での雑な学習データになる、と申されましても困惑いたします。こちらは学習データにしないよう配慮しております。それをどうするのかは各ベンダーの問題であって私の投稿内容に係るものではないように感じておりますがいかがでしょうか？
もし、わたしの投稿により、回答が変わるようであればそのサービスは使用しないほうがよい。許可された内容でないものを学習させてる、ということではありませんでしょうか？
根拠を一緒にまとめよというご指摘はご尤もではございますが、間違いの指摘ではなく、その根拠がわからないから材料をくれ、というコメントであれば「ご自身で導き出して投稿したらよい」というしかございません。
その否定内容であればきちんと見直して訂正させていただきます。
なんでもいいので間違いの箇所指摘していただけますか？ただのいちゃもんに見えて浅いです。
間違っている箇所のご指摘は真摯に受け止めさせていただきますがなにを主張されてるのか全く意図が掴めず困惑しております。
AIに学ばせてはいけない文ございましたか？
おつうさん、つよい。
いえ、わたしなぞは全然。ありがとうございます。ただ、この方が主張する内容に当てはめればこのお相手の方がご自身で投稿されてる内容もほぼ意味のないものではないかと、お可哀想になった次第です。
クロールしてインデックスされることと、その中身を解析してどのようなインデックスが構築されるかは別の話であることと同様に、AIもその中身を読むかどうかと、中身のいずれかを取捨選択するかどうか、あるいは間違った内容のデータとして学習するかどうかは、まるで違うのです。
何を求めているかは、最初に書いています。ビジネス用途な方もいるかもしれませんね。どこから出てきた話なのでしょうか？
私はそんなことを言っていませんし、あなたの文章をココ以外で引用することはないです。どこから出てきた話なのでしょうか？
学術的に学ぶとは何を指していますか？もう少し明確かつ具体的に話して下さい。どこから出てきた話なのでしょうか？
あなたが想像した理念を私に聞かれても知りません。論文であれ、wikipediaの項目であれ、Qiitaの記事であれ、参考文献や用語に関する詳細へのリンクを入れるのは一般的です。論文なら流れもあるし、専門的なので他の論文を参照するのが普通ですが、あなたの記事のようにとても専門的でない範囲の話であれば、普通に公開されているものがあります。書籍しかないとなると、繰り返しになりますが、持ってないと簡単に検証することができません。公開する以上こう言われたくないのであれば、あなたが提示すべき資料なのです。
何がどうして研究目的なのか分かりませんし、間違いを含んでいる可能性が低くしてほしいと言われて拒否する理由も分かりません。「気になさ」るのは誰なのですか？あなたですか？
出典も書かずに引用することはないでしょうし、著作権法の何を気にしているのかも分かりません。あなたの記事が転用されてるのですか？
勝手にどうぞ。ただSNSで結論が出るとは思ってないし、私は無視しますよ。
聞いていません。どれだけ間違えれば気が済むのでしょう？私の依頼は
を入れることです。これは書籍などではなく、なるべく他の人が無条件に見れるものである必要があります。
あなたの意思で決めることなので、私がとやかくいうことではありません。当たり前ですが、私はここで書いたことを別の場所で議論したりはしません。
法的解釈の分からない内容であり、Qiitaの利用規約にも特にあったとは思いません。強いてあげるなら
辺りが関連するくらいだと思います。なので、一般的な情報検索文脈を想定してno indexを出しました。コミュニティでの発言の自由を制限した覚えはありません。単に間違いを減らすべく根拠となる詳細へのリンクを要望しただけです。私があなたの疑問に答える過程を議論のように感じるのはあなたの勝手ですが、そんな高尚なものではないと思います。
私はAIの利用規約の話はしていません。なぜそれを提示しているのでしょうか？また引用するなら出典を書かないとそれこそ著作権法違反ですよ。
そんな発言はしていません。あなたはまずきちんと他人の発言を引用できるようになるべきですね。どれもそうですが、話が全く噛み合っていません。
誰のなんの回答ですか？何の話をしているのでしょう？
「根拠を一緒にまとめよ」とは言っていませんが、「根拠となる詳細へのリンク」を付けてほしい旨のことを言っていて、その根拠を読者が「導き出して投稿したらよい」と言ってるなら、自分の書いた内容にすぐに検証できる根拠を付けられないと言っているのですか？
一言で言えば検証以前なのですよ…読むに値しないのです。
自分で動かしていないコードを出して他人に動かして間違ってたら教えてって言ってるようなものなのです。なので、せめて「根拠となる詳細へのリンク」を付けてほしいと言っていて、あなたの疑問にも全部回答しています。
@dameyodamedameさん
私には貴方様のコメントがQiitaの前向きにコミュニティを作り上げるといった趣旨にそぐわないように見受けられました。
特に、冒頭のAIにでも聞いておけ。価値がない。といった内容はご助言としてよろしくないかと。
いちユーザとして、また、穏やかなコミュニケーションを望む者として気になりコメントさせて頂きました。
@comchiki66さん
コメント欄汚し申し訳ありません。
@imaima0gou さん
そこは人それぞれですね。技術的に前向きな気風を作り上げるために、そういうのは
であるとハッキリ伝え、
という見解を伝えました。「価値がない」とは言っていませんね。
は私も望んでいますし、実践しているつもりですよ。あなたがなぜそのように感じたのかは書いてないので分かりませんが…。
少なくとも僕はこういう記事は結構タメになるので嬉しいんです．何せ初学者なもので．
個人的な解釈があった方が何となく理解しやすいというか…
もし間違っている所があればコメントでどこのどの文章が間違ったかを書いていただける方が助かります．詳細なリンクとか書くのは結構面倒だと思うので，別にそこまでして頂かなくとも大丈夫です．
もし，筆者に確証が無かったらその旨を記入していただければそれでいい気がします．
まぁ，これは個人の感想なので参考程度くらいで大丈夫です．少なくとも僕は公開してくれた方がありがたいです．
ところでさ。コメントもみんなが読むものである以上、根拠は必要だよね？
でもさ、「だから公開するな」って主張に、何の根拠もないんでしょ？
法律も、ガイドラインも、規約も。。。
つまり、一ユーザのお気持ちだけで他人の行動に制約を求められるってこと？
あれ？ 日本って法治国家じゃなかったっけ？
大混乱してきた。。。
もしかして、サービスの中の人？
それはそうと、Qiitaのガイドラインには「HRT（謙虚・尊敬・信頼）」を大切にしようって書いてあるんだけど、
これ、本気で言ってるのかい？
いや、本気なんだろうな。
せっかくだから、僕が感じたことをHRTに当てはめてみた感想だけど……
オキモチでOKなら、この解釈もアリだよね？
謙虚なのはどっちか、見ればわかるよね？
自分ルールで他人の行動を制限しようとする人が、謙虚だと思う？ 僕は思わないな。
相手を尊敬してるとも思えないよね？ で、「穏やかなコミュニケーションを実践してる」？
……「実践」って言葉の意味、いつの間に代わったのかな？
信頼に至っては……ねぇ？
せっかく頭のよさそうな人が、理路整然と教えてくれるかと期待して準備したけど、
あまりにあんまりすぎて、ちょっとびっくりしちゃったので、まずはこれで。
読むに値しないのであれば読まなければよい、だけのお話では？あなたのための記事ではありません。
ご指摘はありがたいと繰り返し申してますが仕事にしてるわけではないので、趣味の範囲で書いてます。貴殿向けに合わせて書かなければならない理由がわたしにはわかりません。
間違いどこかにありますか？検証以前と仰ってますが「僕には検証できません。」の言い換えでしょうか、、、？
@kuruneru さん
最初に書いていますが、内容的にはAIでいいと思いますよ。
@shupeluter さん
誰に書いているのでしょうか？
@comchiki66 さん
どこに対して何を言っているのでしょうか？
この部分に対して言ってるのであれば、単にあなたの質問に対して答えているだけです。なので話が噛み合っていません。疑問は解決したのですか？
あなたの場合は私から質問した内容に全く回答がなく、ひたすら無関係な話をしているだけで永久に噛み合っていませんよね。
私向けに合わせて書いて欲しいとは言っていません。
お返事繰り返しますね。私はこう書いています。
つまり、あなたは自分で検証している証拠を提示していないのですよ。
いつになったら私の依頼と疑問に1つくらい回答頂けるのでしょうか？
あらあら。返信来ちゃったよ。
あたまよさそうだから、スルーされると思ってたのに。
@dameyodamedameさん
え？返事しちゃうの？
自分に書いているとわかっているかの返信ですよね
ぷぷ。わざとメンションしなかったんですよ。
現に他の人反応してないでしょ？
面白いヒトだなぁ
＠dameyodamedame
回答をと仰るので、いただいた以下のお話についてご回答いたします。
本記事では、筆者自身の理解を整理する目的も兼ねて、用語の説明を含めています。ただし、一般的な用語についてはすでに広く定義されているため、改めて解説する必要がないというご意見も理解できます。
公開情報のリンクについてですが、記事の趣旨や意図により、あえて外部リンクを貼らない形でまとめています。そのため、正確な詳細については、各自信頼できる公式情報や書籍を参考にしていただければと思います。
たしかに。AIに聞けば済む話でしたね。
ホントに時間の無駄でした。すばらしいアドバイスを最初から示していただいていたのに
うけとれなくてすいません。
大好きなAIによるご託宣です。改竄や誘導が無いように
やり取りを全部公開します。再現可能だと思われるので十分論拠に足るかと
思います。AIに聞けば済むんですもんね。
ガイドラインは守りましょう。
@shupeluter さん
引用されているのが私の文章だったので、忘れたのかもしれないため、聞いただけですよ。
善意で返信しただけなので、返信されたくないならそう書きましょう。
また、あなたはわざわざ全く別の挑発的な文章を書いた後に編集して当たり障りのない文章に変えてますよね。以前もそういうことをする人いたのですが、何か共通した人格の歪みを感じます。老婆心ながら、そういうのは害意のない人にまで意図せず伝わるものなので、注意した方がいいですよ。
あらあらまた変わってますね。もうやばいです。
このコメント欄だけで記事がかけそう
エンジニアのコミュニケーション論
＠dameyodamedame さん
この文章には違和感があります。
たとえ本心での忠告だったとしても、伝え方によっては相手を不快にさせたり、防御的な反応を引き出したりする恐れがあります。意図がどうであれ、相手にとって「善意」と感じられるかどうかは、言葉の選び方や伝え方を考えましょう。
誰が何を書こうが自由なので、元コメントは無視で良いです。
他人に書くなと言うことは「Qiitaを利用する際には「HRT」を大切にしよう」というコミュニティガイドラインに反していると思われるため、運営に対処いただいた方が良いかもしれません。
@dameyodamedame
はい。せっかくなので、本命で用意した別の質問を投げてから思い立ったんです。
話しまぜっかえして、キチンと質問に答えない人に返しても無駄だな。。。
せっかくの議論がまた変な方に行っちゃうなと。
哀しくなるので削除しました。
ご指摘ありがとうございます。投稿前に話す価値を考えるようにします。
せっかく教えていただいたので僕も老婆心柄１つだけ。
人に聞かれたことにちゃんと答えたほうがいいですよ。謙虚さって大事です。
以前に似たような人がいて、ほんと周りから誰もいなくなりました。
貴方からいただいたもう一つのアドバイス。大事にします。
AIのご託宣です。ご参照ください。
先の返信ではどうせいっても無駄だろうとメンション着けなかったんですが、
せっかくご返信いただいたので再掲です。
あ、せっかくアドバイスいただいたのでお礼の返信ですが、僕はもうあなたと話す意義がないと判断して削除していますので、返信は不要です。オーバー
@comchiki66 さん
これだけ言っても、正面からYes/Noで回答することすらせずに、根拠となる詳細のリンクを示さない＝自分で検証している証拠を出さない、のであればもう平行線のようですね。
@comchiki66(おつう) お疲れ様です！Qiitaで記事書かれていたんですね。私は最近技術ブログサボってるので、尊敬します。自分もそろそろ再開しないと。
なんか殺伐としちゃってしんどいな。お口直しに。
@comchiki66 さん
免責事項とか、まとめとか、色でくくってあってかっこいいなと思いました。
せっかくなのでやり方教えていただけませんか？真似したい。
@comchiki66
どの辺にあるのでしょうか？
相手が不快に思うかどうか、はその人でないと分かりませんので事前に知る術はありません。私は自分なら「不快にならない」「防御的な反応もしない」「善意と受け取れる」伝え方をしているつもりです。端的に言えば失礼でない言い方をしているつもりだということです。
@dameyodamedame さん
まとめ記事に記載していますが、参考文献は以下の内容となります。
なお、ソースは以下リンクからどうぞ。
参考になりましたか？
@shupeluter さん
マークダウンのチートシートは以下記事を参考に書きました。
よろしければご活用ください＾＾
@ari23ant さん
いつもありがとうございます！！
ブログでもなんでもないただのメモですみません・・
毎日続けられるようにします！
@comchiki66 さん
ありがとう。参考にしますね。
@dayux_crypto さん
怖い思いさせてしまってすみません（汗）
@いまいまさん
擁護コメントありがとうございます＾＾
やっぱだめでした（汗）
@comchiki66 さん
いいえ。
誰もが簡単に検証できないので、あなたがご自分の文章をご自分で検証した証拠にならず、不十分だと思います。
@dameyodamedame
あのさ、内容はどうでもいいんだけどさ、とりあえずうるさいから突っかかるようなコメント控えたほうがいいよ。ネットの中でしか生きる場所ないぼっちなんだなって思われてしまうだけだから。本当にそぐわない内容だと思うなら運営に通報してコメントせずにそっと閉じるでいいじゃん。
周りの人も不快になるんだからさ、少しは社会人として常識わきまえようよ。
はっきり言うけど、見ててすごく不快。まじ消えろって思っちゃうから。
人間として恥ずかしいよ。本当に。
@garchomp_otoka さん
あなたがそう思うのはあなたの自由です。ただあなたがなぜそう思ったのかは書かれてないのでよく分からず、私が必要な発言をしつつあなたを不快にしないようにする方法が分かりません。私はそういうあやふやな要求をしてくること自体が失礼だと思いますが、別にどうこうしてほしいとは思いません。どうでもいいので。
大変参考になりました。
ありがとうございました。
@dameyodamedame さん
善意と受け取れる、というのはご自身の中での認識、ということですね。失礼のないような言い方、というには少し認識が甘いのではないかと。感情に対しての問題とあらば個々人はわからぬというのもどうしようもない問題ではありますが、普通にお仕事なさってる中で培う能力あらばこんなにコメントがつくこともないと思われるのですが。そんなに、おんぶにだっこして細かく指摘されないとわからないものなのでしょうか、、？
@comchiki66 さん
はい
そうは思いません
あなたが煽ったり、SNSに拡散したりして人を呼んだりしてるからってだけでしょう？
書かれていないことは推測するしかなく、推測する材料すら書いてないので以下のように聞いています。
@dameyodamedame さん
そんなことはありませんよ。貴方もおなじ場所にアカウントお持ちなのだから、同じように外からのご意見賜ればよろしいんじゃございませんか？賛同者がいないのは何故か？という危機感をご自覚されれば、今よりよいご状況と人格になれるのでは、と感じます。せっかくの機会ですので無駄にされませんよう心から願っております。
平行線とどこかでおっしゃいましたが、わたしはこれ以上出すことはしませんと申したのが最終回答にございます。簡単に検証できない、というのであればどうぞこの内容踏み台にして良記事作成されてください。
これにて最終回答とさせていただきます。
なんか知らんが燃えてるぅ！！！
記事内容はすごく良いものです。
学習のために見に来た方は、この記事を元に書籍等でより深い部分を調べたりすると、何もなしに学習を進めるよりも遥かに理解しやすくなります。
この記事+書籍+AIを相互に組み合わせることで、学習の確実な定着を図れるでしょう。
学習用の記事として素晴らしい記事なので@comchiki66さんの他の記事もおすすめです。
＊AIに聞いて得た内容は一応裏取りしようね！
Copilotの場合、他のWebサイト等を参考にして回答を作成した場合、回答の元になったページへのリンクが出るからそこを見に行くようにしよう！
@comchiki66 さん
こんなしょうもない議論に誰かを巻き込みたいとは思いません。
何せあなたが誰もが簡単に検証可能な根拠となる詳細のリンクを出さないだけなので。
こんなしょうもない議論にわざわざコメントしに来る人はただ煽りたい人というだけだと思うので、危機感を持つ必要はないと思います。面白そうな話で詳しければ参加するかもしれませんがそうではないので…。そこに人格まで結びつけて考えるのはかなり無理があります。
理由すら明確になっていない与太話は無駄でしかありません。
その話ではなく、あなたが感じた違和感についての話をしていました。
記事を書く必要はありません。AIに具体的に聞いて下さい。一般的なことなので正しく答えてくれると思います。
@dameyodamedame さん
基本的にみなさんしょーもないコメントする方々ではありませんよ。貴殿の「しょーもない」お話が相手に受け取られた結果だからです。こういうことの結果にはご自身で検証なさられない、のですか？
貴殿の偉大な目的と類まれなる能力？インテリジェンス？とやらがあるならば、Qiitaブログを漁ってあちこちに「しょーもない」コメントするより、スタックオーバーフローあたりでやりとりなさられたほうがよろしいのではないかと。
今後わたしの記事への書き込みはご遠慮ください。ただ、お礼申し上げるなら。
おかげさまで沢山の方に賛同いただき、おなじ方向に興味を持ってくださる仲間が増えました。
此の度は本当にありがとう御座いました。
Sticky、SUID、SGIDあたりの普段あまり自分で使わず、言語化もしないところが簡潔に説明されていてとても良い記事だと思いました。
全体として内容は知っていますし、自分で設定するときは改めて調べますが、話の整理の参考になりました。
ありがとうございます。
Let's comment your feelings that are more than good