  |
はてなキーワード: 改ざんとは
今止まってる火力発電所に原子力発電所があったら、言い換えたら今ある原発のところにそのレベルの地震があったら、また事故ってたんじゃないの？
再稼働してなくてよかったねｗ福島の二の舞になるところだったよね。
あれって国土が失われたのと同様だよね。福島産の食い物も輸出できないし。あの事故でどんだけのマイナス被ったの？そのマイナスを思えばちょっと停電するくらいでギャーギャー騒ぎすぎだよね？っていうか停電してないしｗ
福島は地震じゃなくて津波ガーとかいう奴いたけど、いや地震の結果津波が来たんだよね？津波で電源を喪失しないように高台に置けばいいとか、いや3.11の前からそうしとけや抜け作
はっきりいって一回事故ったら終わりの勝負で事故ったんだからもうとっくの昔に勝負ついてんだよね。3.11までがボーナスステージだったってだけ。
原子力発電所が地震で壊れないようにいろいろやってますとか書いてあるけど、見る気が起きないよね。そもそもジャップって隠ぺい改ざん破棄大好きミンジョクなんだから信用できないし見る意味がないよね？
つーかジャップなんて電気ガンガン使えても効率悪いんだから意味ないじゃん
MacType(https://github.com/snowie2000/MacType)のRC1を入れてサービスモードで起動し
Chromeの起動ショートカットのプロパティ、リンク先の末尾に「 --disable-features=RendererCodeIntegrity」を入れるといい
ついでに源真ゴシックPを拾ってきてChromeのフォントに設定し
noMeiryoUIを使ってシステムフォントも源真ゴシックP Regular 9ptあたりにするといい
これでエクスプローラなどは綺麗になるが
タスクバーやスタートメニュー、UWPアプリなどのフォントを弄りたいのであればYuGothic系フォントを改ざんするしかない
そのへんまでやりたければ複雑なのでググってくれ
９条があるから湾岸戦争にも自衛隊を派遣しなくて済んだんだよね？その時点で日本守れてるじゃん
バカの安倍が後方支援だのなんだの言いだしたけどまあそれは置いといて
日本からプーチンが出て無茶な侵略戦争をして経済制裁やらなんやらされたり実際に戦地で若者が死ぬ事態を未然に回避してるじゃん
その上で日本が侵略される可能性はもちろん否定しきれないよ。だから自衛隊があるんじゃん。
これとかも侵略される可能性は全くのゼロではないけどほぼゼロだろうと言ってるだけだし、究極的に言えばこの人たちの予測でしかないんだが
でもって事実として現時点まで日本を侵略しようとする国は出てきてないよね？
何が言いたいのかがわからないんだよね、ウクライナに関連して９条ガーって言ってる奴って。
バカなのかな？
普通の軍隊あるウクライナでも攻められてるのに９条ある日本は攻められてない。９条のないロシアはプーチンが侵略戦争をし始めたけど９条のある日本は平和。
ウクライナに関連して９条の話するんならむしろ平和を守ってくれてありがとうなんだけど。理屈ってわかる？
まあ、こんなバカばっかだったらそりゃあ脳死で安倍自民に投票するわな。セルフ経済制裁で没落しまくって韓国以下の一人当たりGDPとかになっても反日野党(笑)を懲らしめたつもりになってへらへらしてそう。俺は自民に入れたことないよと後世の人間に伝えておくよ
息を吐くように捏造隠ぺい改ざんするジャップなんか侵略戦争ができてもすぐボロボロにされるだけだよ。東京五輪やコロナのグダグダ見てもニホンジンは優秀だと信じてる頭お花畑ネトウヨうらやましいわ。おれに言わせると劣等ジャップ民族に軍隊なんて大層なもんはまだ早いけどねｗ
石原慎太郎もうちょっと生きててほしかったわ～せめて北京五輪のすばらしさを知ってから死ねよ
TVクルー(笑)へのへのもへじ(笑)すっかすかの大工みたいな奴(笑)へんな歌舞伎(笑)へんなダンス(笑)パッケージそのまんま買ったドローン(笑)
すまん、ジャップ恥ずかしくないの？
中国様に統治してもらった方がいいよねこれ。大東亜共栄圏じゃんｗｗｗｗｗ
ネトウヨもう舌かみ切って死んだ？中国様にはもう一生適わないって悟ったか？
息を吐くように嘘をつく捏造隠ぺい改ざん大好きミンジョクジャップがまともな文化を作り上げることなんて無理ｗｗｗｗ
批判の大切さを理解しろよジャップ。すぐ対案出せとかガキみたいに騒ぐけどさ。何もしねえことが対案だっつーのアホか。余計な事すんなカス
野党に批判されたらママに怒られた気分になって不貞腐れるいつまでたってもガキなジャップしぐさを改めて大人にならないとこれから中韓に差を付けられるばっかりだよ？
ま、どっちでもいいんだけどね（冷笑）
オープンソースcURLの作者、某大企業から「24時間以内にこの質問に答えるように」との無礼なメールを受け取る － Publickey について思ったことをつらつらと。
log4shell と呼ばれる脆弱性が 2021 年 12 月にあった。これは Java というプログラミング言語でプログラムする際に、動作のログを記録するのに非常によく使われるライブラリ log4j にとても危険な脆弱性があった。なにがそんなに危険かっていうと
マインクラフトのサーバが乗っ取られたとか被害も有名。詳細は Piyolog さんの Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog あたりを参照。
そんなわけで即座に影響範囲、脆弱性のない新しいバージョンになっているか調べろ！って IT 関連企業はとてもバタバタしていた。
という背景の中、オープンソースのソフトウェアである cURL の作者にとても失礼な log4j の問題に関する質問メールが送られてきて、「サポート契約すれば即座に教えてあげますよ」ってかっこいい返しをして盛り上がっている。
cURL (https://github.com/curl/curl]) はオープンソース(以下 OSS)の通信ライブラリとコマンドラインツール。 Linux などのサーバ上からファイルをダウンロードしたりするのにとてもよくつかわれるライブラリ。
C言語で書かれている。
ライセンス は MIT を参考にした独自ライセンス https://curl.se/docs/copyright.htm]
OSS は基本的に無保証で提供される。そのことはライセンスに明記されている。
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
そんな OSS に対して、
「あなたがこのメールを受け取ったのは、■■があなたが開発した製品を採用しているためです。私たちはこのメールをあなたが受け取ってから24時間以内に、お読みいただいた上でご返答いただくよう要求します」
といった上から目線のメールを開発者に送るというのは、IT 企業として無知にもほどがあるといったところ。加えて log4shell 問題、名前のとおり log4j の脆弱性なので Java でかつ log4j を使ってなければ影響はないのに、C言語でかかれた cURL に問い合わせているので問題を全く理解していない。(Java の j が消えるので log4shell という命名はどうなんだというのは個人的にある。つーか Poodle とか Spectre とかファンシーな名前つけてあそんでんじゃねーとも思う。)
なお cURL はどうやら開発者の Daniel Stenberg 氏が wolfSSL というところを通じて商用サポートを提供しているらしい。 https://curl.se/support.html]
ということで、「サポート契約を結んでいただければ、喜んですべて速やかにお答えしますよ」 というのはネタでもなんでもなく、普通の対応。
そしてブログに書いてある2回目の返信で、David と名前を間違えられたのに対して、Fotune 500 の巨人ということで "Hi Goliath," と返しているのも最高にクールですね。
こういうフローが事前に規定されていて CVE とか問題が検知されると発動する。このときに担当が大丈夫です！って回答するときにエビデンス（証拠）を求められるのだけど、クソな情セキは自社の担当の言葉を信用せず、開発会社からの言質をとれ！って命令するので、くそメールがスパムされるという背景があったりする。（担当が無知だったりイケイケだと、とにかく下請けにやらせればいいというパターンももちろんある）
そして情セキも経営層に報告するのに必要で、経営が0リスク信者だと報告が大変なのはわかる。わかるがそれを説得するのが情セキの仕事やで。
加えて担当レベルになると大手は「そんなん下請けにやらせればいいだろ」ってマインドのところが多く、上から目線かつ丸投げすることが多いように思う。
もちろん担当者はピンキリだからこうとは限らないけど比較的多い印象。
ま、これ今回 Daniel Stenberg 氏が公表したからばずってるだけで、日本でもしょっちゅう行われているし、Hacker News みると海外でも一般的なムーブのようです。 LogJ4 Security Inquiry – Response Required | Hacker News
小さいところは
とかであんまり上から目線でこない感じはするけど、これはあくまで個人の資質なのでやべー人はやべーです。オラオラ系の中小とかやっぱいます。でもこんな細かいことはあんまり聞いてこない。（個人の感想です）
この手のメールになんでカチンとくるのかって言えば
ということで、皆ちゃんと保守・サポート契約して、契約範囲で質問しような！
そして金払ってても相手は人間なんで、お互い敬意をもって接しような！
Public Key でこの件にからめて記載されている奴について
https://www.itmedia.co.jp/news/articles/2201/11/news160.html]
ちな、これ詳しくないんだけど、OSS 作者が 「もうただ働きで支援をするつもりはない。これを機に、私に6桁ドルの年間契約書を送るか、プロジェクトを分岐させて他の人にやってもらうかしてほしい」 というのもよくわからないんだよなぁ。
火事で財産失ってむしゃくしゃしてやったのかなんなのか。人気 OSS になったのに全然金にならんぜ！ってのが辛いのはわかる。が、OSS のライセンス的に支援を義務としてやる必要はないので、そんな義務的になってる報告は無視してええんちゃうんと思ってしまう。今回みたいにサポートフィーよこせみたいなスキームが必要だったのかもしれない。
あと個人開発で、善意でこれ便利だろ？って公開しているものに対して、辛辣な言葉の心ないバグ報告やら改善要望は心には刺さるので辛いのはある。それで辞めてしまう人も居る。
ブコメでフリーライドって書いている人が居るけど、MIT ライセンスでだしてんだから OSS の理念である自由なソフトウェアという意味で、再配布、改変、利用は自由でいいんだよ。イヤなら MIT 以外のライセンスでだせばよい。古くは MySQL の Dual ライセンス、最近の Redis とか Mongo みたいに。
ただ、金欲しいとか大体 Donation 募集したりするとかやってると思うんだけど、そういうのもあったのかなかったのかがよくわからにぃ。ポートフォリオになるので、採用にはつかえるんじゃないのかね？
じゃなきゃ GitHub に Public でコード公開しないと思うんだけどな。いまいちピンとこないのであんまり言及しない。
https://www.publickey1.jp/blog/19/redismongodbkafkaaws.html]
で、商用ライセンスの問題。これ今回のくそムーブの問題じゃないのここに並べられるのに非常に違和感がある。なんか OSS と大企業の対立を煽るようなミスリードを誘っているように感じてしまう。
大手クラウドベンダは OSS のライセンスに則って利用・改変するのは問題がない。つーか儲かってるから金よこせっていうのはちょっと違うんじゃないかなと思う。
オリジナルを開発した会社がリスペクトされず、商業的に儲からないってのは、心情的、道義的、人気的にどうなの？クラウドベンダも金払ってあげれば良いんじゃないの？とは思うよ。（2社は協業したけど）
ただ、オープンソースで公開するということは次のような利点を求めてするこって、それがイヤならプロプラで良いわけさね。
Apache License 2.0 とかのライセンスの OSS として公表しているものの利用をフリーライドと表現するのも、それがなんか嫌儲で Evil ってのはちょっと判断できないかなぁ。
大手が自社でメンテできてしまう（できるようにする）というのは経営戦略であり、開発元がクローズにするってのも経営戦略。罵り合い合戦はちょっとなぁという感じ。
OSS の理念的に改修した分は元のソースにもっとフィードバックしろよってのはあるけど AGPL とかで出してないんだよなぁ。
この辺は賛否両論色々あるので気になったら調べてみて。
以上。ご査収ください。
私はb:id:lady_jokeともb:id:lady_jokerとも関係の無い者ですが転載はやめてください。
元の記事（https://anond.hatelabo.jp/20220125023822）を削除してlady_jokeのアカウントも削除した今となっては、lady_joke氏（及び元記事作成者）の真意は測りかねますが、あなたの投稿は元記事投稿者の許可を得て投稿されたとはとても思えません。
また、内容もほぼ全てが転載であり、著作権法で定める引用の範疇をも超えたものです。
はてな社ともlady_joke氏ともlady_joker氏とも関係の無い私がお願いをするのもおかしな話かと思いますが、どうか記事を削除していただけないでしょうか。
削除していただけないのでしたら、『はてラボ利用規約第5条(禁止事項)の2-6【他者になりすましてサービスを利用したり、情報を改ざんする行為】』に該当すると、はてな社へ通告する次第でございます。参考：はてラボ利用規約 - Hatena Policies
＝＝＝＝＝
追記 18:41
非公開ブクマしてくれた人、誰だか知らんがありがとな。
オープンソースで活動してる人間です。気になる点があるのでいくつかピックアップ
OSMを元に作られてはいない。地図データとしてOSMを利用しているだけ。かつてはGoogleMapを利用していた。OSMより使い勝手の良い地図データがあれば乗り換える可能性もある。
ただ乗りを許さない！というのであれば、ライセンスを変更すれば良い。貢献がマストではないのに「貢献していない！ただ乗りだ！」はお気持ち表明に過ぎない。
改ざん動機が何にあるにせよ、そもそも信頼性の薄い、登録したばかりでコミュニティの貢献度の少ない参加者がダイレクトに本番データを修正できる点を考え直した方が良い。
新人は報告するにとどまり地図データは編集権限のある者が修正するなど、改ざんを防ぐ方法はある。OSMも規模が大きくなっているのだから、時代に応じた運用を考えるべきだ。
お気持ち表明はわかった。ただ、オープンソースの運営はお願いだけでは厳しい現実がある。wikipediaだってそうだろう。
niantecに問題がある・ただ乗りするなと叫ぶより、この件をきっかけにしてオープンソース運営を見直すきっかけにすれば良い。
証拠書類改ざんも警察官の解職で終わりだそうだから、これ金持ちだったら証拠を警察官に改ざんしてもらえば、不正な証拠しかない状態だから裁判で確実に無罪になれるよな
OSM は成功したボランタリー地理情報 VGI(Volunteered Geographic Information) の一例と説明されますが、あくまでそれは一つの要素であって、世の中に定着した「最大」の理由はボランティア運営によるクラウドソーシング手法を採用したことではありません
Google Maps のように商用利用時に制限のかかったウェブ地図よりも、より自由で、ある意味何でもできる OSM を採用する企業が増えたことで、OSM の認知度が向上するとともに、企業が OSM を用いたサービスで収益を生むことによる「エコシステム」がまわった。商用利用を許容することで民間企業による OSM のデータ更新と利用価値を更に高める正のフィードバックへとつながったのだと筆者は考えます。
https://medium.com/furuhashilab/show-the-niantic-flag-4ab03ed1c3ea
OpenStreetMapとは、自由に改変ができその利用もGoogleMapより自由度が高いことで有名な地図ソフトです。登山マップやゲームのマップなど、様々な分野で活躍しています。これの特徴は、無償のボランティアや利用する企業によるメンテナンスにあります。その中にはAppleやFacebookといったあまり地図に関係しないような企業も参加しています。
存在しない島を追加したり海岸をまっすぐにいじったりすることは可能ですが、当然そのようなこのはしてはいけません。地図としてきちんと整備することが第一で、OSMやその利用者の利益に繋がります。
ここで名指しで取り上げられているNianticは、ご存じのようにポケモンGoを開発運営する企業。
ポケモンGOの地図はOSMを元に作られています。ポケモンGOは日本だけでなく世界中で広く利用されており、その人口も非常に多いことで有名です。当然Nianticは世界でも指折りのOSMユーザーでありその恩恵を受けていますが、実はNianticはそのOSMに対する貢献が殆ど無いことでも有名です。
自身のアプリ内で直に使用し多くのユーザーの目に触れているものを、自らメンテナンスして貢献していないという実態はコミュニティの中に筒抜けです。
言ってみればNianticはみんなで作る地図にただ乗りしているわけです。
それだけなら大したことではないかもしれません。OSSを幅広く利用していても、その改善に努めないことが間違っては居ません。
ただ、Nianticの作っているポケモンGOはOSM自体への改ざんに繋がっているのが厄介な点です。ポケモンGoはOSM上の公園などの特定の場所にポケモンが出没しやすい仕様です。逆に言えばOSMをいじって自分の周囲に大量をポケモンを出してしまうことも原理的には可能です。そしてそのような改ざんがOSMのコミュニティの中で非常に問題視されました。現在は過去ほど大規模な改ざんは行われていないようですが、小規模な改ざんは今も続いているでしょう。当然、OSMは全世界的にそれが反映されるので、OSMを利用する企業や個人がその改ざんの被害者となり得ます。
それを知っているNianticは問題を放置し、修復を他の企業やボランティアに任せっきりにしています。ただ乗りを明らかに超えていることでしょう。
さらに、現在ではOSMを超えてGoogleStreetMapの改ざんも多く報告されています。実在しないものを審査させるために、その根拠となりうるストビューに意図的な改ざんをして審査を通すやり方です。
ここまでしてまでポケストが欲しい人が多いのが実情
また、ポケモンGoのポケストはそもそもIngressというゲームのポータルに由来します。最初こそこのポータルを設置する機能はポケモンGoにはありませんでしたが、現在はポケモンGoのユーザーでも申請や審査が可能となっています。しかし当然由来と使い方が違う物を別々のユーザーが申請・審査することは非常に軋轢を生むことになります。
現実問題、ポケモンGoで申請・審査ができるようになってからの不正なWayspotの登録は加速度的に広がりました。何も無いはず場所に大量のスポットが出現したり、本来はありえないものが登録されていたり。酷いときには地域毎で談合を行っています。さらにNiaticはあろうことかFourSquarer上から任意のスポットを抽出してスポット化しました。ユーザーに何も伝えずです。
これがポケモンGoの為だけならまだギリギリわかりますが、他のIngressや魔法同盟、ピクミンなどにも影響が及ぶスポットをこのような乱雑なやり方で作成することは問題です。
将来のゲームユーザーも使う物をポケモンGoの恣意的且つ数の暴力で歪めているのが現状です。
唯一のいいところですが、OSMのマッパーが少しだけ増えたことでしょうか。
一見正しそうだが正しくないラベリングをすると、結果として意図しない結果を引き起こすことがある。
"難しい人"、"有害な振る舞い"というのは、大変よろしくないラベリングになる。
こういったときに「言ってることはわからなくないけど、なんか違うな」と違和感を持ち、解決策を探るのがエンジニアである。
アクションに落とし込めないもの、計測できないもの、機械的に判断できないものは、いわゆる人間力に頼ることになる。
具体的に以下を例に挙げる。（元の記事の一番最初に例示されているもの）
この短い（１行８０文字以下を短いと言う）文章の中に、人間力に頼る判断は何か所あるだろうか？
私は、「創造的」「議論」「阻害」「時間を奪う」の４つは、機械的な判断が難しいと思う。
これは客観的な基準で「他者の話に割り込んで、自分の意見を差し込」んでいる。
先ほどの例だが、こんな前提があったとする。
そうすると、「営業と管理職から見て、大変有意義で創造的な議論に、毎度口をはさむ難しい組み込みエンジニア」というレッテルは正しいだろうか？
各人の判断は、正しいだろうか？
人間力に頼る判断基準で多数決を用いるのは、エンジニアリングで無く、政治的な解決だと思う。
先ほどの会議の例でいえば、５人中３人が心理的な負担を感じており、不愉快な気分になっている。
チームの60%が「創造的な議論を阻害する有害な振る舞い」だと認定している。
その判断は、正しいだろうか？
この場合、組み込みエンジニアが、難しい人 or 有害な振る舞いをする人として、指導もしく排除されたとする。
それは、心理的安全性をあげ、チームの生産性をあげる行為だろうか？
例えば、今後デザイナーは、営業と管理職が「どのような雑談をどの長さでしていても」発言しなくなるかもしれない。
デザイナーからみて、その会話が創造的な議論か判断ができないからだ。
さて、Web系のバックエンドエンジニアや、クラウドインフラエンジニアだと、アラートを設定したり、対応したいことがある。
「何かまずいことが起こっていることを、何らかの方法で監視して、対応したい」という場合だ。
例えば、待機系サーバーの起動時に妙に時間がかかっている場合、自動対応ができないので、アラートメールを飛ばして手動対応したいと思ったとする。
絶対値（10分）か、相対値（過去5回の起動時間の平均値）かは場合によるし、それが適切かはまた別の話だ。
「他者の話に割り込まない」というルールは、誤検知を引き起こしやすいアラートだ。
そんなのは常識で考えたらわかるだろう？曖昧な基準は「俺のは有意義な議論の発言だ」の判断を誰かが決めることになる。
大多数がそう思っていれば、という複合的な基準もありうる。その場合、先ほどの例の組み込みエンジニアは、アラート対象になる。
「会議のアジェンダに記載されている内容を3分以内で喋っている場合に、割り込まない」というのは、一つの基準になる。
この場合、営業が「営業概況を冒頭のアジェンダに加えて欲しい」と交渉する余地がある。
また「報告時間が10分は欲しいが、3回以上は一度会話を止めるので、営業概況に対する質問はその時に」という合意もできる。
そして、顔合わせのキックオフミーティングで、営業概況をやるかは、会社やチームによる。
明示的なルールで縛るのが正しいかと言えば、そうした方が良い職場もあるだろうが、窮屈な職場も多いだろう。
という簡単な話に見えることですら、ルールを作って守らせることに違和感を感じる感性も正しいと思う。
チーム（もしくはマネージャー）に求められるのは、こうした「何かチームに嫌な感じがある」ときに軌道修正できることだ。
一例でしかないが、例えば以下の流れでルールを作らずに、解決できることもある。
コミュニケーションコストを、チームを維持するのに必要なコストとして、きちんと時間を割けるかが重要だと思う。
さらに言えば、「それは有害な振る舞いだと自分は思うが、あなたがそう思わない理由は何か」とコミュニケーションを取れないのであれば、そこに課題があるだろう。
チームやマネージャーがある人を「難しい人だなあ」と思ったとして、2つの解決策が出てこないのなら、その思考には課題があるのではないか。
「他者に配慮できる」という曖昧な基準で異物を弾くようなチーム作りは、蛸壷化して致命的な結果を引き起こすことがある。
パワハラ、セクハラ、試験結果改ざんが、「なんでそんなんなるまで誰も言わなかったんだよ」となるのは、
「その構成員が他者に配慮できる人たちで構成されていて、異物を弾き続けた結果」であることが多い。
少なくとも、「エンジニアの”有害な振る舞い”への対処法」には、機会、動機、正当化のいわゆる不正のトライアングルのうち、動機と正当化を満たしている。
いやいや極端だろと思うだろう？
快不快が、正しい正しくないに繋がっていることは社会生活を送っていると極めて多い。
「マネージャーならば」法律や外部の意見も含めてかなり慎重に判断する必要がある。
「エンジニアならば」相手に快適に聞こえるようにコミュニケーションするスキルは磨いておいて損はない。
（あと、機械的に判断可能なルールを守ることが自分を守ることに繋がる。ルール順守か業績なら、常にルールを守れ。記録を軽視するな）
