arashi1977さんの助け合いフォーラム投稿一覧

助け合いフォーラムの投稿

2024/07/16 コメント

SaaSやPaaSも正解になりませんでしょうか。

意図がないなら結構です。通常、相手の名前を当人に見せる形としては見ない書き方ですし、何か意図があるのだろうと思って聞いてみたかったのです。気に障っての質問だと解釈されたのであれば、大変失礼いたしました。

2024/07/15 コメント

SaaSやPaaSも正解になりませんでしょうか。

この問題についての会話はここで終わりという意図だと理解しました。問題ではない点について1点確認させてください。 > 「arashi1977」様、お時間いただき、ありがとうございました。私のアカウント名を括弧で括った意図はなんですか？

2024/07/15 コメント

解説とAIでの相違

どちらが相応しいかというのは、「Ping-tさんの解説ではなくAIを信用したいが言っている事が毎回違うので困っている」ということを言われているのでしょうか？ Ping-tさんの解説自体であればまだ参考URLなどもあるので考えようがあるのですが、AIの解説については解説を生成したAIの開発元にしか相応しいかを答えることはできないのではないかなぁと思います。（どういうデータでどうトレーニングしたかとかにも関わりますし、開発元も答えられない様な気もしますけどね… ^^; ）

2024/07/15 コメント

SaaSやPaaSも正解になりませんでしょうか。

２の観点だと余計に「最上位」で考えることになるかと思います。 AWSをでメールシステムを立ち上げようとする場合、利用できる製品（サービス）を考えるとたとえば - EC2: IaaS - SES: PaaS - Workmail: SaaS が候補に上がりますが、それぞれこうなりますよね。 - EC2: サービスとして利用しているのはコンピューティングリソースであり、OSを含めたメールシステム自体は自分達で構築して運用する。 - SES: サービスとして利用しているのはメール送受信のシステムであり、コンピューティングリソースやOSはサービスとして利用していない（したくても触らせてもらえない）。 - Workmail: サービスとして利用しているのはメールアプリであり、メール送受信システムやコンピューティングリソースやOSはサービスとして利用してない（したくても触らせてもらえない）クラウドサービスを利用して開発するエンジニアであってもSESとEC2では利用するサービスが異なっているので、エンドユーザーと同じ考え方になるかと思います。そういう見方で、Workmailが「仮想化されたインフラ環境」をサービスとして提供しているかと言われたら、なんか違うんじゃないかなぁというのが私の認識です。サービス提供にあたって必然的に提供者が用意すべきものを「利用者に提供されたサービスだ」と言われると「タクシーの車両自体が利用者に提供されたサービスだ」と言われて「でも利用者が運転できるわけじゃないよね…？」って思うような違和感なのです（レンタカーならわかる）。逆に、この文脈で「サービス」といったときに「裏に存在するすべてを含めてがサービスだ」ということだと、たとえば - 屠畜場：牛を枝肉にするサービスを提供する - 肉屋：仕入れた枝肉から部位ごとに切り出して食用に利用できるよう加工するサービスを提供する - 惣菜屋：食用肉を含め、仕入れた複数の素材をもとに惣菜へ調理するサービスを提供するの関係で晩御飯のおかずに惣菜を入手して食卓に並べるというときに「いち消費者の観点だと提供されているサービスは惣菜（調理）だが、料理人の観点では享受しているサービスは枝肉にする作業と食肉に加工することと惣菜へ料理することだ」っていっている様に聞こえてなんかしっくりこないイメージがあるんですよね。（わかりにくい例だったらすみません…）「目の前でまさに触っているもの」を「サービス」と表現するのでは不足していて、「直接関わりがない裏側も含めたすべて」を「サービス」とするべきだというお話であれば、私からはこれ以上コメントできることはなさそうかなぁと思っています。

2024/07/15 返信

SaaSやPaaSも正解になりませんでしょうか。

問題文を見ると

仮想化されたインフラ環境をサービスとして提供

とあるので、「インフラ環境」を「サービス」として利用できるか、というのが重要な観点かと思います。SaaSアプリケーションの一例としてですが、オンライン版のMicrosoft 365を利用するにあたって、メールを送受信したりWord/Excel/Powerpointなどのファイルを編集することはできても「サーバ、ストレージ、ネットワーク等、仮想化されたインフラ環境」は直接利用できないですよね。どこのネットワークに配置されたどのようなスペックのサーバで動作するかとか、それはクラウド側が管理しているものであって、サービスとして提供されているのは「アプリケーション」なのですよね。

「クラウド事業者が何を提供しているか（ユーザーが何を用意しなくていよいか）」ではなく、「サービスとして利用しているものは何か」というのがこの問題で扱っている「クラウドのサービスモデル」の内容かなと思います。

2024/07/15 コメント

SSH設定

show runのどこにもvrfの設定がないのにそれで解決されたのも不思議ですが、まぁ解決したのなら良かったですね。あと > そんなときはスルーするのをお勧めします。。。とのことですが、この助け合いフォーラムって https://mondai.ping-t.com/g/contents/faq > 最強WEB問題集について > ・どうしても分からない問題があります。 > 助け合いフォーラムでご質問ください。と、Ping-tさんの最強WEB問題集に取り組む中での疑問解決が目的の場所だと理解してるので、「なんだかよくわからんがなんぞこれ？」っていうものにコメントしたまでと捉えていただければそれで良いかなぁと。以前はマジで「業務に関連する設定の質問」としか思えないようなものもあったのもあって一応確認してるだけなので、まぁ「そういう考えのやつもいるんだな」ってな感じでスルーしていただいても全然問題ないですよ。

2024/07/14 返信

SSH設定

このshow runやその他の出力からではほんとに現在SSHできてるかわかりませんし、試験学習やそのための実機確認に関するものにも思えないのでここで質問するのが適切かを考えるところからかなぁという気がします。

2024/07/14 返信

解説とAIでの相違

私が試したときは以下のように回答があったので「どういうことだ？」と思って何回かやったら、違うパターンの解説が来ました。

最初にやった時の解説冒頭

IPv6のグローバルユニキャストアドレスに関して、「前半64ビットはIPv4のネットワークアドレスに該当する」という選択肢が正しい理由を詳しく見ていきましょう。

IPv6アドレスは、128ビットの長さを持ち、これをさらに2つの主な部分に分割できます。次の点を確認してみましょう。

別の解説

すみません、「C. 前半64ビットはIPv4のネットワークアドレスに該当する」が正解であるとの説明は間違っています。「C」は実際には不正解です。正しい情報を提供するために、以下で詳しく説明します。

おそらくここで使用している（Generative）AIは基本的にいろんな情報を集めてきたものの中から質問にマッチしそうなものをピックアップしてそれらしく回答を生成したりするものですし、まさにAI Assistantの利用に書いてあるこの部分に遭遇したのかなと思います。

*AIは間違えることがあります。

2024/07/14 返信

模範解答の正当性について

白本持ってないので白本の内容に疑義があるならそちらの発行元にお問い合わせいただくのが良いかなと思います。
それはそれとして。

PVST……PVSTはISLでカプセル化されたBPDUを使用して（以下略）

PVSTはISLはCisco独自のカプセル化方式（ISL）を使うSpanning-treeの実装であり、IEEE標準の実装ではない

PVST＋……PVSTではISLを使用することが前提となっています。これをIEEE802.1Qに対応させたのもが、PVST＋となります。

PVST+はPVSTの実装のうち、使用するカプセル化のみをIEEE 802.1Qにしたものであり、Spanning-tree実装としてはCisco独自のままでカプセル化のみIEEE 802.1Qに変更したものなので、Cisco独自と言える

という話だと解釈しましたが、どうでしょう？

2024/07/09 返信

ネットワークACLのアウトバウンドルールの「ポート範囲：すべて」の理由

TCPの通信ではサーバ、クライアント双方が特定の「ポート」を使用します。
サーバ側は特定サービス（HTTPなら80、HTTPSなら443とか）がわかっていますが、クライアント側ポートはOSが自動的に割り振るためどのポート番号になるかは特定できません。

https://xtech.nikkei.com/it/pc/article/NPC/20070621/275460/

クライアントソフトも通信の際にはポート番号を利用します。サーバーソフトと異なり、通信を始める際に、空いている番号をOSが自動で割り当てます。クライアントがサーバーにアクセスしたときに、クライアントのポート番号が伝わります。そのため、クライアントのポート番号は自動で決めても問題ないのです。

なので、アウトバウンド（＝クライアント向け通信）の宛先ポート番号の範囲は「利用可能なすべて」を指定しないといけないんですね。

まぁそういう意味だと、クライアントのIPアドレスも不定なので全てを意味する 0.0.0.0/0 になってるわけですが。

2024/07/08 返信

「show interfaces trunk」について

コマンドリファレンスに記載があるので、使えるんじゃないですかね？
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/command/ir-cr-book/ir-s4.html#wp4112214085

2024/06/30 返信

コマンド誤記

どちらも間違いやミスではないですよ。

Router#show running-config vrf
Building configuration...

Current configuration : 388 bytes
ip vrf SAMPLE
!
!
interface GigabitEthernet0/0
 ip vrf forwarding SAMPLE
 no ip address
 shutdown
 duplex auto
 speed auto
 media-type rj45
!
vrf definition SAMPLE2
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
!
interface GigabitEthernet0/1
 vrf forwarding SAMPLE2
 no ip address
 shutdown
 duplex auto
 speed auto
 media-type rj45
!
!
end

じゃあ何が違うの？というとIPv6対応かどうかです。
ip vrf forwarding は IPv4 にしか対応せず、 vrf forwarding は vrf definition で定義してあれば IPv6 にも適用されます。
おそらく IPv4 のみ対応の形式で設定された古いルータ向けに残ったままなのかなぁと思います。

2024/06/27 返信

「GUIのみで管理できる」の正誤判定について

確かに日本語の話ですねぇ。
「管理できる」→「操作できる」なら良さそう？

2024/06/27 コメント

ハードリンクはディスク容量を消費しない？

> ほぼ解決済みで、いつでも議論を終了できると思っています。そうですね。これ以上続ける必要はないという点については私も同意見です。別のご質問と同様に、最初の方で > ご提示の問題が間違っているかどうかについてコメントすることはありませんので、このやりとりによって、実試験で類似の問題が出題された際に「ハードリンクはディスク容量を消費しない」という内容の選択肢があった場合でも、harmoさんが自信を持って「これは不正解だ」と判断した上で合格を勝ち取れればそれで良いと思います。とコメントしたところで終わっていてもよかったのですが、「間違っている」と断定されていたので、私の理解を修正する必要があるかと思って追加のご質問をしてしまいました。特にその必要もなさそうだということがわかりましたので。 > また、私のこれまでの理解（ハードリンク自体はディスク容量消費しない、dentryはディスク容量消費する）は何ら変える必要がないこともわかりました。このコメントした時点で明確に「終わりにしましょう。」とお声がけするべきでしたね。すみません。長々とお付き合いありがとうございました。

2024/06/26 コメント

ハードリンクはディスク容量を消費しない？

この問題というか、harmoさんにとってのPing-tさんのコンテンツの利用目的がわからなくなってきたので、できればこれを最後にしたいところです… この問題（というかPing-tさんの学習コンテンツ）の利用目的に関わるので、まずは「疑問」から。 > そして疑問なのですが、ping-tやこの問題にはLPIC/LinuCとどのような関係性があるのでしょうか。この問題がLPIC/LinuCのレベルを表すものと捉えられているようですが、そう考えられた理屈がよく分かりません。「どのような関係性」と言われても「当該試験合格に向けた学習問題」でしかないと思っています。ですので試験合格に必要な知識を学ぶためのものであり「この教材で学習して合格できる＝LPIC/LinuCで求められる知識レベルを満足している」と言えるという認識です。 > ping-tの問題は全てLPIC/LinuCの方が監修されていたり、全て過去問として出題された実績があるということでしょうか。それは逆に問題かなと思います。本屋や他のWeb学習コンテンツなどで「LPIC-1対応」とか謳っているものもある中で、Ping-tさんだけがLPIC(LPI)/LinuC(LPI-Japan)の監修を受けていたら不公平な待遇ですし、過去問をそのまま出していたら受験ポリシーに引っ掛かりますからそんなコンテンツは不適切と判断されて監修どころかNG食らう可能性の方が高いと思います。＃＃＃ここまでが「疑問」についてで、ここからは「ハードリンクはディスク容量を消費するか」についてのお話です。＃＃＃引用された部分からは「ハードリンクを作成することで追加エントリが作成される」は読み取れるものの「ハードリンクすることでディスク容量を消費する」とは読めませんでした。ここはharmoさんもおっしゃっている通り > ・ハードリンク作成しても増加量が0byteに見えるのはディレクトリの容量確保が4096byte単位であるため、全エントリ容量がそれに満たない場合は変化しないだけと、「ハードリンクを作成しても増加量が増えない」場合を踏まえてのことだと理解しています。逆に「They are not duplicates」と「複製ではない（ハードリンク元と同じディスク容量を要求しない）」とは読める記述があります。加えて、英語版P.514の「3. Explain the difference between a hard link to a file and a copy of this file.」で > A hard link is just another name for a file. Even though it looks like a duplicate of the original > file, for all purposes both the link and the original are the same, as they point to the same data > on disk. や > A copy is a completely independent entity, occupying a different place on disk. 「ハードリンクは複製のように見えるがそうではなく、どちらもディスク上の同じデータを指す」「複製(copy, duplicate)は完全に別のエントリであり、別のディスク領域を占有する」と説明されており、対比することで「ハードリンクはコピーと異なりディスク領域を別途占有しない」と理解させようという意図が読める記述があります。また、「Moving and Removing Hard Links」のセクションでも以下の通り「ハードリンクは通常ファイルとして扱われる」との記述もあるので、「ハードリンクはエントリでありファイルではない」は（厳密な実態がそうであるとしても）LPIC-1の想定する利用者運用者の観点では混乱の元かもなぁと思っています。 > Moving and Removing Hard Links > Since hard links are treated as regular files, they can be deleted with rm and renamed or moved > around the filesystem with mv.

2024/06/25 コメント

ハードリンクはディスク容量を消費しない？

> 「0バイト（ディスク容量消費なし）のファイルは存在する」というのは妥当な理解ここちょっと補足すると、「中身のない0バイトのファイルを作成した」というのも「既存ファイル（実データあり）に対するハードリンクを作成したが、実データを複製したわけではないのでハードリンク自体は容量を持たない」というのも同じことだと判断できる、という意図です。

2024/06/25 コメント

ハードリンクはディスク容量を消費しない？

ありがとうございます。（いただいた回答から、LPIC101が求めているレベルはいつの間にかdentryの利用に関する知識レベルになっていたのか？！と驚きを持って受け止めています ^^; ） > そして私が述べていた「メタデータ」も「マッピング情報」も共に{名前,inode}という管理情報です。こちらのご説明から、これまでのやり取りは「メタデータおよびマッピング情報＝dentry」を意図していると確認できました。それでようやく当初ご質問の > ハードリンクのメタデータ(ハードリンク名や参照先iノード番号)の分が理解できました。その前提に立てば、これまでのharmoさんのおっしゃっている内容に同意です。また、私のこれまでの理解（ハードリンク自体はディスク容量消費しない、dentryはディスク容量消費する）は何ら変える必要がないこともわかりました。 LPIC Level1の求めるスキルは以下の通りです。 > LPIC-1は、候補者がコマンドラインでメンテナンスタスクを実行し、Linuxを実行するコンピューターをインストールして構成し、基本的なネットワークを構成する能力を検証します。 https://learning.lpi.org/ja/learning-materials/101-500/ このレベルで想定する運用観点で考えれば、この問題も私の認識でも「0バイト（ディスク容量消費なし）のファイルは存在する」というのは妥当な理解ですが、これまでのharmoさんのお話を踏まえると「データとしては0バイトかもしれないが、dentry分ディスク容量を消費しているのだから0バイトではない」となってしまい、小学校理科の知識を高校レベルで否定している感が否めません。この問題はLPIC-1向けの学習問題ですし、求められている知識レベルに合わせた回答を意識しないと、以前のコメントの通り > 実試験で類似の問題が出題された際に「ハードリンクはディスク容量を消費しない」という内容の選択肢があった場合でも、harmoさんが自信を持って「これは不正解だ」と判断するしかなくなり、自縄自縛になりかねないんじゃないかなぁと心配しています。もし「メタデータも考慮しないのか！」とレベルの低さを嘆かれるようであれば、LPIC/LinuCとかでは役不足かなと思いますので、期待するレベルに合う別の認定資格をお探しになった方が良いかもしれません。

2024/06/24 コメント

ハードリンクはディスク容量を消費しない？

ありがとうございます。クリアにしたい部分がクリアにならなかったのでお尋ねするのですが > という部分等から、 > ・通常ファイルとは一意のinodeを持つファイル実体であり固有の名前を付けることはできない。 > ・普段ファイル名として扱っているのは、ディレクトリが持つinodeへのマッピング情報である。 > ・既存inodeへの別名のマッピング情報を特にハードリンクという。 > と解釈できます。 1. 前のコメントの抜粋なのですが、 > $ touch original_file > $ stat original_file > File: original_file > <SNIP> > Device: fd00h/64768d Inode: 1457210 Links: 1 ←inode: 1457210, リンク数は1 ここでは元ファイルのinode番号が1457210となっており、このoriginal_fileが「一意（1457210）のinode番号を持つファイル実体」のことだと理解しました。（「固有の名前をつけることはできない」については意図が理解しきれませんでした。original_fileという名前をつけられない、という意味？）上記のstatコマンド出力の2行目でファイル名（original_file）が見えていますが、この「ファイル名」そのものがinodeへのマッピング情報を意味するということでしょうか？それともマッピング情報が「original_file」というファイル名を意味しているということなのでしょうか？また、「マッピング情報」と「メタデータ」は同一のものと理解して良いのでしょうか？ 2. 上記のファイルについて、ls -liコマンドで確認すると、どちらも同じinode番号を示しています。（これはハードリンクなので当然だと理解しています） > $ ls -li | grep _file > 1457210 -rw-rw-r-- 2 user user 0 Jun 23 19:17 hardlink_file > 1457210 -rw-rw-r-- 2 user user 0 Jun 23 19:17 original_file また、この出力の3列目の「2」は「ハードリンク数」を示していると確認しています。この状態でoriginal_fileを削除すると以下のようになります。 > $ ls -li | grep _file > 1457210 -rw-rw-r-- 1 user user 0 Jun 23 19:17 hardlink_file ハードリンクではなく元ファイルを削除したのに「ハードリンク数」が減少しています。また、この残っているファイルを元にしたハードリンクを作成することもでき、そのinode番号も同じものです。 > $ ln hardlink_file another_file > $ ls -li | grep _file > 1457210 -rw-rw-r-- 2 user user 0 Jun 23 19:17 another_file > 1457210 -rw-rw-r-- 2 user user 0 Jun 23 19:17 hardlink_file この時以下の点についてどう理解すれば良いのかが整理できません。 > 「ハードリンク=ディレクトリファイルの実体が保持する名前とinodeポインタの組」、いうなればメタデータこそがハードリンクの本体 > ・既存inodeへの別名のマッピング情報を特にハードリンクという。「メタデータがハードリンクの本体」であれば、ハードリンクに対するハードリンクを作成した場合「メタデータ（＝名前とinodeポインタの組）への別名のマッピングとなるメタデータ（メタデータへのinodeポインタとなるメタデータ）」を作成した、ということなのでしょうか？また、original_fileを削除したということは、メタデータであるhardlink_fileのみが残り「一意のinodeを持つファイル実体」である通常ファイルは消えたという理解で良いのでしょうか？ハードリンクが通常ファイル（という表現で良いのか？）の同じinodeへの参照であれば同じデータを複製することなく異なるファイルとして存在できるので「ディスク容量を消費しない」というのが成立するという理解であったので、「ハードリンク＝メタデータ」と考えるには「ハードリンク元のファイルを削除する」というのが元ファイルの実データとの観点でどういうことなのかをクリアにする必要があると思っています。 3. 私の元々の理解では「inode≒メタデータ」だったので、同一inodeで管理する情報が増えたとしてもそれはメタデータ（というかファイルの実データ）が増えるのではなく「当該ファイルを格納するディレクトリが管理するデータ量」が増えることで増加しているものであり、ハードリンクそのものがディスク容量を消費してはいないという認識でした。ですが、ハードリンクは「メタデータ」とのことなので上記の認識を変える必要があるかなと思っています。このやり取りの中で出てきている「メタデータ」とは「ディレクトリが持つ管理情報（マッピング情報？）」のことなのか、ファイルの実データに関する管理情報であるinodeなのか、それとも別の情報のことなのでしょうか？（最初のコメントの「固定サイズのメタデータ格納用ファイル」の理解に必要な情報である認識です）

2024/06/24 コメント

ハードリンクはディスク容量を消費しない？

認識改のために考えていたのですが、わからなくなってきたので教えてください。 > 「ハードリンク=ディレクトリファイルの実体が保持する名前とinodeポインタの組」、いうなればメタデータこそがハードリンクの本体であり、ハードリンクというファイルは存在しないとのことですが、「ハードリンク」はファイルではないのでメタデータが本体だということであれば、「通常ファイル（という言い方が適切かも考え中ですが）」とは何なのでしょうか？上記のstatの結果からすると、ハードリンクもとのファイルとハードリンクのどちらも同じinodeが割り当てられている（＝同じinodeポインタを持つ）ということだと思ったのですが、通常ファイルとハードリンクはどこがどのように異なるものなのでしょうか？ハードリンクと通常ファイルの違いについて明確に解説されたドキュメントもうまく見つけられず困っています。

2024/06/23 コメント

ハードリンクはディスク容量を消費しない？

そうなのですか！ハードリンクがすでにあるファイル（実データ）への別名による参照だと理解していたので、どちらもファイルだと思っていました。ーーー $ touch original_file $ stat original_file File: original_file Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd00h/64768d Inode: 1457210 Links: 1 ←inode: 1457210, リンク数は1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user) Access: 2024-06-23 19:17:16.846932371 +0900 Modify: 2024-06-23 19:17:16.846932371 +0900 Change: 2024-06-23 19:17:16.846932371 +0900 Birth: 2024-06-23 19:17:16.846932371 +0900 $ ln original_file hardlink_file user@containerlab:~/work$ stat hardlink_file File: hardlink_file Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd00h/64768d Inode: 1457210 Links: 2 ←inode番号は同じで、リンク数が2に増えた Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user) Access: 2024-06-23 19:17:16.846932371 +0900 Modify: 2024-06-23 19:17:16.846932371 +0900 Change: 2024-06-23 19:17:26.863098754 +0900 Birth: 2024-06-23 19:17:16.846932371 +0900 $ rm original_file　　←ハードリンク元のファイルを削除 $ stat hardlink_file File: hardlink_file Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd00h/64768d Inode: 1457210 Links: 1 ←inode番号は変わらず、リンク数が1に減った Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user) Access: 2024-06-23 19:17:16.846932371 +0900 Modify: 2024-06-23 19:17:16.846932371 +0900 Change: 2024-06-23 19:17:31.915182665 +0900 Birth: 2024-06-23 19:17:16.846932371 +0900 ーーー「Unixではすべてのリソースがファイル」という概念を昔学んだのが根本にあったので「ハードリンクもファイル」という認識でいましたが、今は変わっているのですかね。認識を改めねば。

2024/06/23 コメント

ハードリンクはディスク容量を消費しない？

もしご存じだったら教えてください。当然だと思ってて気にしてなかったのですが、「ハードリンク」と「ハードリンクを作成することで記録されるメタデータ」って同一視すべきものだったりするでしょうか？ハードリンクは「ファイルシステム上の同じデータを指す」ファイルだと理解していたので追加で容量消費しないのは当然だと思っており、逆にメタデータは「ファイルシステムの管理情報」なので管理対象となるハードリンクが増えることで「メタデータ」が増えるのは当然だとも思っています。で、そうすると「ハードリンク＝ハードリンクのメタデータ」とはならないんじゃないかな？と思ってたのですが「”ハードリンク”と”ハードリンクのメタデータ”は異なるものだという私の理解がそもそも間違ってる…？」と心配になってきました。

2024/06/23 コメント

機械的に壊れにくいが、機械的に壊れないわけではない

> もしかしたら「機械的な」の言葉の解釈に齟齬があるのかもしれません… はい、私もそこがポイントなのかもなぁとはうっすら感じていました。ご質問の時点で > SSDやUSBフラッシュメモリは可動部品がないので機械的に壊れにくいだけとおっしゃっていたので、「可動部品の有無について言及されている＝機械をmachine（部品を組み合わせた装置）とした前提で会話可能」と判断していたのですが、 > 外的要因の振動や衝撃等の機械的(mechanical:力学的)な故障と「力学的」という前提で会話されていたのだということがわかってスッキリしました。前提が違ったら会話もすれ違いますよね(^^; なお「ドライブ（記憶装置）」の観点で、使用中のSSDに対して「力学的故障」が発生するシーンというのはパッと思い浮かばなかった（それこそ天災や不慮の事故ぐらい？）ので、やはり最初に言及したように > 曖昧さ回避のために「SSDとUSBフラッシュドライブは」を「SSDは」として「頻回な抜き差しや意図していない操作による破壊」を考慮外にできるようにというのが、出題意図からすると妥当なのかなぁと改めて感じています。（基盤にソルダリングされたSSDが力学的に壊れる＝SSD単体の観点じゃなくマザーボードごと壊れるという話でもありますしね）とはいえ、「機械的」を「機械（部品を組み合わせた装置）」「的（そのような性質）」と理解してこの問題を解く事に特に問題があるとは思いませんし、「機械的（mechanical）」を「力学的」と理解することを間違いだとも思っていません。 https://dictionary.cambridge.org/ja/dictionary/english/mechanical ですので、前者の意図で作成したであろうこの問題を間違っているということもharmoさんの考え方が間違っているということもできませんので、別のご質問と同じ結論になってしまいますが、「実試験で同様の選択肢があった場合でも、自信を持って当該選択肢を誤りと判断して別の選択肢を回答として選択される」というのが落とし所（っていうのも変ですが）かなと思います。

2024/06/22 コメント

機械的に壊れにくいが、機械的に壊れないわけではない

> 今は個体が多いからか「個体」じゃなくて「固体」ですね (^^;

2024/06/22 コメント

ハードリンクはディスク容量を消費しない？

回答に記載した別の質問の中で > 試験では「ハードリンクとはどういうものか」が問われていると考えられますので、「動的inodeのファイルシステムでリンク先が重複する大量のハードリンクを作成した場合」という特殊な例を前提にはしていないと判断するべきかなぁと思います。と記載しましたが、実験された内容に > 3.以上繰り返しと記載がありますので、この操作が通常運用で当然のものだというご判断なのだと理解しました。ですので > したがって、問題ID15004及び3701は「ハードリンクはディスク容量を消費しない」は間違っていることが分かりました。ご提示の問題が間違っているかどうかについてコメントすることはありませんので、このやりとりによって、実試験で類似の問題が出題された際に「ハードリンクはディスク容量を消費しない」という内容の選択肢があった場合でも、harmoさんが自信を持って「これは不正解だ」と判断した上で合格を勝ち取れればそれで良いと思います。

2024/06/22 コメント

機械的に壊れにくいが、機械的に壊れないわけではない

> 基盤やコンデンサの破損等で例えた方が良かったですね。はい、その例示は適切かと思います。電源ユニットでも使ってたら煙吹いて使えなくなるとかよくありましたしね。（今は個体が多いからか、あまり聞きませんが）この場合は「回路上の部品破損」なので「機械的故障」ではないというのがはっきり見えて良いと思います。後半についてですが、そもそもこの質問の主旨は > 「SSDとUSBフラッシュドライブは、HDDのような機械的な故障が起きない」という正答の選択肢についてでしたので「機械的な故障」についての話だったと理解しています。破壊行為や振動や熱といった外的要因を主眼に話を進めるのなら、それは「意図しない操作」や「（劣悪な）使用環境」という観点が優先になるように思ったので、掘り下げると違う方向に進んでしまってよくないかなぁと思いました。

戻る