パッケージ管理(yum)
日頃お世話になっているくせにいざLPIC問題を解いてみると悲惨な結果だったので、きちんとまとめてることにする。あずき本からの抜粋。
yumの設定は/etc/yum.confと/etc/yum.repos.d/ディレクトリ以下のファイルでおこなう。以下の表は、yumコマンドの主なサブコマンド。
| サブコマンド | 説明 |
|---|---|
| check-update | アップデート対象のパッケージリストを表示する |
| update パッケージ名 | 指定したパッケージをアップデートする |
| install パッケージ名 | 指定したパッケージをインストールする |
| remove パッケージ名 | 指定したパッケージをアンインストールする |
| info パッケージ名 | 全パッケージリストを表示する |
| list | 指定したパッケージをアップデートする |
| search キーワード | パッケージを検索する |
| grouplist | パッケージグループをリスト表示する |
| groupinstall グループ | 指定したパッケージグループをインストールする |
とりあえず、しばらくは試験のためわかっていると思われることも再学習することにする。(だいたい曖昧だったりするからね。)
東電福島原発事故 総理大臣として考えたこと
安倍総理は施政方針演説において
原子力規制委員会の下で、妥協することなく安全性を高める新たな安全文化を創り上げます。その上で、安全が確認された原発は再稼働します(安倍首相:施政方針演説 原発再稼働明言 「安全確認なら」- 毎日jp(毎日新聞))
と言った。しかしながら完全な安全など絵に描いた餅であり、遠い天空の彼方から巨大な隕石が降ってくる事はあいかわらず想定外だし、想定震度はたかだか人間の想像範囲内でしかない。次の災いは決して我々が想像し得ない角度からやってくる。
浜岡原発停止を要請した後見舞われる強烈な「菅降ろし」がはじまる。まるで、事故のすべてが彼の無能によるものであるかのごとく扱われる報道。もちろん、本書は当事者の筆によるものだから管さんにとって都合の悪いことは書いていないかもしれない。しかし、マスコミの報道もまだ同様であることもまた同じである。
まず、私たち日本人が経験した福島原発事故が国家存亡の危機であったという共通認識を持ち、そこから再スタートすべきだ。それを忘れた議論、無視した議論はまさに「非現実的」な議論だ。
311以降、福島で起きたことのすべては、東電の無責任かつお粗末な対応や、もちろん総理をはじめとする政府の不手際もあるだろう。しかし辛うじて破滅を回避し今日を迎えることができた今、考えるべきは今後の国のあり方ではないか。
お手製の演台に「原発ゼロ」を掲げるたったひとり。彼を支持せざるを得ない。
| 東電福島原発事故 総理大臣として考えたこと (幻冬舎新書) | |
![]() |
菅 直人
幻冬舎 2012-10-26 |
二項関係の数
練習問題やった。解答がないのであっているのか...
n個の要素を持つ集合Aについてその二項関係の数
個。そいで、冪集合の要素数は、
個。そのうち、反射関係は
個、対称関係であるものは
個。おもしろい。
組合せ数の求め方
HaskellでProject Euluerとかその他パズルとか解くとき、組合せの数が必要になることがよくあるけどこれまでは公式どおり
combination :: Int -> Int -> Int
combination n k
| n < k = 0
| n == k = 1
| otherwise = truncate((fromIntegral n') / fromIntegral((k' * kn')))
where
k' = factorial k
n' = factorial n
kn' = factorial (n-k)みたいなコードを使ってたんだけどhaskellで組合せと順列 - 計算機と戯れる日々を発見。さすが、nobsun!
パスカルの三角数は生成するコードを書いたことはあったんだけどこのコードと比べるとなんとも垢抜けないコードでとても晒せない。こういうコードをサクっと書ける関数脳なプログラマになりたいものだ。
-- pascal's triangle
triangle :: [[Integer]]
triangle = [1]:[zipWith (+) ([0]++t) (t++[0])|t <- triangle]
combination :: Int -> Int -> Integer
combination = (!!) . (triangle!!)
スターリング数(漸化)
スターリング数の漸化式もあったので書き直してみた。
stirling' :: Integer -> Integer -> Integer
stirling' 0 0 = 1
stirling' _ 0 = 0
stirling' 0 _ = 0
stirling' n k = stirling' (n-1) (k-1) + k * (stirling' (n-1) k)
スターリング数
-- スターリング数
stirling :: Integer -> Integer -> Integer
stirling n k = truncate((fromIntegral s) / (fromIntegral k'))
where
s = sum [(-1)^i * (combination k i) * (k-i)^n | i <- [0..k] ]
k' = factorial kついでにベル数も。
-- ベル数
bell :: Integer -> Integer
bell n = sum [stirling n k | k <- [1..n]]一応答えはでるものの、式をコードに書き直しただけで洗練されてない。それ以上にこのコードをきちんと説明できるか!自信がない。(combinationとfactorialはテキトーに作ってね)
プログラム意味論と「Basic Category Theory for Computer Scientists」
プログラム意味論を飛ばし飛ばし読んでるんだけど、5章の「カテゴリ理論の基礎」が、以前読んで挫折しかけていた「Basic Category Theory for Computer Scientists」の 「1. Basic Constructions」とほぼ同じであることに気づいた。読みながらとっていたメモと比べてもなかなかイケてる。でも、やっぱり日本語で読んだほうが理解が深まるかなぁ
まぁ、結局のところ日本語だろうが英語だろうがわからないことがでで来れば行きつ戻りつしながら、あるいは別の本を探しなら読み進めていくしかないわけで、小説なんかと違ってなかなか「読了!」ってわけにはいかず、少しでも「理解の小島」が大きくなることを信じてこれからも未読の山と格闘していくのだ...
| プログラム意味論 (情報数学講座) | |
![]() |
横内 寛文
共立出版 1994-06 |
![]() |
Basic Category Theory for Computer Scientists (Foundations of Computing) Benjamin C. Pierce The MIT Press 1991-08-07 |
禅とオートバイ修理技術
二十年?ぶりくらいに読み返し。当時はほとんどよくわからなくて読み飛ばしていた箇所も多かった(というかほとんど)けど、少しはわかる箇所もでてきた。
シルビアの苛立ちは、コンピューターのプログラミングが「創造的なこと」だと思っている、ある友人に対して向けられていたのだ
はぁ、少なからずぼくの家庭にも当てはまるのだろうなぁ。まだ、再読始めたばかりだけど今度はどこまで吸収できるかな。
本当のシステムは、私たちの体系的思考そのものー合理性ーによって構築されたもである。だから工場を破壊してもそれを生み出した合理性が残っているかぎり、その合理性が再び別の工場を築き上げるだろう。
| 禅とオートバイ修理技術〈上〉 (ハヤカワ文庫NF) | |
![]() |
ロバート・M. パーシグ Robert M. Pirsig
早川書房 2008-02 |
反射閉包
例えば、
と、その関係
があるとき、Rの反射閉包は
である。つまり、Rそのものが含まれている必要があるんだね。
ミルカさんに言われるまでもなく例示が理解を助けるな。あたりまえだけど、内容を理解していないと日本語にはうまく訳せない。
問題なのは何故これがmost important closures
のひとつなのか?なんだけど...
Project Euler Problem73
Poject Euler Problem 73解いた。といっていいのか?なんの工夫もなく40秒近くもかかるこのコードで...
p73 :: Int -> [(Int,Int)]
p73 v = [ (n,d) | n <- [1..v], d <- [1..v], n < d && gcd n d == 1 && p n d && q n d]
where
p x y = ((fromIntegral x) / (fromIntegral y)) > (1 / 3)
q x y = ((fromIntegral x) / (fromIntegral y)) < 0.5
main = do
putStrLn $ show.length $ p73 12000n <- [1..v], d <- [1..v]の時点でダメな気がする。Problem71~73は一気に解けていい問題のはずだけど案の定71,72は終わりません。
久しぶりProject Eulerなど
久しぶりにProject Eulerの問題74をやった。なんとか解答できたのだけど、最初のバージョンはPreludeにある某関数の存在を知らず自前でコリコリ書いて15分近くも時間がかかったんで正答とは言えそうもない。
fact :: Int -> Int
fact 0 = 1
fact n = n * fact (pred n)
chk :: Int -> Int
chk n = sum $ map (fact.digitToInt) $ show n
cyc :: [Int] -> [Int]
cyc xs = if elem n' xs then xs else cyc (n':xs)
where
n' = chk (head xs)
main = do
let c = length $ filter (\x -> (length x) == 60) $ map (\x -> cyc [x]) [1..999999]
putStrLn $ show c最終的には(ウチのマシンで)40秒くらいなんだけど、Forumを見てみると10秒以内ってヒトも結構いるみたいで、正答を出すだけで精一杯じゃホント修行が足りないねぇ。
独自データ型を畳込む
独自に作ったデータ型を畳込みたいなんてのは良くあることで、とりあえず書いてはみたものの自身がない。例えば、
data Exam = Exam { name :: String, english :: Int, mathemetics :: Int }
| SumExam { english :: Int, mathemetics :: Int }
deriving (Show)というデータ型があったときこの試験結果を畳込みたい。とりあえず、モノイドのインスタンスにしなければいけないというのはわかったので
instance Monoid Exam where
mempty = SumExam { english=0, mathemetics=0 }
a `mappend` b = SumExam { english=(english a)+(english b)
, mathemetics=(mathemetics a)+(mathemetics b)
}として
sumExam :: [Exam] -> Exam
sumExam = foldr mappend mempty
で、望みの結果は得られることは確認した。でも何かしスッキリしない。Foldableクラスのインスタンスにしなくても良いのだろうか? 後、できれば
foldr (+) mempty [exams]のように書けた方がわかりやすいだろうなぁ
関数脳はまだ遠い。
SharpZipLib・DotNetZipを使ったアーカイブの解凍でプログレスバーを表示する
SharpZipLibを使ったアーカイブの解凍でプログレスバーを表示します。なにしろ、ターゲットユーザは3秒以上の処理では状況表示しないと待っていてくれませんから... :-( プログレスバーを表示するのは以前書いたエントリC#でサブスレッドからプログレスバーにアクセスする(デリゲート・ラムダ式は快適!)とやり方は一緒です。
解凍の手順は簡単です。アーカイブのタイプに合わせたストリームクラスを作成してReadするだけ。gzipの場合は2回同じ手続きが必要なので注意します。
if (source.EndsWith(".tgz") == true || source.EndsWith(".tar.gz") == true)
{
GZipInputStream tgz =
new GZipInputStream(new FileStream(source, FileMode.Open,FileAccess.Read);
TarInputStream tar = new TarInputStream(tgz);
:
}ストリームを作成したら、アーカイブ内のエントリ毎に読みながらプログレスバーを更新していくだけ。
delegateProgressBar increment_bar = new delegateProgressBar((int v) =>
{ Cursor.Current = Cursors.WaitCursor; progressBar1.Value = v; });
ICSharpCode.SharpZipLib.Tar.TarEntry entry = tar.GetNextEntry();
while (entry != null)
{
Invoke(new delegateProgressBar((Int32 v) =>
{ progressBar1.Value = 0; progressBar1.Minimum = 0; progressBar1.Maximum = v; }),
new Object[] { (Int32.MaxValue < entry.Size) ?
(Int32)(entry.Size / 65536) : (Int32)entry.Size });
using (FileStream dest = new FileStream(
desitination + "¥¥" + entry.Name, FileMode.Create, FileAccess.Write))
{
Int32 count = 0;
Int32 write_total = 0;
byte[] buffer = new byte[32768];
using (BinaryWriter br = new BinaryWriter(dest))
{
while ((count = tar.Read(buffer, 0, 32768)) > 0)
{
br.Write(buffer, 0, count);
write_total += count;
if (Int32.MaxValue < entry.Size)
{
Object[] inc_arg = { (Int32)write_total / 65536 };
Invoke(increment_bar, inc_arg);
}
else
{
Object[] inc_arg = { write_total };
Invoke(increment_bar, inc_arg);
}
}
br.Flush();
br.Close();
}
dest.Close();
}
}プログレスバーのMaximumはInt32なので、巨大なファイルだとパンクするので適当に切り捨てた単位で回さないといけないのが面倒です。まー、プログレスバーなんて出さなくてもヘーキというユーザがターゲットの場合
using (ICSharpCode.SharpZipLib.Tar.TarArchive ta = TarArchive.CreateInputTarArchive(
new TarInputStream(new FileStream(source, FileMode.Open, FileAccess.Read))))
{
ta.ProgressMessageEvent +=
new ProgressMessageHandler(tar_ProgressMessageEvent);
ta.ExtractContents(desitination);
}で一発解凍できます。ProgressMessageHandlerを指定しておけばエントリ毎にイベントが上がってきますので取り出し中のエントリ名を表示したりとかくらいはできそうです。(エントリ単位で解凍するってのはやり方がわかりませんでした。)
ところで、このSharpZipLibですが*nix系システムで作成したzipをうまく解凍できないという問題があります。回避方法がハッキリしなかったのでzipに関してはIconic.Zipを使うようにしました。
using (Ionic.Zip.ZipFile zip = Ionic.Zip.ZipFile.Read(source))
{
zip.ExtractProgress +=
new EventHandler(extract_zip);
foreach (Ionic.Zip.ZipEntry entry in zip)
{
Invoke(new delegateUpdateLabel((string s) =>{ this.label1.Text = s; }),
new Object[] { entry.FileName + " extracting ..." });
entry.Extract(desitination, ExtractExistingFileAction.OverwriteSilently);
}
} こちらは逆にエントリ毎に解凍したバイト数がイベントで上がってきますのでそこでプログレスバーを更新してやればOKです。
500M近いアーカイブを毎日DLするので進捗具合を表示してやるのが必須の要件なんですが、それにしてもみんなセッカチですよ。これで少しは気も収まるかな?
ソースはhttps://github.com/hippos/extract_sampleにあります。
収束の判定法
で与えられる数列の収束性を調べる。
これを、として、
との大小を比べるやり方。二項定理により展開する式の途中が省略されていたので迷った時の補完メモ。
から、いきなり
に変形されている。迷ったのはここです。いきなり、ここまで展開されるとついていけない...
と、
まで、補ってようやく理解できた(気がする)。ってか、読めばなんとか理解できるものの、自力で
かつ、
まで、導くのムリ。
テストでも使ってはいけないアカウント名を抽出
いろんな実験用にServersman@vpsを借りてますが、logwatchから毎日毎日嫌になるくらい不正なアクセスがありますね−。特に、この数週間Dovecotへの不正アクセスが急増してます。まぁ、誰もユーザ作ってないんでログインできないんですけど、もうサービス止めておこうかなと思いますね。で、メールサーバ構築時に止めといた方がいいアカウント名のリストです。ログから抜き出して、sort | uniq -c | sort -rの結果です。






最近のコメント
1年 15 weeks ago
1年 50 weeks ago
2 years 14 weeks ago
2 years 14 weeks ago
2 years 32 weeks ago
2 years 32 weeks ago
2 years 32 weeks ago
2 years 43 weeks ago
2 years 44 weeks ago
3 years 24 weeks ago