コメント: Re:Edgeも追従して (スコア 5, 参考になる) 58
頭に?をつける
おしまい
アナウンス:スラドとOSDNは受け入れ先を募集中です。
頭に?をつける
おしまい
神父というのは、カトリック、正教会の司祭職の事であり、叙階の秘跡を受けた有資格者で、終身独身です。結婚の秘跡は信者に限られます。相手が信者では無い場合入信を強く勧められます。司式する教会以外で結婚の秘跡を授ける事はまず無いです。
プロテスタントには司祭職が無いので、牧師が司式しますが、牧師も一応有資格者です。牧師は司祭では無いので結婚、子作りが出来ます。結婚式場に出向く事も有りますが、労力の割に入信者が増えない事、高齢化による人手不足もあって、乗り気では無いようです。そのため信者が頼まないと来てくれない事の方が多いです。
神父と牧師の混同、FLOWERSでも間違った記載あってちょっと悲しかった。
という訳でアルバイトです。一応資格を持っていても教会を持たない牧師もいるのですが、仕事してるのに、こんな不定期なアルバイトしません。
次に外国人のプータローのアルバイト。万人祭司という考えがあって、司祭がいない時には信者は誰でも司式出来るというものです。牧師もルターの宗教改革の時に万人祭司の考えに基づいて出来た教師職です。そのため宗派に限らずクリスチャン3人(司式役1名 証人2名)であれば誰でも緊急避難的に結婚を司式可能です。緊急避難じゃない、牧師でも無い、証人いないし。
次に結婚式場の職員。外注費も発生しないし時間も柔軟に対応できるね。クリスチャンですら無い。
したがって結婚式場のあれは、神父でも牧師でも無いので、アレと呼んでください。
カイルくんに「お前を消す方法」とかばかり言うからイルカの逆襲が始まったぢゃないかっ!!
という冗談は置いといて、原理がわかると夏休みの自由研究ネタになるぐらいのものですね。
ざっと96KHzサンプリングレートのサウンドカードがあれば実験出来そうな感じ。
データだけPCで作ればハイレゾプレーヤーでの再生でも(音圧をどう稼ぐかの問題は置いといて)
なんとかなったりするのかな?
人間の可聴域外の音なのに機械を通すと可聴域内の音が聞こえるってのはいろいろ遊べそうだ(謎)
例えばノイズキャンセラー付きのヘッドフォンを使ってる人だけに耳障りな音を送るとか :)
恋人や女房の気持ちが一番理解できないんですよ。
友達じゃないからね。
はっきりと見たことはありませんが、せいぜい5x5くらいのマトリクスです。指でサインを出すからそれ以上は難しい。
サインを出す前に捕手が乱数表を見る、サインを見た投手が乱数表を見る、の2工程が増えるわけですが、一試合トータルでは百数十球を投げるため累積するとばかにならない時間になるみたいです。
打者にしてみれば間合いの長さという感覚的なものもあるでしょうね。
百分の一秒の違いでヒットになるかならないかも左右されるため、打席に立っているときは非常に集中力を必要としますから。
空気自体の非線形性を利用するならパラメトリック・スピーカーがあるね。
ローパスフィルタ前のマイクとマイクアンプの時点で可聴域の音が出てる。
で、ローパスフィルタで超音波成分を削ると復調された可聴域だけが残る仕組み。
どうも、非対称な入力に対してDCオフセットが積み重なるのが原因みたい。
AM変調音だけだと可聴域は出ないが、搬送波成分を加算したらAM復調されるみたいな事が書いてあった。
CSP を導入しているけど、インラインスクリプトが使えないと不便だからか 'unsafe-inline' を許可しているサイトも多いですが、危険だし、中途半端で美しくないポリシーだと思います。
6. Content Security Policy Directives より
In either case, developers SHOULD NOT include either 'unsafe-inline', or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.
'unsafe-inline' は XSS 攻撃を可能にするので、いずれのケースであっても、指定すべきでない (SHOULD NOT) とされており、(危険なため)'unsafe-inline' や 'data:' は完全に避けるのが最善(they are best avoided completely)とも書かれています。
# 一応補足しておくと、nonce を使って 'unsafe-inline' の安全性を高める方法も W3C 勧告に書かれています
そもそも、CSP を導入する主目的は、エスケープ漏れで XSS (インジェクション系の脆弱性) があった場合に、注入された不正なスクリプトが実行されるのを防ぐためだと思います。'unsafe-inline' という SHOULD NOT な指定をしてしまうと、XSS 脆弱性があったときに不正なインラインスクリプトが実行されてしまう恐れがあり、その時点で手遅れとなります。
仮に他のポリシーで form の post 先のオリジンを限定していたとしても、例えば Cookie に含まれるセッションIDを盗みたい場合には、同一オリジンにブログのコメント欄があったらそこに post して盗み取るとか、お問い合わせフォームを悪用(差出人を攻撃者のメールアドレスにして、問い合わせ内容にセッションIDを含めフォームを送信し、送られてくる控えからセッションIDを盗むなど)するなど、あらゆる方法で悪用できてしまいます。
初期値を変えるのにコードいじる必要があるのはそれほど問題とは思わないけど。
パッチ見る限り初期値についてはmodules/libpref/init/all.jsで集中管理していて、
今回、AndroidとUnix Likeのそれぞれの初期値を変えるために1行ずつ削っただけ。
変更は簡単であるけど、優先度は低いことが想像されるし、
だれかパッチ送ってくれたら余裕があるときに取り込むわ的ノリは理解できる。
ヘンタイは、アブノーマルか、ジーク
変態は、メタモルフォーゼか、メタモルフォーシス
変形は、トランスフォーム
変貌は、トランスフィギュアー
変化は、チェンジ
片仮名で言い換えた気になってみました。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー