アカウント名:
パスワード:
全部の鍵が掛かった状態＝実際に鍵か掛かった状態、なのでANDだよね？
普通にTTLで設計したら、入力をどこにも繋がないときに鍵が掛かるようにするだろうから、(鍵を空けるときだけ電力を消費する)
HI -- 鍵が掛かるLO -- 鍵が外れる
が無難だろうからANDゲートかな。
CMOSだったらどうするか。同じロジックにしとくだろうな。
1つの錠が解除された状態＝実際に錠が解除された状態、なのでOR？
ところでらばQに
これは共有のセキュリティの脆弱性で、バカな誰か1人がロックし忘れることで、いつか失敗する。
ってコメントがあったけど、それは別に「共有のセキュリティの」ではなくて、単に鍵をかけ忘れるという脆弱性でしかないよね。
その通りしかもこの場合、バカがどっち側にいるのかが明白なのが素晴らしい
各社が専用の扉を作ると・・・
シャープの冷蔵庫みたいに左右両方開きのドア作ってた奴も。でも、3社目からは結局一緒でコストが無駄にかかるだけ。
南京錠でチェーンを形作る奴は、抜かして繋いだ奴が居てわざわざ連絡して開けに来て貰った覚えが有る。
鍵の紛失に対して対象1グループの錠を交換するだけで対処完了なのはむしろ脆弱期間の短縮と作業の軽量化でセキュアップよね
QRと空目してしまい、そんなところまでQRコードを読み取らせてカギを開けるようになっているのかと驚いてしまったのに……
なんで論理演算の話が出てくるのかしばらく気づかなかった orz
目的が鍵を操作なら、ご指摘の通り。目的が柵を通ることなので、 通れる 真 通れない 偽という論理和でいいんじゃない。
鍵が鍵の意味か、錠の意味か、みたいな？
錠 [wikipedia.org]の息子さんが開 [wikipedia.org]なので錠を選ぶなら開を１とした論理＝OR論理でいいと思いまーす
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
ANDじゃねーの定期 (スコア:2)
全部の鍵が掛かった状態＝実際に鍵か掛かった状態、なのでANDだよね？
Re:ANDじゃねーの定期 (スコア:2)
// どっちがどっちなのかややこしいから仕方ない
Re: (スコア:0)
普通にTTLで設計したら、入力をどこにも繋がないときに鍵が掛かるようにするだろうから、(鍵を空けるときだけ電力を消費する)
HI -- 鍵が掛かる
LO -- 鍵が外れる
が無難だろうからANDゲートかな。
CMOSだったらどうするか。同じロジックにしとくだろうな。
Re:ANDじゃねーの定期 (スコア:1)
Re:ANDじゃねーの定期 (スコア:2, 参考になる)
1つの錠が解除された状態＝実際に錠が解除された状態、なのでOR？
ところでらばQに
これは共有のセキュリティの脆弱性で、バカな誰か1人がロックし忘れることで、いつか失敗する。
ってコメントがあったけど、それは別に「共有のセキュリティの」ではなくて、単に鍵をかけ忘れるという脆弱性でしかないよね。
Re:ANDじゃねーの定期 (スコア:2, 参考になる)
その通り
しかもこの場合、バカがどっち側にいるのかが明白なのが素晴らしい
Re:ANDじゃねーの定期 (スコア:1)
各社が専用の扉を作ると・・・
Re: (スコア:0)
シャープの冷蔵庫みたいに左右両方開きのドア作ってた奴も。
でも、3社目からは結局一緒でコストが無駄にかかるだけ。
Re: (スコア:0)
南京錠でチェーンを形作る奴は、抜かして繋いだ奴が居てわざわざ連絡して開けに来て貰った覚えが有る。
Re: (スコア:0)
鍵の紛失に対して対象1グループの錠を交換するだけで対処完了なのは
むしろ脆弱期間の短縮と作業の軽量化でセキュアップよね
Re:ANDじゃねーの定期 (スコア:1)
QRと空目してしまい、そんなところまでQRコードを読み取らせて
カギを開けるようになっているのかと驚いてしまったのに……
なんで論理演算の話が出てくるのかしばらく気づかなかった orz
Re:ANDじゃねーの定期 (スコア:1)
目的が鍵を操作なら、ご指摘の通り。
目的が柵を通ることなので、
通れる 真
通れない 偽
という論理和でいいんじゃない。
Re: (スコア:0)
鍵が鍵の意味か、錠の意味か、みたいな？
Re:ANDじゃねーの定期 (スコア:1)
錠 [wikipedia.org]の息子さんが開 [wikipedia.org]なので錠を選ぶなら開を１とした論理＝OR論理でいいと思いまーす