  |
はてなキーワード: コマンドとは
だからオタクの敵になりたいとかそういうつもりで書いてないし、自分の問題提起が正しいかもあやふやだ。そこも含めて聞きたいと思っている。
言いたいことは題名の通りで、漫画やアニメの異常な表現は見直されるべきだと思う。
これはお気持ちの問題もあるが、実際に女性がコンプレックスを持つ原因になるのではと危惧している。
それは、アジア人ではまずいないレベルの巨眼女性が普通であるかのように表現されて、
特に若い世代が現実ではあり得ないくらいの巨眼を理想としてしまっていることだ。
少年漫画平均くらいの目の大きさならともかく、少女漫画は顔の四分の一くらいが目に支配されていることも多い。
さらには女児漫画だと顔のパーツの7割くらいが目で構成されているキャラクターが度々登場する。
で、これの何が問題なのかと言うと、現実の女性がその漫画アニメ表現に合わせようとしていることだ。
例として学生時代に彼女とプリクラを撮った際のことなのだが、出力された写真の目がデカ過ぎて宇宙人みたいになっていた。
キモいから40秒くらいの加工タイムで補正を切るコマンドをさり気なく探していたが、
そういうボタンは無かったし、彼女は「かわいい〜♥」とテンションが上がっていたので何も言わなかった。
「まぁプリクラってそういうもんか…」とスルーしたのもつかの間、俺の世代では「SNOW」という写真アプリが大流行した。
これは写真を撮る前から人顔を認識し、自動で肌補正や巨眼加工などをやってくれるアプリだ。
その結果、学内の奴等がSNSに挙げる写真は目が異様にデカく、肌も筆で塗ったみたいにボヤっとしていて、鼻の部分に猫の鼻みたいなバカなエフェクトが乗っているのがデフォルトになってしまった。
加工が一切ない写真を撮っていたのは俺だけで、共に旅行した友人は皆SNOWで撮っていた。
おかげでLINEに共有したアルバムの8割に変な鼻エフェクトが乗って宇宙人みたいな顔になっている。
時が経つにつれて最早SNOWでなくても加工撮影アプリを平然と使う世になってきた。
大学の友人は「かわいい彼女いるんだぜ」と顔が巨眼に加工された女性の写真を見せてきた。
サークルの先輩は「これが合コンのメンバーなんだが行くか？」と顔が巨眼に加工された女性の写真を見せてきた。
ルームメイトの後輩は「いやぁ〜マッチングアプリの写真に騙されましたよ〜」と顔が巨眼に加工された女性の写真を見せてきた。
百歩譲って見栄を貼りたい女性の立場を受け入れたとしても、ほぼ絵みたいになっている加工写真を男性側が受け入れて品定めするようになってきた。
完全に俺はついていけなくなり、頭がおかしくなりそうになった。
そんな折、俺は加工写真に理解を示すべく、相変わらず写真補正アプリをデフォで使ってくる彼女に対して、「これ使ってると人の顔が絵みたいになるよね〜」とアプローチをかけてみた。
すると「だよねだよね！少女漫画の主人公みたいでカワイイ〜」と返してきた
………な…なるほど〜……と思った。
確かに異様にデカい目、ツルッとした肌、点みたいにちっちゃい鼻
彼女の家には大量の少女漫画があったし、昔からプリキュアを見続けているとも言っていた。そういったモノへの憧れなのか…それとも目が小さいというコンプレックスが刺激されてしまったのか…
今や補正撮影アプリも使用したところで何か言われるような世ではすっかりなくなった。
人々がこのアプリを使う理由は必ずしも俺の彼女と同じとは限らないだろう。
しかし現日本は公共にアニメ絵が溢れ、日本人は幼い頃から目が大きなアニメキャラを自然と見てきている。
そういったモノに対して、最早意識して憧れを抱くまでもなく、大きい目が自然で理想的だという無意識が若い世代に芽生えているのではないのだろうか。
………と、ここまで書いたが
どこかしら変な所があるとは思う。
それとぶっちゃけこれを書いた主目的は学生時代に体験したSNOW大流行という恐怖体験の本質は何だったのかを知りたいだけなんで
もしくはコマンド打ってCtrl+CでExcelにコピペして比較、もいっかいPowershellでレジストリ抽出して～と実装せず手作業でやるってことでしょうか？
んなめんどくさいことはしたくなくて、ダウンロードしてきてZip解凍するなりインストールするなりで利用できることを想定してます。
レジストリの抽出だけならあるかも＆テキストの差分比較(Diff)ならあります。
それぞれを一緒にやろうとすると厳しそう。
自分ならPowerShellでタイムスタンプつきで抽出して、それをDiffしますかね～。
DIffで思い出したけどPowershellにもDiffありましたね。Excelいらないや。
Linuxでも似たようなことはできるかと。
タイトルにある通り、”ツール”が欲しいんですね。えぇ、タイトルの通り。
プログラム作るなり、スクリプト組むなりすれば実現できる、ということは認識してます。これは”実装”ですよね。
もしくはコマンド打ってCtrl+CでExcelにコピペして比較、もいっかいPowershellでレジストリ抽出して～と実装せず手作業でやるってことでしょうか？
んなめんどくさいことはしたくなくて、ダウンロードしてきてZip解凍するなりインストールするなりで利用できることを想定してます。
CUIではなくGUIで、ボタンポチポチでレジストリの変化を絞り込めるツールです。
メモリエディタはそういった機能があるので、使っていただけると理解しやすいかと。
もしPowershellとかExcelの(ワンライナーですらない)1コマンド(コマンドレット?)でできるならとてもありがたいですが、
そんな機能は私は存じ上げません。
もしあるのであれば教えてほしいです。
タイトルにある通り、”ツール”が欲しいんですね。えぇ、タイトルの通り。
プログラム作るなり、スクリプト組むなりすれば実現できる、ということは認識してます。これは”実装”ですよね。
もしくはコマンド打ってCtrl+CでExcelにコピペして比較、もいっかいPowershellでレジストリ抽出して～と実装せず手作業でやるってことでしょうか？
んなめんどくさいことはしたくなくて、ダウンロードしてきてZip解凍するなりインストールするなりで利用できることを想定してます。
CUIではなくGUIで、ボタンポチポチでレジストリの変化を絞り込めるツールです。
メモリエディタはそういった機能があるので、使っていただけると理解しやすいかと。
もしPowershellとかExcelの(ワンライナーですらない)1コマンド(コマンドレット?)でできるならとてもありがたいですが、
そんな機能は私は存じ上げません。
もしあるのであれば教えてほしいです。
そもそも何も置かない、そうすると細くなってコンパクトになる。
必要なアプリがあればWinキー押して、打てば候補で出てくる。
例えばコマンドプロンプトを起動したければ、Winキー押して「cmd」の「cm」あたりまで打てば候補で出てくる。
この際下のコマンドで、「ウェブで検索」やコルタナなどの諸々のゴミ機能をオフにしておくと、スタートメニューの検索ボックスを使い勝手が大変よくなる。
reg add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search /f /v BingSearchEnabled /t REG_DWORD /d 0
reg add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search /f /v AllowSearchToUseLocation /t REG_DWORD /d 0
reg add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search /f /v CortanaConsent /t REG_DWORD /d 0
お試しあれ
そもそもの問いの立て方が間違い（酷いストローマン）。ホロコーストでのユダヤ人の犠牲者は、大雑把に言えば、アウシュヴィッツで100万、その他の約四箇所（マイダネクは少ないので計算から除外）の絶滅収容所で200万、ソ連等のその他の地域での虐殺で150万、ゲットーや強制収容所などで100万、その他50万、合計で600万人と言ったところ（繰り返し言うがかなり大雑把）。つまり、ホロコーストの象徴になっているアウシュヴィッツでは約100万人なので、それを6倍もストローマンした虚言・戯言である。
また、アウシュヴィッツでさえ「骨まで残さず焼却した」だなんてことはない。むしろ、非常に荒っぽい不完全火葬で、細かい話だが炉の中の死体を載せる格子から下の灰皿に落ちた残骸は、掃き出してランマーで細かく砕いて、集めて近くの川に捨ててしまったのである（司令官を含む複数証言）。他のヘウムノなどの絶滅収容所では焼却後、粉砕機を用いて骨類は砕き、周辺の土地へばら撒いた。また、犠牲者数こそ数万と少ないものの、マイダネク収容所には大量の遺骨が残っていた。「Majdanek bone」とすればその画像が得られる。
もしそうならば、確かに、大雑把に絶滅期間を500日とすると、十万体しか処理できないことになる。しかし、それは明らかに嘘である。何故ならば、別の収容所であるマウトハウゼン強制収容所の衛星収容所であるグーゼン収容所では、一基の火葬炉あたり、1日あたり20体以上の火葬をしていた記録が残っているからである。アウシュヴィッツには絶滅の現場であるビルケナウだけで46基の火葬炉（マッフル数）があり、1日あたり少なくとも900体処理できたことになって、500日なら45万体である。それでもまだ半分以下だが、アウシュヴィッツでは実は一体ごとに火葬するなどと言う丁寧な火葬などせず、複数遺体を同時に火葬していたので、能力自体はもっと増える。それに、ビルケナウの火葬炉はトリプルマッフル炉や八連マッフル炉になっていて、遺体を入れて火葬する場所が内部で繋がっており、高温を維持しやすい構造となっていて、連続焼却を前提とした構造だった。民生火葬場とは全く違い、遺骨を遺族に返却する必要はなかったのだ。（あっても、適当に遺族に誤魔化して骨壷に入れて渡した）さらに、犠牲者が多かった時期は、野外焼却を実施し、司令官のヘスは自叙伝で「ほとんどの火葬は野外焼却となった」と書いている。以上、百万体程度は十分可能だった。
実は、アウシュヴィッツの火葬炉は、最初の二日間程度、炉内を高温化するためにコークスが必要だっただけで、遺体の火葬自体にはコークスはほとんど必要なかった。何故ならば、複数遺体を同時に連続的に火葬していくので、それらの遺体自身が燃料化したからである。燃えにくい痩せてガリガリの遺体の場合にはコークスは追加されただろうが、太った新鮮な遺体（つまりは収容所に収容されずに即日ガス室で殺された人）ならば燃料替わりにさえ使われた。これらについての細かい技術的な話は、遺体処理を担当したゾンダーコマンドだったヘンリク・タウバーの証言を読むといい。
アウシュヴィッツの様々な議論（９）：証人の宣誓供述書１：ヘンリク・タウバー｜蜻蛉｜note
青酸ガスの爆発濃度下限値は56000ppmであり、人間の致死濃度はせいぜい2000ppm程度（一般には300ppmとされるが諸説ある）である。いずれにしても、ガス室内だけの話であり、ガス室外に漏れ出したとしても、濃度は低下してしまうため、引火の危険があるとは考え難い。否定派は、シアン化ガスの「濃度」を無視する傾向がある。実際には例えば、10ppm程度だと致死に至る可能性は極めて低い。そもそも青酸ガスの元であるチクロンBは害虫（及び害獣）駆除剤であり、害虫駆除作業で使える程度の安全性がなければ使えなくなってしまって全く意味がない。なお、詳細な話をすると、この火葬場の隣のガス室は、アウシュヴィッツのメイン収容所にある、現在でも観光用に公開されているガス室（第1ガス室）のことであり、ユダヤ人絶滅の現場であるビルケナウのガス室のことではない。流石に第1ガス室で処刑最中には、隣で火葬作業をしていたとは思えない。そこでは毎日稼働させるような大量の処刑はしていなかったからである。ビルケナウのガス室では、火葬場はガス室から離れていたので、引火の危険性を考えること自体おかしい。
遺体搬送の働き手は、いつ死んでもいいユダヤ人のゾンダーコマンドである。また、20時間の換気は、ディゲシュ社が想定した害虫駆除作業箇所でのものであり、様々な場所を想定した上での安全性を配慮しただけのことであり、必要十分な時間よりかなり長いマージンをとっている。しかしアウシュヴィッツのガス室は、室内はガランとしたただの空間であり、致死濃度でさえなければ、あるいはガスマスクを使用していれば、少なくとも死ぬ危険はなかったのである。実際、何人かのゾンダーコマンドの証言ではガスマスクをつけていたとの証言がある。十分な換気能力の換気装置のあったガス室と、自然換気で行ったガス室があったが、生存者証言によるとわずかに体調を崩した程度の証言があるのみで、死者があったと言う証言はない。また、非常に細かい話としては、地下型のガス室になっていたクレマトリウム２や３では、金網投下装置なる特殊なチクロン投入装置があり、これを利用してユダヤ人殺害を確認したのち、ガスを放出し続けるチクロンBを容器ごと天井から引き抜いたため、「ガスを放出し続けるチクロンB」の問題はなかったのである。
それは、ロイヒターやルドルフは、殺人ガス室とされた場所には存在していない、（シアン成分が鉄分と結合して化学変化した長期的に安定的な）プルシアンブルーを害虫駆除室で試料採取し検量したからである。プルシアンブルーが、青酸ガスが使われたら必ず発生するという証明は一切されていない。その上、害虫駆除室の壁面をよく見ると、プルシアンブルーのある場所とない場所がはっきり分かれており、これは青酸ガスが存在してもプルシアンブルーが発生しない場合があるという証明になっている。プルシアンブルー以外のシアン化物質成分は、非常に水に流出しやすいことがわかっている（ビルケナウのガス室のあった火葬場は全てダイナマイトで破壊されており長年に渡って雨曝しだった）。さらに、害虫駆除室と殺人ガス室におけるチクロンの使い方は、その残置時間が全然異なる。害虫駆除ではシラミはなかなか死なないので、通常は丸一日の燻蒸を行ったのに対し、殺人ガス室では証言によるところ、せいぜい三十分以内であった。死体の火葬処理の方に時間がかかるため、一箇所のガス室での集団処刑はせいぜい1日に一回、多くても2回が限度だった。したがって、殺人ガス室の後とされる場所にプルシアンブルーが生成されていなくても、何ら不思議はない。以上のことから、プルシアンブルーを含めない検査方法でなければインチキである。それをやったのが、ポーランドの公的機関であるクラクフ法医学研究所であり、結論として殺人ガス室があったとみなして良い結果を得たのである。
ロイヒター＆ルドルフレポートに対抗したクラクフ報告とは。｜蜻蛉｜note
野外焼却の証拠は、まず司令官ルドルフ・ヘスの自叙伝に記載されているものがある。他にも複数人の証言がある。また、1944年中の米軍による航空写真にそれら証言が伝える場所での煙が写っている、さらにはユダヤ人ゾンダーコマンドによる極秘に取られた焼却中の写真もある。さらには1960年代に行われた民間会社による野外火葬場所の発掘調査で遺灰などが発見されている。否定派は、「アウシュビッツに焼却用の燃料がなかったこと」「どのくらいの燃料が必要だったかの客観的根拠」など、否定すべき内容についての証明を一切行っていない。なお、アウシュビッツ・ビルケナウ収容所は、十万人規模の囚人と二千人規模の親衛隊員を有する巨大施設であり、燃料不足で燃料を使わずに活動・生活していたなど信じ難い。ユダヤ人絶滅は「総統命令」として実施されており、極秘作戦だったから、遺体の証拠隠滅も必須であり、戦争遂行と同じであって、何が何でも実施したであろうことは想像に難しくない。彼らは命令で動いていたのである。否定派は、何故ユダヤ人絶滅をやっていたのかを全く考慮していない。戦況が敗戦必至になって、絶滅作戦が中止されたが、それもまた親衛隊トップのヒムラーの命令であった。
今更何を……。［しかしいまだにアンネの日記のデマはツイッターなどでしばしば流れる］
Twitterホロコースト否定論への反論（18)：アンネ・フランクの日記｜蜻蛉｜note
昔からあるアルマナック・デマと呼ばれる既に何度も論破された愚論。戦後のセンサスがアルマナックに反映されるのは1949年まで待たなければならない。それまでは、単に1939年の値からの推計値を記載していたのである。また、ニューヨークタイムズは後日、その数字を1200万人に訂正している。
ダッハウに米軍が入った時、大量の囚人の死体があったのは周知の事実である。ガス室のあった建物であるバラックX周辺にも遺体が山積みとなっていた。そして「浴場へ」と書かれた看板のある、ダミーシャワーのついた謎の部屋……、戦時中からドイツ軍がユダヤ人のガス処刑をしていることは広く連合国側に伝わっており、これらの状況からダッハウのガス室で大量虐殺をしていたと誤解しても致し方のない状況であった。米軍は当初勇足で「ダッハウのガス室での大量虐殺」を報告してしまった。しかし、直接的な目撃証言や裏付けのある証拠が当初は見当たらず、ガス室でのガス処刑があったとは言えないとわかるのは1960年代まで待たなければならなかった。のちに僅かな目撃証言と文書資料が見つかったが、裏付け能力に乏しく、「実験的なガス処刑があった可能性がある」くらいしか言えない。いずれにしても、歴史的事実がさまざまな調査研究により、後々になってより詳しく判明していくのは当たり前のことである。とくにおかしいところはない。
知らんがな。確かにNHKの番組ですら誤ったホロコーストの内容を伝えていることはある。実は著名な研究者ですら、非常に細かいところで誤った記述をしていることもある。しかし、日々のニュースでさえも、「先ほどのニュースの中に誤りがありました。訂正してお詫びします」を聞かない日はない。人は誤りを犯す生き物である。それが何か？
……ほんとにネット界隈（特にTwitter、Youtubeあたり）は修正主義支持者が多いので、誰か手伝って欲しいくらいなんだ……
貰える給与と本人が目指す方向性・所属会社にもよるけど、基本的にそれは大ハズレ案件だな
お散歩していい案件は20件しか見てなかったよ。それもひとりではなく"チームで"だぞ
一応、CCNAとLPICは推奨されてはいたけど、別になくても勤怠に問題無さそうな人なら採用してたし、
そもそも、Cisco機器やサーバーに入ってコマンド打たせるとかトンデモねーことさせないです
監視サーバーがアラート上げる＞担当者へエスカレーション、報告書書いて終わりだぞ
Twilio でいいじゃんって思うけど、こういう仕事、何故かまだ絶滅していないです
強いて言えば、楽なことが知れ渡ってるので夜勤・日勤を混ぜたシフトを出してくる会社もあるくらい
個人的には昼勤務もめっちゃ暇で基本遊んでてOKとかでもない限り、夜勤専属で押し通せないなら監視以外の仕事した方がいいと思う
グローバル展開してて夜間帯も時差のある国の海外支社からの問い合わせ対応しますよみたいな、いわゆる夜間帯専属の社内ヘルプとかやった方がまだいい
基本的に暇だし、英語使えるからいいんじゃないかと。在宅もあるしそもそも在宅で雇ったことがある
在宅の具体的な活用例
24hで海外サイトの対応も依頼されたよ。でもクソみたいな予算だよ。英語対応出来る人材どころか、未経験の子なら雇えるくらいの予算だぞ。バカなの？
＜解決策＞
(なお、都内でオフィスに通いで同スキルの人材雇ったら1.5倍はする上に求人時に競争力のある時給では無い)
英語使いたかねーよならクラウドサービスのサポートで夜勤専属ってあるな
ただしスタンドアロンのアプリを書いてる人については特に問題ない。
要はシステム構成がWindowsPC1台orスマホ1台のみで済むとか、組み込みとかね。
それからITゼネコンの末端で、詳細設計をコードに翻訳するライン工もどきみたいな立場の人も別に知らなくていいけど、それもうプログラマーじゃなくて単なるコーダーだよね。
こういうこと書くと
とか言い出すやつが絶対にいるんだけど、今やクラサバモデルのシステムは開発のメインボリュームで、かなりの数の開発者に関係する話じゃねーの？って思うから言ってるわけで。
あと、Linuxというか本当はUNIXなんだけど、現状サーバ用途のUNIX系OSがほぼLinuxで占められているので。
なんでLinuxが使えないと問題かというと、実際にサーバを運用しているエンジニアとまともにコミュニケーションが取れないから。
それが回り回って開発と運用が対立する、あるいは何かあったときに適切に連携できなくなる遠因になる。
本当は開発側がサーバ側の運用設計まで書いて、運用するSEに承認してもらうまでが仕事。
そのためには自分が作るシステムの動作環境の構築は自力でできなきゃダメだし、そのためにはLinuxの基本的な使い方を知っている必要があるわけで。
それにネットワークプログラミングなのだからある程度のネットワークの知識は必須で、Linuxも扱えない人がそういう専門家になれるとは到底思えない。
まあ流石にスイッチ・アプライアンス・ストレージみたいな話になると、カネ払ってベンダーのセミナーを受講しないとわからないと思うので正直厳しい。
その場合でも、Linuxに触れることで身につけたネットワークの知識が不要ではないどころか、
「今こちらのサーバでこういうコマンドを実行した結果がこうで・・・」
みたいな話をインフラエンジニア相手にできるとできないでは大きな差がある。
最近の流れで、そこらへんを全部クラウドにお任せするにしても、サーバとは一体何者か？レベルは体験的に知っておいたほうがよさそうだし。
IDEを使う上で覚えることは決して少なくないし、CLIだったら実行するためのコマンドとエラーメッセージの読み方だけに絞れる。
そしたら「自分のプログラムがなぜ動かないか」という本質的な問題に直面しやすいだろ。
たった1文字書き誤っても動かない、だから書く時は注意の仕方にコツがいる(≒単純なコピペであってもすぐ動くとは限らない)とか、実地に学べるじゃん。
一方で、スペルミスとかもいちいち丁寧に教えてくれる、IDEの親切な機能に最初からおんぶにだっこみたいなプログラミングがいいとは思えない。
あと、こっちはIDEの便利さは否定しないどころか、効率的に開発するなら必須だと思っているけど、最初からセットで覚えるものじゃないと言っているだけなんだが。
なんで最初からIDEでプログラミングを覚えるべきなのかが理解できない。
その「マネージド」の部分にawsコマンド叩いてよしなにやらせることも含まれるやで
まぁそういう人もいるよね。それで問題ないと思うよ
サーバー←→クライアントの関係、基本的なネットワークが理解出来ているか？だけが重要な訳で
CUIの画面でカタカタったーーンが重要なわけではないし、必要になったら必要なコマンドをググれば事足りる
あとワイは未経験者はLinuxと仲良くなっといた方がスムーズでは？派だが
わざわざ普段使うオペレーターティングシステムをUnix寄りにましてやMacにする必要性はない思ってる
この増田→ anond:20220811161554 がMacなんちゃら書いてること読み落とした
MacはApple信者とスタバでドヤ顔に任せておけばいいと思うよ
https://anond.hatelabo.jp/20220527063027
あとWSL2使えよは何度も言ってるわ
