Linked


Linked: The New Science Of Networks
 
네트워크 이론의 소개서처럼 보이지만, 사실 이 책은 Albert-Laszlo Barabasi와 그의 동료들이 고안된 용어인 Scale-free network에 대한 소개서이다. Barabasi는 Scale-free network를 random connectivity network와 대조시켜서 설명하고 있는데, 가장 큰 차이는 바로 scale-free network의 경우, connectivity의 distribution이 매우 uneven하다는 것이다. 이러한 성질로부터 scale-free network만의 독특한 성질이 파생된다.
 Barabasi가 scale-free network의 개념을 도입하게 된 계기이자, 첫번째 실례는 바로 인터넷이다. 인터넷의 각 페이지 또는 서버를 node로 표현하고, 연결상태를 edge로 나타낼 경우, 대부분의 노드는 leaf이고 소수만이 많은 edge를 가질 것이라는 것은 왠만한 computer scientist/engineer라면 모두 직관할 수 있는 사실일 것이다. scale-free network는 인터넷에서의 많은 연결을 가진 node와 같이 ‘very connected hub’을 가지고 있다는 중요한 특성을 가지고 있다.
 이러한 소수의 ‘very connected hub’의 존재에 의해서 ‘small world’ network(어떤 두 node 사이의 링크 수는 매우 작다)라든가 random failure에 대한 안전성, very connected hub의 failure에 대한 취약성 같은 특성들이 다시 파생된다.
 Scale-free network의 생성 조건에 대해서 Barabasi는 단지 두가지 rule만을 제시한다.
a) growth
a) preferential attachment (새롭게 추가되는 node는 많은 link를 가진 node에 연결되는 것을 선호한다.)
 
 책의 표지 같은데에서는 매우 거창하게 소개하고 있지만, random-connectivity로 제약된 시각으로부터 벗어나 scale-free라는 개념을 발견해낸 것 외에는 그다지 새로운 것은 없어 보인다. Complex system이나 Chaos theory쪽 연구의 한 성과 정도로 보이는 정도랄까. 좀 더 사실대로 말하면, 나로서는 이 분야에 대해서 아는게 별로 없어서 중요성도 제대로 평가하기가 힘들다는 것을 인정해야할 것이다.
 
 책의 전반은 위와 같은 scale-free network의 소개가 이어지고, 후반은 scale-free network에 대한 실례들을 계속 보여주는데, 지적인 즐거움이 탁월한 전반과는 달리 후반은 시간낭비라고 생각될 정도로 매우 지루했다. scale-free network의 stereo type을 보여주는 것 보다는 어떤 변수가 작용해서 scale-free network의 variant가 이런이런게 있다 같은 식으로 진행했으면 어떨까 하는 생각이 들었다. 따라서, 반 정도를 읽고 난 후 인터넷 서핑을 해보는 것을 추천!
 
 이 책을 읽고나서 scale-free network 자체보다는 complex system이나 choas theory 쪽을 좀 더 공부해보고 싶은 마음이 생겼다.
 
Scale-Free Networks
 
Wikipedia
http://en.wikipedia.org/wiki/Scale-free_network
 
Emergence of Scaling in Random Networks from Science
http://www.nd.edu/~networks/Papers/science.pdf
(Barbarasi가 Scale-Free Networks에 대해 처음으로 공식적으로 발표한 내용으로 보임.)
 
Scale-Free Networks from Computerworld
http://www.computerworld.com/networkingtopics/networking/story/0,10801,75539,00.html
 
Scale-Free Networks from Scientific American (May 2003)
http://www.nd.edu/~networks/PDF/Scale-Free%20Sci%20Amer%20May03.pdf
 
Study of Self-Organized Networks at University of Notre Dame
http://www.nd.edu/~networks/index.html
 
Releated Field(?)
Linked를 읽으면서 떠오르던 keyword들.
 
Wikipedia: Complex System
http://en.wikipedia.org/wiki/Complex_system
 
Wikipedia: Dynamic Systems
http://en.wikipedia.org/wiki/Dynamical_systems
 
Wikipedia: Choas Theory
http://en.wikipedia.org/wiki/Chaos_theory

Linked 더 읽기"

山崎まさよし – 僕はここにいる

僕はここにいるジャケ写 僕はここにいる
1998.11.11発売
PODH-1445
12cm MAXI-SINGLE
POCH-1959

僕はここにいる
mud skiffle track V
お家へ帰ろう
僕はここにいる
  (Backingtrack)

 

ため息だけが静寂に消えていった帰り道
한숨만이 고요하게 사라져 간 돌아가는 길
遠い空 揺れてる街並み

먼 하늘 흔들리고 있는 거리풍경
すべてに君の優しい微笑みが離れない

모두에게 너의 상냥한 미소가 떨어지지 않는
手を伸ばしても届かない場所にいる

손을 뻗어도 닿지 않는 장소에 있는

もっと君のこと知りたいよ
좀 더 너알고 싶어
悲しみもささやきも全部見てみたい

슬픔도 속삭임도 전부 보고 싶은
苦しいよ 今度はいつ逢える

괴로워 이번은 언제 만날 수 있는

遅すぎた出逢い 胸にかみしめている痛いほど
너무 늦은 만나 가슴에 악물고 있는 아플 정도(수록)
気づいたら夜は終わりはじめてる

눈치채면(자) 밤에는 끝나기 시작하고 있는

うまく君の名を呼べないよ
잘 너의 이름을 부를 수 없어
せつなくてむなしくてつぶされそうさ

안타까워 허무해서 부수어질 것 같음
わかるかい?

알까?
僕はここにいる

나는 여기에 있는

報われない つかの間の夢ならば
보답받지 못하는 잠시동안의 꿈이라면
せめて偶然の時だけでも

적어도 우연한 시에만
儚いうたかたの 恋ならば

덧없는 노래 가타노연이라면
せめて今君の声だけでも

적어도 지금 너의 소리만으로도

救われない 痛みだけの気持ちでいい
구해지지 않은 아픔만의 기분으로 좋은
傷ついてもそれでかまわない

다쳐도 그래서 상관없는
できるなら今すぐ抱きしめたい

할 수 있다면 금방 꼭 껴안고 싶은
二人だけの約束をかわしたい

두 명만의 약속을 주고 받고 싶은

報われない つかの間の夢ならば
보답받지 못하는 잠시동안의 꿈이라면
せめて偶然の時だけでも

적어도 우연한 시에만
儚いうたかたの 恋ならば

덧없는 노래 가타노연이라면
せめて今君の声だけでも
적어도 지금 너의 소리만으로도

 
※ 번역이 이상하지만 참아주세요^^ 수정해주시면 감사하죠~
※ 일본어 파일명은 제대로 안올라가나봐요.
 
 

山崎まさよし – 僕はここにいる 더 읽기"

Let Java Go

얼마전에 Eric S. Raymond가 Sun에게 쓴 open letter. 현재의 Sun이 “The open-source model is our friend”라는 정책을 표명하고 있지만, 부족하다고 생각하며, 특히 Java code에 대해서는 control 하려는 경향이 강해서 Java는 open-source community에의 acceptance를 잃고 다른 language에 자리를 내주고 있다는 얘기를 하고 있다. 마지막으로, Java 개발을 open source community에 내주자는 주장을 하고 있다. 이에 대해 Simon Phipps는 답장에서 Java는 지금도 충분히 open source의 요건을 만족하고 있다고 하면서, 사실상 ESR의 요청을 거절했다.
 
Open letter to Sun: Let Java Go
http://www.catb.org/~esr/writings/let-java-go.html
 
Sun’s Simon Phipps Answers ESR’s Call to Open Source Java: Doesn’t Hold Water
http://news.osdir.com/article451.html

Let Java Go 더 읽기"

Hypertransport 2.0

지난 9일, PCI-Express에 mapping되는 AMD 진영의 대체 PCI bus인 Hypertransport 2.0 spec이 나왔다. speed capacity가 2.0-2.8 Giga Transfers/second이고 maximum aggregate bandwidth가 22.4 Gb/s란다.
 
아래의 Inside PCI Express 기사에 의하면, Hypertransport가 실용화되고 있는 시점에서 PCI Express가 어떻게 Hypertransport를 대체할 것인지에 대해서 잘 모르겠다고 평가하고 있다. 그리고 PCI Express가 process-to-process 또는 processor-to-north bridge간의 connection으로 활용될 경우, PCI Express가 채용하고 있는 serial interconnects (rather than pararrel interconnects in Hypertransport)는 latency가 높아질 수 있다고 한다. 그 외에도 MP design에 있어서의 cache coherent protocol의 지원 미비에 대해서도 언급하고 있다.
 
소비자인 나로서는 Hypertransport가 PCI Express와 용호상박이라는 것이 즐거울 수 밖에.
 
HyperTransport Consortium
http://www.hypertransport.org/
 
HyperTransport Consortium Announces High-speed Release 2.0 Specification
http://www.hypertransport.org/pr_020904.htm
 
HyperTransport Technology Overview
http://www.hypertransport.org/docs/ht-overview.pdf
 
PCI Express
http://www.pcisig.com/specifications/pciexpress
 
Intel Developer Network for PCI Express Architeture
http://www.intel.com/technology/pciexpress/devnet/
 
What is PCI Express?
http://www.intel.com/technology/pciexpress/devnet/docs/WhatisPCIExpress.pdf
 
PCI Express Architecture Initiative Overview
http://www.intel.com/technology/pciexpress/devnet/docs/PCI-Express-Overview-Oct2003.pdf
 
High-Performance Buses and Interconnects
http://www.extremetech.com/article2/0,3973,27302,00.asp
 
Inside PCI Express
http://www.extremetech.com/article2/0,3973,522303,00.asp
 

Hypertransport 2.0 더 읽기"

We Are Morons: a quick look at the Win2k source

We Are Morons: a quick look at the Win2k source
http://www.kuro5hin.org/story/2004/2/15/71552/7795
 
항상 내가 하던 짓이라 공감도 가고, 재미있기도 하고,
또한 감동적이기도 하다.
 
—>8—
In the struggle to meet deadlines, I think pretty much all programmers have put in comments they might later regret, including swearwords and acerbic comments about other code or requirements. Also, any conscientious coder will put in prominent comments warning others about the trickier parts of the code.
—>8—
 
—>8—
From the comments, it also appears that most of the uglier hacks are due to compatibility issues: either backward-compatibility, hardware compatibility or issues caused by particular software. Microsoft’s vast compatibility strengths have clearly come at a cost, both in developer-sweat and the elegance (and hence stability and maintainability) of the code.
—>8—

We Are Morons: a quick look at the Win2k source 더 읽기"

Secure Your Web Services

 .net magazine august 2003에서 발췌, 요약.
 
Secure Your Web Services
 
Using currently available technology
 
1. SSL/TLS
 
Secure Socket Layer/Transport Layer Security (SSL/TLS)나 Windows Integrated Security를 사용하는 방법이다. TLS란 SSL의 대체물로 SSL 3.1로 불리기도 한다. TLS와 SSL은 호환성이 없으므로, 새로운 프로젝트에는 TLS를 사용하는 것이 좋을 것이다.
 
Web services message는 Web services provider에게 secure SSL/TLS channel을 통해 전달된다. 이 secure channel은 interaction’s outset에서 handshake에 의해 형성된다. 각각의 message들은 encrypt되어있고 digitally sign되어있고, 따라서 message의 confidentiality와 integrity를 보장한다.  initial handshake 중에는 single, dual-sided authentication이 일어난다. Web service provider는 항상 CA로부터 발급받은 certificate를 가지고 있다.
 
SSL/TLS solution은 매우 secure하지만, 매우 resource-intensive하기 때문에 scale하지 않다.
 
2. Windows Authentication
 
authentication만을 지원. (not encryption) provider와 client 사이의 정보는 clear text.
 
3. SOAP header
 
SOAP header는 fully extendable하기 때문에 authentication을 위한 credential을 포함하는 header를 만들 수 있다. 이러한 solution은 client와 service 양측에 대한 control이 가능할 때 가장 적절한 solution이다.
 
적절한 de facto or official standard 없이는 여러 partner간에 secure infrastructure를 일반화하고 유지하는 것은 불가능하다. 위의 방법들은 Web services를 위해 설계되지 않았기 때문에 한정된 환경 (constrained environment)에서 잘 동작하는 단기적인 해결책이다.
 
WS-Security specification from OASIS
 
– enhancements to the SOAP messaging protocol: authentication & security token
– XML digital signatures: integrity
– XML encryption: confidentiality
 
Web services architeture usage scenarios에서 W3C는 specification들에 관련된 Web services의 requirement를 정리하고 있다.
 그러한 specifications들 가운데 기본적인 개념 하나는 미래의 Web services message들은 claim을 가질 것이란 것이다. claim이란 name, key, 또는 permission 그리고 authorization이다. Web services의 security policy는 필요한 claim들의 집합을 명시할 수 있다. Web service는 필요로 하는 claim을 가지지 않은 message를 무시하거나 거부할 수 있다. Web service client는 security token을 message에 포함함으로써 claim의 증명을 제시한다.
 
Web services message는 parsing, authentication, authorization에 필요한 모든 정보들을 가지고 있을 것이다. messages가 destination에 도달할 때까지 여러 intermediaries를 거치게 되므로, 이 원칙은 매우 중요하다.

 
이러한 시나리오에서 message의 recipient가 모든 인증된 claim을 가지고 message의 originator와 항상 직접 interact하는 것은 불가능하다. message가 필요한 claim 없이 destination에 도달할 경우, requestor나 requestor에 해당하는 intermediaries는 다른 Web services로부터 필요한 claim과 security token을 얻어올 수 있다.
 

 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
Prepare for Web Services’ Future
 
Web services는 서로 다른 vendor들의 system을 연동하는 glue이다. 따라서 capable least common denominator가 시급하게 필요하다. 소프트웨어, 하드웨어 산업의 모든 key player들이 노력을 쏟고 있는 현실에서, 앞으로 Web services의 확산은 불가피한 것 같다.
 
Resources
 
Microsoft XML Web Services Developer Center Home:
http://msdn.microsoft.com/webservices/
 
OASIS
http://www.oasis-open.org
 
OASIS Web Services Security TC
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
 
W3C Web Services Architecture Usage Scenarios
http://www.w3.org/tr/2002/wd-ws-arch-scenarios-20020730/
 
developerWorks Web services
http://www-136.ibm.com/developerworks/webservices

Secure Your Web Services 더 읽기"

2004년 2월 3, 4주 개봉 예정 기대작들



 
 
 
 
 
 
 
 
 
 
사랑도 통역이 되나요? (Lost In Translation)
제목 맘에 듬. (물론 영제)
 
8명의 여인들 (8 Femmes)
프랑소와 오종. 밀실 살인 사건. 뤼디빈 사니에르.
 
스쿨 오브 락 (The School Of Rock)
포스터는 물론이고 칠판 씬도 봐버렸다.
 
타임라인 (Timeline)
마이클 크라이튼 원작의 영화화. SF팬으로서 의무적으로..
마이클 크라이튼을 SF 작가로 부르기도 뭐하거니와, 영화도 그다지 기대는 하지 않음.
 

2004년 2월 3, 4주 개봉 예정 기대작들 더 읽기"

볼 영화들


 
 
 
 
 
 
 
 
 
 
페이첵
악평에도 불구하고 SF 팬으로서 의무적으로..
 
피터팬
피터팬의 또다른 해석. 스위밍풀의 뤼디빈 사니에르 (Ludivine Sagnier)를 보는 것도 또다른 재미.
 
자토이치
기타노 다케시. 맹인검객이라는 매력적인 캐릭터.
 
사랑할 때 버려야 할 아까운 것들
빠방한 출연진이라니. 오랜만의 로맨틱 코미디. ‘What women want’의 Nancy Meyers.
 

볼 영화들 더 읽기"