Linux.comがコミュニティポータルにリニューアルしたそうです。
---From @IT---
　Linux Foundationは米国時間の5月13日、「Linux.com」サイトをリニューアルした。

　Linux Foundationは2009年3月に、SourceForgeからLinux.comのドメインを取得していた。ニュース、コミュニティ、Linux ディストリビューション、教育、ディレクトリという5つのカテゴリを用意し、Linuxのユーザーと開発者を結び付けることを目的としたポータルサイトとして運営していく。Linux関連のリソースを提供するほか、利用者がブログやグループを立ち上げ、活動を展開することができる。スポンサーは、 Intel、NetApp、Novell、Red Hatの各社。

　Linux.com利用者の活動は、「Guru」ポイントで評価される。コミュニティに参加し、ディスカッションに参加することによりポイントがたまり、上位50名のGuruには、Linux Foundationの年次報告への記載、上位5名にはさらにLF Collaboration Summitへの招待、Linux.comの年次計画策定会議への参加といった特典が授与される。最上位のLinux Guruには、「Ultimate Linux Guru」（究極のLinux Guru）の称号が許され、Linus TorvaldsがサインしたLinuxノートPCが与えられるという。
---From @IT---

　Oracleによる買収に反対するSun Microsystemsの株主らが、買収阻止に向けて3件の集団訴訟を起こした。

SUNの4半期報告書からわかったようです。

実質56億ドルの価値のところ74億ドルで買ったのが
どうも癇に障ったようです。

IBMのときよりちょっと高い値段ぐらいじゃ済まさないってことですかね(^^;

あのまま行けばSUNの将来はなかったので
損はしたものの無くなるよりはましだったとあきらめるほかないように思いますが・・・

業界では危ないのは数年前から囁かれていましたからねえ。

今後は自社でサーバを持つ時代ではなく
Saas、Paas時代ですから！

鯖屋もクラウドを提供する企業特化。
保守運用もクラウドを提供する企業特化で行かないと！

The Linux Foundation Japanが5/7にデータベース化されたオープンソースソフトの2008年度使用実績調査の結果を発表したそうです。主要なOSSのツール256個についてまとめたものです。

その結果、ネットワークの「BIND」「OpenSSH」「OpenSSL」「OpenLDAP」など、開発の「PHP」「Eclipse」「Subversion」、データベースの「MySQL」「PostgreSQL」などの基盤系ソフトが、ほぼすべてで活用されていることが分かったとのことです。

詳細はこちらから
http://sourceforge.jp/magazine/09/05/08/0917229

　レスキューモードで起動したいシーンに直面するまで
イマイチ実感が無いかもしれませんが、机上での理論として
一応シングルユーザモードとレスキューモードの違いを理解してみましょう！

今回はレスキューモードについて少し見てみます。
　
　・レスキューモードで何ができるか？

まずレスキューモードで起動する際はインストールした際のDVD-ROMかCD-ROM
を使ってブートします。

　そうすることでメディアに入っているカーネルからブートでき、コマンドや
　ファイルはブートメディアのものを使用します。

つまり

・システムがハードディスクからブートできなくなった場合
・システムのハードディスクから起動したくない場合

などが用途の目的と考えられます。

　具体的にDVD-ROMやCD-ROMからブートした後は、ダイアログにしたがって
もともと起動していたハードディスクをマウントすることができますので
実際にはシステムをブートさせないが、通常動作していたハードディスクの
中身を操作できます。

【レスキューモードでの起動方法】
1.DVD-ROM or CD-ROMを挿入(1枚目)
2.挿入したメディアから起動
3.いつものインストール時のbootプロンプトに
boot:linux rescue
4.ダイアログに従って入力していく

最近まことしやかにささやかれている
WebOSとは何かご存知でしょうか?

このサイトにたどり着く皆さんには
当然でむしろ開発もしているよ!

って聞こえてきそうですが

引用：

http://www.startforce.jp/

これはかなり便利でしょう！
ネットに接続してさえ入れば
どこからでも自分のデスクトップが操作できるのですから。

まだまだ発展途上の時期ですが期待したいところです!

ITmedeliaTankによると
日経ベストPC+デジタルが休刊となるようです。

引用：

確かに最近はこの手の情報はwebで情報入手するほうが早いかもしれません。
ただ、個人的には電車の中の隙間時間や待ち合わせまでの時間など
まとまった情報を一気に吸収したいときにはすごくよかったんですけどねえ。

残念です。

　lsコマンドでファイル(ディレクトリ)一覧を出せますよね。(そんなこと知ってるっつうの!)
ファイル名だけを１ファイル名１行に表示したいことって時々ありませんか?

例).
# ls
amanda chargen-udp dbskkd-cdb finger kshell rlogin telnet vmware-authd
amandaidx cups-lpd echo gssftp ktalk rsh tftp
amidxtape daytime echo-udp klogin ntalk rsync time
chargen daytime-udp eklogin krb5-telnet rexec talk time-udp

↓　こんな感じに

amanda
amandaidx
amidxtape
chargen
chargen-udp
cups-lpd

どうやったらこうなるでしょうか?

A).ls --perfile
B).ls | xargs -n 1
C).ls -l | awk '{print $1}'
D).find ./

正解：B

A:--perfileオプションは無い
C:$1が$9だと正解
D:findでは./がファイル名の前に付いてしまう

実はxargsコマンドを問題のように使うことでlsの結果を
1ファイル名1行で表示することができます。

意外と便利なことがあるかもしれませんね。
ファイルの個数数えるときも

# ls | xargs -n 1|wc -l

なんかで数えられますしね。

きっと他にも使い道があるはずです。頭の片隅でも残して置いてください。

■問題■前述の「例」に出したファイル一覧はどのディレクトリでしょうか?
A)./etc
B)./etc/rc5.d
C)./etc/xinet.d
D)./usr/sbin

答え：「おわりに」の中で。

　前回はLABELやUUID名からそのデバイスを探すコマンドはfindfsと
紹介しましたが、今回はその逆です。

　/dev/hda1や/dev/sda1に割り当てられているLABEL名やUUID名を
特定するコマンドです。

　・LABEL名を探すときは「e2label」コマンド
　・LABEL名やUUID名を探すときは「blkid」コマンド
　・ファイルシステム情報もあわせて確認したいときは「tune2fs」コマンド
　
　※詳しい出力順(上：簡単　下：詳細)


例).
# e2label /dev/cciss/c0d0p1
/boot

# blkid /dev/cciss/c0d0p1
/dev/cciss/c0d0p1: LABEL="/boot" UUID="4077ed20-a20c-440e-835a-c6ee23831895" SEC_TYPE="ext3" TYPE="ext2"

# tune2fs -l /dev/cciss/c0d0p1
Filesystem volume name: /boot
Last mounted on: <not available>
Filesystem UUID: 4077ed20-a20c-440e-835a-c6ee23831895
Filesystem magic number: 0xEF53
　　<以下略>


こうやればデバイスに割り当てられているラベル名やUUID名が判断できますよね。

　よく/etc/fstabファイルをみたり/etc/grub.confを見ると

　LABEL=/
　LABEL=/boot
　UUID=a0dead04-2770-4c35-9300-bb936294fc2c
　UUID=61158c27-2804-49f6-9944-11b15de335b7

という表現がされています。solarisユーザなんかではなじみが無いと思いので
実際のデバイス名が分からないことに違和感を覚えるかもしれません。

このラベルに指定されているLABELやUUIDのデバイス名が何か知りたいときは
どうしていますか？

tune2fsコマンドで全てのデバイスを調べていますか?

そんなわけ無いって聞こえてきそうですが、以外にそんな管理者さんもいるかも
しれません。ラベル名からデバイス名を調べたいときは

　　　　findfsコマンドを使いましょう！

例).
# findfs LABEL=/
/dev/cciss/c0d0p3

# findfs UUID=a0dead04-2770-4c35-9300-bb936294fc2c
/dev/cciss/c0d0p3

こうやれば/や上記のUUID名からデバイスが判断できますよね。

　結果を先に「URG」「PSH」はむしろ現在は使いません。
といった方がいいでしょう(≧∇≦)/

　TCPについてこれまでオープンやクローズを説明しました。
SYN,ACK,FINフラグについては使われ方が分かったと思いますが
他にも「RST」「URG」「PSH」さらにおまけで「ECN」フラグなんて
のもTCPには存在します。ECNはTCPの拡張のフラグで、フロー制御の
時に使うので今回は置いて、残りの「RST」「URG」「PSH」は覚えるという
ほどのものでも無いので一気に説明します。

■RSTフラグ
　接続要求を拒否します(listenして無いポートに接続きたりしたとき)
　コネクション確立中のものを切断します
　受け取るとすぐクローズします

　関係するカーネルパラメータ：「tcp_rfc1337」

　デフォルト1にセットされています。0に変更するとRFC違反になるので
　そもそも設定変更はしてはいけません。

■URGフラグ
　帯域外のデータを転送するためにあるはずですが
　実際は帯域内になってるので真実ではない。
　アプリケーションに緊急にデータを渡すためのフラグ。
　受け取ったアプリケーションが緊急モードになる。

　関係するカーネルパラメータ：「tcp_stdurg」

　デフォルト無効になっています。RFC793に厳密に
　従うためには有効にしますが、緊急ポインターは
　BSD互換のものが使われることが多いので、多くは
　意味を持たないので現在では無効がデフォルト。
　BSDとRFC793ではフラグの位置が違うような感じ

■PSHフラグ
　カーネルでバッファリングせずに、プロセスにすぐに
　渡すようにするためのフラグですが、現在はカーネル
　はすぐにプロセスに渡すの実質使用していません。

　特にカーネルパラメータで関係が深いものがありません。

■ECNフラグ
　RFC2481 Explicit Congestion Notification (ECN)のような
　輻輳制御の手法です。他にも「Tahoe」「Reno」　「NewReno」
　「TCP New-Reno」「BIC」「Westwood+」「vegas」など
　いろいろあります。デフォルトではBIC TCPが有効(RHEL4 2.6.9)になっています。

総まとめ　RFC一覧

---TCPそのものやTCPに関わるRFC総まとめ---
RFC793　 Transmission Control Protocol
RFC813　 Window and Acknowledgement Strategy in TCP

RFC1144　compressing tcp ip headers for low
RFC1323　TCP Extensions for High Performance
RFC1337　TIME-WAIT Assassination Hazards in TCP

RFC2001　Fast Retransmit, and Fast Recovery Algorithms
RFC2018　TCP Selective Acknowledgment Options
RFC2147　TCP and UDP over IPv6 Jumbograms
RFC2415(Informational) Simulation Studies of Increased Initial TCP Window Size
RFC2481(Experimental)　A Proposal to add Explicit Congestion Notification (ECN) to IP
RFC2581　TCP Congestion Control
RFC2582　The NewReno Modification to TCP's Fast Recovery Algorithm

RFC2760　Ongoing TCP Research Related to Satellites
RFC2861(Experimental)　TCP Congestion Window Validation
RFC2883　An Extension to the Selective Acknowledgement (SACK) Option for TCP
RFC2988　Computing TCP's Retransmission Timer
RFC2923(Informational)　TCP Problems with Path MTU Discovery

RFC3042　Enhancing TCP's Loss Recovery Using Limited Transmit
RFC3390 Increasing TCP's Initial Window
RFC3448　TCP Friendly Rate Control (TFRC)
RFC3522(Experimental)　The Eifel Detection Algorithm for TCP
RFC3649(Experimental)　HighSpeed TCP for Large Congestion Windows
RFC3742(Experimental)　Limited Slow-Start for TCP with Large Congestion Windows
RFC3782 The NewReno Modification to TCP's Fast Recovery Algorithm
RFC3821　Fibre Channel Over TCP/IP (FCIP)
---こんなに一杯あります。困ったときは参照しましょ---