입론
환수는 신중에 신중을 기해야 한다.
· 주권
○ 전시작전통제권과 전시작전지휘권은 다르다.
§ 연합사는 한미 공히 50대 50으로 편성되어 있다.
§ 감정적으로 다가갈 문제가 아니다.
· 자주국방
○ 한국군의 전쟁 지속 능력엔 한계가 있다.
§ 전쟁이 일어나면 1개월이 걸릴지 혹은 3∼5년이 걸릴지 아무도 알 수 없다. 현재 한국군이 보유한 탄약, 유류, 수리부속품 등은 평균 6개월 정도의 전쟁 지속 능력을 갖고 있다. 특히 전투기, 미사일, 신형 무기는 미군의 지원 없이는 지속적인 조달이 불가능하다. 이러한 전쟁 지속을 위한 군수조달계획 또한 한미연합사령관의 중요한 임무 중 하나다.
최윤경: 전작권 정의, 역사적유래
전작권환수와 전쟁억제력상실과는 무관-전작권환수는 군사자산유지 하면서 지휘체계만을 바꾸는 것
전작권문제와 핵방위조약과는 별개의 문제
////////////////////////////////////
전작권은 무엇이다.
전작권 양도의 시대적 배경. -> 현재 사정에 맞지 않다.
전작권 환수의 위험에 대한 견해들이 있다.
But 위험하지 않다. 한미 상호 조약은 유지된다. 한미 상호 방위 조약은 유지
북한의 열악의 경제 상황등을 고려했을 때 남침은 불가능하다.
핵문제는 전작권 환수와는 별개의 문제다.
경제적 부담이 있을거라는 얘기
2020 에 책정되어 있는 예산만으로도 충분히 가능
추가적인 경제 부담은 없을 것이다.
미국과 협의 과정에 있다. 한미 상호 방위 조약의 유지, 공동 경비 태세가 유지될 것이다.
지금 환수하는 것이 맞다.
전시작전 통제권과 전시작전 지휘권은 다르다. 군사작전만이 아닌 다른 것들을 포괄하는 것이 지휘권이다.
(예를 들어주면 좋겠다)
통제권을 갖고 있더라도 한국이 충분한 힘을 발휘할 수 있다. (?) (근거가 잘 안들어옴)
1994년도 예시. (전쟁이 날 뻔했습니다. 라고 하는 건 어떨까) 전시작전 통제권의 절반의 힘은 우리 것이므로 미국의 북침을 막을 수 있었다.
미국이 전시작전통제권을 환수해주면, 미군이 우리나라에서 나가게 된다.
경제적인 이득
미국이 제공하던 국방의 일부를 자력으로 해결해야 하므로 추가적인 비용이 발생한다. 정부의 예산은 충분하지 않을것이다. 우리나라는 부유하지 않다.
전략정보의 100% 를 주한미군에서 받고 있다. ~~ (이 부분 좋다!)
(현대는 정보전이라는 것 다들 알고 계실겁니다. 추가하면 좋을 것 같다)
첨단정보 기기를 도입하는데 10년이나 걸린다는 장관의 말을 인용. 충분한 시간이 필요하다. 돈만이 아니라.
감정적인 이유로 전작권을 환수하는 것은 타당하지 않다.
전시작전 통제권과 전시작전 지휘권은 다르다. 군사작전만이 아닌 다른 것들을 포괄하는 것이 지휘권이다.
(예를 들어주면 좋겠다)
통제권을 갖고 있더라도 한국이 충분한 힘을 발휘할 수 있다. (?) (근거가 잘 안들어옴)
1994년도 예시. (전쟁이 날 뻔했습니다. 라고 하는 건 어떨까) 전시작전 통제권의 절반의 힘은 우리 것이므로 미국의 북침을 막을 수 있었다.
미국이 전시작전통제권을 환수해주면, 미군이 우리나라에서 나가게 된다.
경제적인 이득
미국이 제공하던 국방의 일부를 자력으로 해결해야 하므로 추가적인 비용이 발생한다. 정부의 예산은 충분하지 않을것이다. 우리나라는 부유하지 않다.
전략정보의 100% 를 주한미군에서 받고 있다. ~~ (이 부분 좋다!)
(현대는 정보전이라는 것 다들 알고 계실겁니다. 추가하면 좋을 것 같다)
첨단정보 기기를 도입하는데 10년이나 걸린다는 장관의 말을 인용. 충분한 시간이 필요하다. 돈만이 아니라.
감정적인 이유로 전작권을 환수하는 것은 타당하지 않다.
ahn jun hyung
서울 시내 대표적인 재즈클럽 중에요
- 대학로 재즈 클럽 : 천년동안도
- 이태원 재즈 클럽: 올댓재즈
- 청담동 재즈 클럽: 원스인어블루문, 야누스
- 삼청동 재즈 클럽: 재즈 스토리
에 대해 궁금합니다.
매일 재즈 공연이 있는 재즈 클럽과 공연이 없는 재즈클럽으로 나눠서 알구 싶습니다.
모든 재즈 클럽에서 매일 라이브 공연이 있습니다..
다른 곳은 다 가봤고 재즈 스토리만 가보지 않았는데..
거기도 매일 공연이 있다고 알고 있습니다..
그런데 아무래도 주말 공연이 하일라이트죠..
예전 천년동안도에서 주말에 신관웅 빅밴드 들었는데..
정말 흡겹고 좋더군요..
?GetSystemDefaultUILanguage
테스트
SSH Frequently Asked Questions
Sometimes my SSH connection hangs when exiting — the shell (or remote command) exits, but the connection remains open, doing nothing.
--------------------------------------------------------------------------------
Quick Fix
You're probably using the OpenSSH server, and started a background process on the server which you intended to continue after logging out of the SSH session. Fix: redirect the background process stdin/stdout/stderr streams (e.g. to files, or /dev/null if you don't care about them). For example, this hangs:
client% ssh server
server% xterm &
server% logout
hangs...
but this behaves as expected:
client% ssh server
server% xterm < /dev/null >& /dev/null &
server% logout
SSH session terminates
client%
Short Explanation
This problem is usually due to a feature of the OpenSSH server. When writing an SSH server, you have to answer the question, "When should the server close the SSH connection?" The obvious answer might seem to be: close it when the server-side user program started by client request (shell or remote command) exits. However, it's actually a bit more complicated; this simple strategy allows a race condition which can cause data loss (see the explanation below). To avoid this problem, sshd instead waits until it encounters end-of-file (eof) on the pipes connecting to the stdout and stderr of the user program.
This strategy, however, can have unexpected consequences. In Unix, an open file does not return eof until all references to it have been closed. When you start a background process from the shell on the server, it inherits references to the shell's standard streams. Unless you prevent this by redirecting these, or the process closes them itself (daemons will generally do this), the existence of the new process will cause sshd to wait indefinitely, since it will never see eof on the pipe connecting it to the (now defunct) shell process — because that pipe also connects it to your background process.
This design choice has changed over time. Early versions of OpenSSH behaved as described here. For some time, it was changed to exit immediately upon exit of the user program; then, it was changed back when the possibility of data loss was discovered.
Race Condition Details
As an example, let's take the simple case of:
ssh server cat foo.txt
This should result in the entire contents of the file foo.txt coming back to the client — but in fact, it may not. Consider the following sequence of events:
The SSH connection is set up; sshd starts the target account's shell as shell -c "cat foo.txt" in a child process, reading the shell's stdout and sending the data over the SSH connection. sshd is waiting for the shell to exit.
The shell, in turn, starts cat foo.txt in a child process, and waits for it to exit. The file data from foo.txt which cat write to its stdout, however, does not pass through the shell process on its way to sshd. cat inherits its stdout file descriptor (fd) from it parent process, the shell — that fd is a direct reference to the pipe connecting the shell's stdout to sshd.
cat writes the last chunk of data from foo.txt, and exits; the data is passed to the kernel via the write system call, and is waiting in the pipe buffer to be read by sshd. The shell, which was waiting on the cat process, exits, and then sshd in turn exits, closing the SSH connection. However, there is a race condition here: through the vagaries of process scheduling, it is possible that sshd will receive and act on the SIGCHLD notifying it of the shell's exit, before it reads the last chunk of data from the pipe. If so, then it misses that data.
This sequence of events can, for example, cause file truncation when using scp.
xslt 의 서버 사이드 처리
ajaxslt 브라자별로 특성이나 의존성 없이 xslt-transform 되는 라이브러리
파이썬이라면 4Suite나 PyXML
![[http]](/wiki/imgs/http.png)
http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39134231,00.htm
