公共ギャンブルに於ける乱数の生成について疑問が湧いたので調べてみた
totoBIGの件は何が問題なのか、なるべく分かりやすく説明してみる: 不倒城
http://www.toto-dream.com/press/20170220.html
ここ最近話題のtotoBIGの件、上記のBlogにおいて擬似乱数生成の仮定において精度の甘い実装になっていたということが指摘されていた。
自分も概ねそのあたりが原因ではないかと思っていました。テクニカルな面についてはこの記事の通りで不足ないと思います。
では、一方でポリティカル(要するに法律や業界規制、公安委員会や保安通信協会とのやり取りを含めて)の部分はどうかというと、上記のような問題が発生してしまっても仕方ないという状況にあるのではないかと疑問に思ったので、色々調べてみた。
totoBIG同様に乱数を利用するパチンコについて、平成18年に特許庁が取りまとめた資料。項目「2-4 抽選機能」にその言及が有る。
平成18年度 標準技術集 遊技機及びその関連技術 | 経済産業省 特許庁
調査対象技術の技術概要
2-4-2-1 乱数方式
乱数とは 、無秩序でかつ全体として出現頻度が等しい数の系列を指すが、デジパチタイプの遊技機など、図柄表示装置によって当選の可否を表示する遊技機においては、特賞等の役の当選の可否を判断するために、メイン基板内部で常に乱数をカウントしている。
乱数の生成は、ソフトウェアで行う方式(ソフト乱数方式)と、ハードウェアで行う方式(ハード乱数方式)に大別することが
出来る。また、ソフト乱数方式は、乱数のカウントが進行する形態の違いによって、プラスワン方式とプラス乱数方式に分類される。
乱数幅変更機能付き遊技機 - 特開2004−298370 | j-tokkyo
乱数発生手段10aは、例えばカウンタIC等からなり、所定の乱数幅の範囲(例えば1〜16384)でダウンカウントやインクリメントカウントすることにより、一定時間毎に一の乱数を発生させる。そして、この乱数発生手段10aで発生する乱数の上限値が乱数幅変更手段10eによって変更され、これによって抽選処理における各入賞内容の当選確率が変更されることになる(図5参照)。
ここで、乱数発生手段10aとしては、例えば、カウンタICを用いて乱数となる数字をハードで生成して取り出すハード乱数と、CPUのソフトウェアによって乱数となる数字を生成するソフト乱数とがあり、本実施形態の乱数発生手段10aは、いずれの方式であっても良く、両方式を併設することもできる。
http://law.e-gov.go.jp/htmldata/S60/S60F30301000004.html
また、警察庁生活安全局保からの通達において、遊技機についての規格解釈基準が発行されている。
平成16年5月26日警察庁丁生環発第155号
内部抽せんは、条件装置の作動等、遊技の結果に影響を及ぼすものである。出現する乱数値に偏りが出る仕組みは「当せんする機会を容易に推定することが、できる仕組み」であると解する。よって、内部抽せんが、周期が一回の遊技の結果が得られるまでの間において終了しない仕組みである等出現する乱数値に偏りが出る仕組みである場合には、当該内部抽せんの偏りが出る仕組みは、本規定に抵触する。
当り乱数を現状の初期値更新型乱数とした場合、大当り判定値には素数以外を使用してよい。
基本乱数について、乱数にあるそれぞれの値の発現方式が、乱数の数列に沿って順々に値を発現させる方式(本集で「プラスワン方式」という。)と、乱数の数列の最終値が発現したときの次の値(本集で「初期値」という。)を偶然性のある値によって定める方式(本集で「初期値更新方式」という。)を併用している等、基本乱数値を容易に推測させない方式である場合に、当たり判定データ値が素数以外であること又は複数の連続した数値であることは差し支えない。ただし、基本乱数を構成する値の総量、当たり図柄乱数を構成する値の総量等、内部抽せんに係る乱数を構成する値の総量は互いに素であるか、又は当該乱数における一の値の発現から次の値の発現までの時間間隔が互いに素でなければならない。
ソフトのみで更新する当り乱数(カウンタ)は1割り込み毎に+1更新するカウンタとすること。
基本乱数にあるそれぞれの値の発現方式がプラスワン方式であることは、別表第三(2)ハ(ニ)の規定に適合する方式である限り差し支えない。
当り判定に、プログラムより高速でカウンタを更新するハード乱数を使用してよい。
基本乱数にあるそれぞれの値の発現方式がプラスワン方式であること等、当該基本乱数にあるそれぞれの値の発現が規則的である方式であっても、別表第三(2)ハ(ニ)の規定に適合する方式である限り差し支えない。
別表第三 不正な改造その他の変更を防止するための遊技機の構造に係る技術上の規格」関係
(2)ハ(ニ)内部抽せんは、条件装置の作動等、遊技の結果に影響を及ぼすものである。出現する乱数値に偏りが出る仕組みは、「当せんする機会を容易に推定することができる仕組み」であると解する。よって、内部抽せんが、周期が1回の遊技の結果が得られるまでの間において終了しない仕組みである等出現する乱数値に偏りが出る仕組みである場合には、当該内部抽せんの偏りが出る仕組みは、本規定に抵触する。
また、気になってJ-PlatPatで「乱数」をキーワードに含む特許を調べたところ、遊技機もしくはパチンコで登録された乱数に関する特許は1994年が初の出願となっていた。
上記のように警察の解釈や特許の状況を見るに、状況証拠での判断となるが(保安通信協会の内規など一部資料には簡単にアクセスできなかったため)、乱数の取り扱いに関しては規定があるものの、乱数そのものの生成方式の制約ついて言及はなく、生成方式固有の偏りについてもまた言及がない(乱数生成後の処理による偏りについての言及は有る)ということがわかった。
このような状況下においてtotoBIGのようなシステムを作る場合(もちろんパチンコとは別の話し合いが有ると考えられるが)、技術仕様を満たしていれば合法であり、たとえ実装上の擬似乱数において今回のような事象が発生したとしても、誰にも否はないと判断せざるを得ない。
ただ、この状況をこのままにしておくかどうかについてはまさに政治的判断が必要で、正しい改善方法としては法律もしくは省庁からの通達において、乱数生成については真性乱数を利用することを明記するしかないと思わる。
(もちろん真性乱数とは何か、真性乱数発生器の検査は誰がやるかなど新たな利権は生まれそうだが…)
話は飛ぶが、真性乱数発生器も昔に比べるとだいぶお手頃になったと思う。一個くらい買って遊んでみたい。
読モ化はライターだけではない、もっと広域な作り手側の問題だと思う
http://bylines.news.yahoo.co.jp/miyazakitomoyuki/20170207-00067457/
「ライター」を名乗り、それを生業にしている筆者は、ライターを取り巻く現状について考えることが多い。といっても、現在では「ライター」の定義自体が揺らいでいて、同業者と話していても共通認識が得られず、議論が空転することもしばしばだ。しかしそこに、「ネットやSNSの出現によって、ライターの仕事が『読モ』みたいなものに近づいている」という補助線を引くと、現状がクリアになる気がする。
このニュースを読んで色々と頭にあったことが筆者と同じく自分自身もだいぶスッキリした。作者も書いているとおりだけれど、この「読モ化」という概念を咀嚼する上でまず整理しよう。
- 作り手
- 記事のライターや、クリエイター、技術者など
- 物を作ったり技術を探求する人などが該当
- コンテンツを供給する側の人
- 受け手
- 消費者や読者など、作り手が作ったコンテンツを受給する側の人
- 読モ化
- 「顔出し」や「本人そのものがコンテンツ化(商品化)」する事
- 主に作り手側の意識や戦略、身なりに関する表現
- 読モ化した作りて手には、作品より作者本人に価値があると言う周囲の認識が伴う
- また読モ化した作り手の特徴として、作品作りは「自身のタレント性を表現する一つの手段」であり、こだわる必要がない(偶然それができるからそれをやっているに過ぎない)
- 例)「ライターの過度な顔出し(本人が出ることがコンテンツである、彼とか)」「コスプレイヤーの作品再現より本人が前に出た作品など(その作品のキャラになるのは自身に注目を集めるための手段)」「ボカロ曲を作っていたと思ったら本人のニコ生が始まって曲を作らなくなった(曲を作るのは注目を集める手段)」
- 読モ力
- 作り手側の「読モ化」の度合い。受け手側(読者や消費者など)が感じ取るバロメーター
- 主に受け手側がその人やその作品を判断するときの基準としている(無意識にしている場合が多い)
- 例)「あの作者が可愛いから作品を買う(買う動機は、あくまで可愛い作者だから)」「可愛い女の子が登壇するからXamarinの勉強会に行く(勉強会に行く動機は可愛い女の子に会えるから)」
- このように作りて側の「読モ化」が受け手側の行動に作用するエネルギーを「読モ力」として考える
「読モ化」が主に作り手側の変化の話なので、その変化に伴うエネルギーを「読モ力」とした。こうすることで理解が進む。
「読モ化」はなぜ発生するのか
先程の記事では「読モ化」しているという話だったが、掘り返してみるとなぜ作り手が読モ化するのか、と言う疑問が湧いてくるはず。そこで自分なりに頭を整理してみた答えがこれだ。
- 受け手側が作品の善し悪しを判断するときに、作者の人間性を気にする文化はもともとあった(ネット時代よりもさらに前からの前提として)
- ネット時代が到来し(概ねWeb2.0到来以降)作品を公開するあらゆるプラットフォームが整備され、ネット上に大量の作品が溢れた
- ネット上に大量に作品が溢れた結果、受け手側の自分好みの作品を探し出す手間が膨れ上がった
- ネット上に大量に作品が溢れた結果、作り手側の練度は大幅に向上し所謂「うまい作品」が増えた
- 3,4のサイクルが何回か回った結果、ネット上に「うまい作品*1」が溢れ、さらに受け手側の手間が膨大になった
- そして「うまい作品」は希少性を失っていった(「うまい作品」であるためのハードルが遥か高くに設定されてしまった*2)
- 作品の希少性が失われると、作り手側に還元される「承認」は不足し、作り手は「承認不足」の状態になる(その作品へのアクセスが増えたとしても、反応は減るため)
- 作り手側は「承認不足」の状態を脱却するために、より楽に注目を集める事ができる差別化要因を探し出す
- この時並行して受け手側も作品探しに疲弊しており楽な方法を探していった結果、作品とは関係ない作者の人間性を気にするという文化が先鋭化していった
- 受け手のそのような変化は、作り手側から楽で効果のある差別化要因として認識される
- 結果として本人自体を売りとする手法や考え方が確立され広がっていった
この流れの中で受け手側の疲弊を解消するために生まれたのがキュレーションという考え方です。(悪用されちゃったけど機能としては良い)
また、「読モ化」が進みすぎた結果発生するのが「オタサーの姫」であり、諸問題色々有るけれど根源はここかと。
このように、受け手側と作り手側の変化が双方に影響を与えながらお互いに妥協点を探していった結果が「読モ化」であると考えている。
「読モ化」と承認欲求とメリットデメリット
先程の解釈の上では「承認」と「承認不足」という単語を出して説明した。これは単に承認欲求に於ける承認の話。ただし、一般的な承認欲求に於ける承認の解釈に「支払われる報酬も承認である」という解釈を加えた上で、この「読モ化」を咀嚼する必要がある。
というのも、この記事に於いては特に生業としてのライター(Webで記事を書くライターも含めて)の「読モ化」も指摘しているからであり、それ以外の理由としても、今現在生業としての「作り手」が置かれている状況を加味すると、報酬と承認は切り離せない関係にあるからである。
自分自身クリエイターもやっているので報酬はよく意識しているが、生業としての「作り手」にとっては「SNSでもらえるいいねやFav」と同様に「やった仕事でもらえる報酬」や「尊敬する人やすごい人と一緒に仕事ができたこと」についてもその仕事を続ける上、作品作りを続ける上では重要な承認である。
これらの承認の要素に「読モ化」がどのような影響を及ぼすかというと
メリット
- 「読モ化」することで本人に注目が集まり、アクセスが欲しいクライアントの意向とマッチする
- 「読モ化」することで担当に気に入られることで仕事が増える、結果として報酬も増える(ここで安価な発注をするとご破算になる。女性ほど有利な手法)
- 「読モ化」することでつながりが増えて業界の中で生きているぜっていう感覚が生まれる(自己承認を行う)
- 「読モ化」することで何となく自分は特別という感覚が芽生えてきて仕事に取り掛かれる(自己暗示に近いけど実際効果はある)
デメリット
- 「読モ化」すると周りの職人気質な作り手からバカにされたり軽蔑される(しかし本当にデメリットはあるのか?交友範囲でカバーできるのでは?)
- アンチが増える(しかし、精神力が強ければ耐えられる、所詮ネットだし)
- 「読モ化」するとプライベート含めて人生オープンソース化するので、家庭持ちには辛いかも(やまもといちろうみたいな例も有るが、敵を作らなければ良いという話もある)
- 女性が「読モ化」すると、アンチに加えてストーカーも発生する(そして実際に事件になる例もあるが極稀である)
色々と考えてみたが「読モ化」はアンチが増えるがそのデメリットを無力化できる一般常識や思考力や精神力があれば、いい事だらけでありむしろなんでやらないのと言い出しそうな人が多分にいるのもよく理解できる。
「読モ化」について作り手が取るべきバランス
記事の中で筆者は
筆者が思うのは、おそらく現在、多くの人が「ライター」としてイメージするのは「読モ」としてのライターなんだけど、彼らが物書きとしての「本流」になることはないということだ。
と述べているがこれは本当だろうか?
おそらくこの記事を書かれた胸のうちにあんな奴らとは違う俺は本流だ、というような意識を垣間見えることができる。たしかに一般的に見て「読モ化」していくとチャラく見えるので、実力がないのにちやほやされやがって、と思われるのは仕方がないことだろう。ただし、本流かどうかはその本人の実力や作品自体の練度の高さが物語るのであって、決して「読モ化」と同じに語ってはいけない。
「読モ化」すると身の丈にあっていない仕事が来ることはおそらく増えるだろう。ただし、作り手ならば来た仕事に全力で答えて身の丈を伸ばして行けばよいだけの話で有る。ただ、この筆者が指摘したいことは多分、「読モ化」することによって、実力を伸ばすような仕事が来なくなり(周りはキャラを売ることを求めるから)、「本流」を伸ばすための実力が付かなくなる(実力をつけるための余力がなくなる)ことを懸念しているのではないかと考えられる。(汲み取り過ぎかもしれんけど)
作り手が「読モ化」という禁断の果実に手を出すときは、そのバランスを見誤ってはならない。より自分におごること無く、実力がつくかどうか、人気が出るかどうか、承認は増えるかどうか、をバランス良く考えていくことが重要となる。
このバランス感覚を鍛えた上で「読モ化」という手段をとれるならば、それはとても強い武器になると思う。
「読モ化」の失敗例
失敗から学ぶのは重要である。「読モ化」の失敗例は身の回りに転がっているからよく観察するといいだろう。決してコードをあまり書かないが開発者向けに勉強会と称した事実上の姫集会をやっているような人になってはいけない。
Infinite Storage 220をDS3400にする
概要
自宅ストレージの強化を行うために、ひょんなことからSGI InfiniteStorage 220を手に入れたので色々調査したところ、IBM System Storage DS3400と中身が同じ(OEM供給元一緒?)だったので、FW書き換えとかそのあたりの話。というか、ニッチ過ぎて需要があるかわからないけどとりあえず。
という訳でまずは手順から。だいたいこんな感じで作業していきます。
SGI IS220 > FW書き換え > IBM DS3400(v06.70.69.00) > FW書き換え > IBM DS3400(7.35.66.00系FW)
ココでこだわりたいところは、FWがversion 7.xx.xx系であること。これはなんでかというと、LUNのサイズ上限が解除されるため。6.xx.xx系FWではLUNのサイズが2TBで強制的に切られるため、単一ボリュームとして大容量なものを用意するときには物足りない。あと7.xx.xx系ではRAID6が使えるのでこのあたりも色々とベンチしてみたいところ。
- FW7.xx.xx系での6.xx.xx系からの主な変更点
- Added support for RAID 6 (p+q implementation) - Support for greater than 2TB Logical Drive. - Support for RAID 0 and 1 arrays with more than 30 drives. - Increase maximum number of partitions to 32. - Support for IPv6 on the controller management Ethernet ports. - Support Telnet protocol on the controller management Ethernet ports.
IPv6対応が面白い。こういうネットワークに繋がるけど本格的にネットワーク使わない感じのHWのIPv6対応はまだ珍しいので、どんどん頑張って欲しいところ。あとTelnetが地味に便利。コンソールケーブルが独自形式なのでケーブル無いときに。
ファームウェア書き換え
という訳でファームウェアの書き換えを行う。今回はIBM System Storage DS Storage Manager version 10.77.35.16を使った。Versionは10.77系以降であること。古いVersionではアップデートに失敗したり、ソフトウェア側がFWに対応しきれていない。
手順としては、Storage ManagerでIS220へ接続し、FWを更新していくだけ、FWのVersionにあわせたNVRAMは適切なタイミングで上書きしていく。
というわけで
View Storage Subsystem Profileの出力が変更されていることを確認。
- 変更前
Number of controllers: 1 Controller in Enclosure 85, Slot A Status: Online Current configuration Firmware version: 06.70.41.00 Appware version: 06.70.41.00 Bootware version: 06.70.41.00 NVSRAM version: N1932-670863-100 Board ID: 1932 Submodel ID: 64 Product ID: IS400 Product revision: 0670 Serial number: ########## Vendor: SGI
- 変更後
Number of controllers: 1 Controller in Enclosure 0, Slot A Status: Online Current configuration Firmware version: 07.35.66.00 Appware version: 07.35.66.00 Bootware version: 07.35.66.00 NVSRAM version: N1726D34LR335V06 Board ID: 1932 Submodel ID: 64 Product ID: 1726-4xx FAStT Revision: 0617 Replacement part number: 097-0329-001 Part number: 21201-07 Serial number: ########## Vendor: IBM
VendorがIBMに、Product IDはFAStTとなって、中身がまるっとDS3400化。シリアル番号は同じままでした。後はこのまま運用試験をしてみようかと。
Macmini(Early 2006) メモ
WindowsXPでIEEE1394デバイスを使う必要があったので、転がっていたMacmini(Early 2006)にWindowsXPを突っ込んでました。ドライバ周りで苦戦したのでそのあたりメモ。
デバイス | 詳細 | その他 |
CPU | Core solo 1.5Ghz | Core2Duo(Merom)まで換装可能 |
チップセット | Intel GAM 950 | 内蔵VGADriverも同時に入れる |
RAM | PC2-5300 DDR2 256MB*2 | MAX 2GB |
HDD | ST96812AS | 5400.2 SATA 1.5Gb/s 60-GB Hard Drive |
LAN | Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller | |
WLAN | Atheros AR5006X Wireless Network Adapter | 802.11a/b/g |
Sound | SigmaTel High Definition Audio CODEC | Ver 5.10.5185.0 OSX インストールディスクのwindows supportからインストール |
Drive | MATSHITA CD-RW CW-8124 | COMBO |
ドライバーインストール手順としては、http://macxp.furbism.com/ にある「mini.drivers.all.zip」を入れた後に適当なOSXインストールCDからBootCampサポートを入れることで完了。AudioDriverを無線LANDriverがOSXインストールCDに収録されているものでしかインストールできなかったので注意。
SSL証明書更新
PKCS#12ファイル(拡張子 .pfx)から既存のSSL証明書を更新する手順メモ。
# pfxファイルから中間CA証明書ファイルを取り出す openssl pkcs12 -cacerts -in ほげほげ.pfx -out cacert.cer # pfxファイルから秘密鍵を取り出す # 抜き出した秘密鍵を暗号化する必要がなければ「-nodes」を付ける openssl pkcs12 -nocerts -nodes -in ほげほげ.pfx -out ほげほげ.key # pfxファイルからサーバ証明書を取り出す openssl pkcs12 -clcerts -nokeys -in ほげほげ.pfx -out ほげほげ.cer
あとは抜き出したそれぞれのファイルをssl.confの指定した場所にある既存のものと入れ替える。ちなみにopensslで証明書の有効期限を確認するにはこうする。
openssl x509 -noout -text -in (crtファイル)
SSHログインをメールで通知する
複数人でサーバを管理していると、誰がいつサーバにログインしたかを管理したくなってくる。というわけでSSHでログインしたときにメールで通知するようにしてみた。仕組みとしてはsshrcに通知スクリプトを仕込むという簡単な物
/etc/ssh/sshrc
echo "\"$USER\" has logged in from $SSH_CLIENT at `date` " | mail -s "SSH LOGIN INFO" 通知先アドレス
変数名 | 内容 |
$SSH_CLIENT | 接続元IPアドレス |
$SSH_TTY | 利用しているttyの名前 |
$USER | ログインユーザ名 |
sshrcで任意のスクリプトが実行できるので、ログイン情報をDBなりなんなりに突っ込むとかも可能。管理台数が増えたときはそっちにしたほうが良さそうです。
Scientific Linux のyumレポジトリ設定
というわけで、yumで自前のミラーサーバを参照するような設定。
/etc/yum.repos.d/sl.repo
[sl] name=Scientific Linux $releasever - $basearch baseurl= http://ftp.tsukuba.wide.ad.jp/Linux/scientific/$releasever/$basearch/os/ http://ftp.scientificlinux.org/linux/scientific/$releasever/$basearch/os/ http://ftp1.scientificlinux.org/linux/scientific/$releasever/$basearch/os/ http://ftp2.scientificlinux.org/linux/scientific/$releasever/$basearch/os/ #mirrorlist=http://ftp.scientificlinux.org/linux/scientific/mirrorlist/sl-base-6.txt enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson [sl-testing] name=Scientific Linux $releasever Testing - $basearch baseurl= http://ftp.tsukuba.wide.ad.jp/Linux/scientific/6rolling/testing/$basearch/ http://ftp.scientificlinux.org/linux/scientific/6rolling/testing/$basearch/ http://ftp1.scientificlinux.org/linux/scientific/6rolling/testing/$basearch/ http://ftp2.scientificlinux.org/linux/scientific/6rolling/testing/$basearch/ enabled=0 gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson [sl-source] name=Scientific Linux $releasever Alpha - Source baseurl= http://ftp.tsukuba.wide.ad.jp/Linux/scientific/$releasever/SRPMS/ http://ftp.scientificlinux.org/linux/scientific/$releasever/SRPMS/ http://ftp1.scientificlinux.org/linux/scientific/$releasever/SRPMS/ http://ftp2.scientificlinux.org/linux/scientific/$releasever/SRPMS/ enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson [sl-testing-source] name=Scientific Linux $releasever Testing - Source baseurl= http://ftp.tsukuba.wide.ad.jp/Linux/scientific/6rolling/testing/SRPMS/ http://ftp.scientificlinux.org/linux/scientific/6rolling/testing/SRPMS/ http://ftp1.scientificlinux.org/linux/scientific/6rolling/testing/SRPMS/ http://ftp2.scientificlinux.org/linux/scientific/6rolling/testing/SRPMS/ enabled=0 gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson
/etc/yum.repos.d/sl-updates.repo
[sl-security] name=Scientific Linux $releasever - $basearch - security updates baseurl= http://ftp.tsukuba.wide.ad.jp/Linux/scientific/$releasever/$basearch/updates/security/ http://ftp.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/security/ http://ftp1.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/security/ http://ftp2.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/security/ #mirrorlist=http://ftp.scientificlinux.org/linux/scientific/mirrorlist/sl-security-6.txt enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson [sl-fastbugs] name=Scientific Linux $releasever - $basearch - fastbug updates baseurl= http://ftp.tsukuba.wide.ad.jp/Linux/scientific/$releasever/$basearch/updates/fastbugs/ http://ftp.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/fastbugs/ http://ftp1.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/fastbugs/ http://ftp2.scientificlinux.org/linux/scientific/$releasever/$basearch/updates/fastbugs/ #mirrorlist=http://ftp.scientificlinux.org/linux/scientific/mirrorlist/sl-fastbugs-6.txt enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson