반응형

OS: Ubuntu 16.04


우분투(Ubuntu)에서 기본으로 제공하는 terminal에서 screen을 사용하면 한 화면을 여러 개의 쉘(shell)로 쪼개서 쓸 수 있다. 시스템에 screen이 설치되어 있어야 한다.


*화면 분할 방법

먼저 터미널 창에서 screen 을 실행한다.

screen에 대한 소개와 설명이 나오는데, 엔터를 치고 shell이 나오게 한다.


$ screen



1. 세로로(vertical) 화면 분리:

Ctrl + a 를 누른 다음, (이후 모든 키에서 손을 떼도 된다)

| 키 (Shift + \, 백스페이스 밑에 있는 키)를 입력


2. 가로로(horizontal) 화면 분리:

Ctrl + a 를 누른 다음, (이후 모든 키에서 손을 떼도 된다)

대문자 S 키 (Shift + s)를 입력


3. 분리된 화면으로 커서를 이동시키기:

Ctrl + a 를 누른 다음, (이후 모든 키에서 손을 떼도 된다)

탭(Tab) 키를 누르면 분할된 화면으로 하나씩 커서가 이동한다.


4. 분리된 새 화면에 쉘 실행:

맨 처음 화면을 분리시키면 검은색만 나오고 아무 것도 없다.

일단 Ctrl + a, Tab으로 해당 위치로 커서를 이동시킨다.

그 다음, Ctrl + a를 누른 뒤에 소문자 c 키를 눌러 준다.






(2018.03.26 추가)

기본 터미널에서 screen으로 화면 분할해서 사용해 보니, 살짝 불편한 점이 두 가지 있다.

 - 마우스를 이용해서 커서를 특정 화면으로 옮길 수 없는 것과,

 - 각 화면에서 이미 지나가 버린 화면을 마우스 휠 스크롤을 써서 볼 수 없는 것.


이 두 가지를 제외하고는 쓸만한 것 같다.




<참고자료>

https://unix.stackexchange.com/questions/7453/how-to-split-the-terminal-into-more-than-one-view




반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 16.04

Shell: bash



배쉬(bash) 쉘에서 반복문, 즉 루프(loop)를 돌릴 때 여러가지 방법을 사용할 수 있다.



1. seq 사용


가장 간단한 방법이다. seq라는 프로세스가 순서대로 숫자를 출력해 주는 역할을 하는데, 그 결과를 문자열로 받아서 루프로 사용한다.


skylit@Linux:~$ seq 1 10
1
2
3
4
5
6
7
8
9
10


배쉬 쉘에서 seq를 바로 실행하면 위와 같이 나오고, 이것을 문자열로 사용해서 루프를 돌린다.


#!/bin/bash


SET=$(seq 0 9)

for i in $SET

do

    echo "Running loop seq "$i

    # some instructions

done


실행 결과:

Running loop seq 0
Running loop seq 1
Running loop seq 2
Running loop seq 3
Running loop seq 4
Running loop seq 5
Running loop seq 6
Running loop seq 7
Running loop seq 8
Running loop seq 9




2. 공백으로 구분된 문자열 사용


위의 seq를 그냥 수동으로 입력하는 방법이다. seq 쓰는 것과 아무 차이가 없고, 대신 사용자가 원하는 순서대로 숫자의 나열을 바꾸거나 뺄 수 있다.

루프 돌리는 수가 적고, 특정한 번호 순서를 직접 명시하고 싶을 때 유용하다.

#!/bin/bash


ORDER="5 6 7 8 9 4 3 2 1 0"

for i in $ORDER

do

    echo "Running loop "$i

    # some instructions

done


실행 결과:

Running loop 5
Running loop 6
Running loop 7
Running loop 8
Running loop 9
Running loop 4
Running loop 3
Running loop 2
Running loop 1
Running loop 0


물론 숫자 말고 다른 문자열도 가능하다.


#!/bin/bash


ORDER="apple orange watermelon"

for i in $ORDER

do

    echo $i

    # some instructions

done


실행 결과:

apple
orange
watermelon




3. bash의 루프 문법 사용


C/C++과 가장 유사한 형태라서 편하게 쓸 수 있다.

그리고 앞서 소개한 두 방법은 메모리에 문자열 변수를 할당하고 있어야 하는데 루프의 수가 매우 커지면 문자열의 길이도 그만큼 길어지기 때문에, 혹시나 너무 큰 루프 숫자로 인해 발생하는 메모리 문제를 방지하고 싶다면 이 방법이 유리하다.


#!/bin/bash


for ((i=0;i<=9;i++))

do

    echo "Running loop "$i

    # some instructions

done


실행 결과:

Running loop 0
Running loop 1
Running loop 2
Running loop 3
Running loop 4
Running loop 5
Running loop 6
Running loop 7
Running loop 8
Running loop 9







반응형
블로그 이미지

Bryan_

,
반응형
  • Client OS: Ubuntu 16.04
  • FreeRDP (xfreerdp) version: 2.0.0-dev2 (3c4385e)
  • Server OS: Windows 10 (version 1709, build 16299.309)



xfreerdp를 이용해서 리눅스에서 원격 윈도우 머신에 RDP (Remote Desktop Protocol) 연결을 해서 쓰고 있었는데, 2018년 들어서 윈도우10이 업데이트되고 나서는 아래와 같이 오류가 나면서 접속이 되지 않았다.



[19:43:47:999] [2320:2321] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[19:43:47:033] [2320:2321] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_PASSWORD_CERTAINLY_EXPIRED [0x0002000F]
[19:43:47:033] [2320:2321] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error


확인해 보니, 윈도우 10에서 네트워크 수준 인증(Network Leval Authentication; NLA)을 사용하여 원격 접속을 허용하는 옵션과 연관된 듯 했다. 비슷한 문제를 겪는 사람들의 의견을 봤을 때, NLA 옵션을 끄니까 다시 되더라는 사람도 있었고, xfreerdp를 실행할 때 보안 옵션(/sec)으로 nla를 지정해 주었더니 되더라는 사람도 있었다.




*네트워크 수준 인증 (NLA) 끄는 방법:

  1. 시작버튼 누르고 "제어판"이라고 입력해서 제어판(윈도우10 설정 말고) 실행
  2. 시스템 선택
  3. 좌측에 "원격 설정" 선택
  4. 하단 부분에 "이 컴퓨터에 대한 원격 연결 허용" 아래에 있는 체크박스 해제 (네트워크 수준 인증을 사용하여 원격 데스크톱을 실행하는 컴퓨터에서만 연결 허용 (권장))



*xfreerdp에서 보안 옵션 지정하는 방법:

커맨드 라인에서 실행할 때 /sec 옵션을 추가해 준다.

  • 네트워크 수준 인증을 사용할 경우, /sec:nla
  • 그렇지 않을 경우, /sec:tls



나는 NLA 옵션을 끄고, xfreerdp를 실행할 때 /sec:tls 옵션을 추가했더니 문제 없이 접속이 잘 되었다.




<참고자료>

https://github.com/FreeRDP/FreeRDP/issues/4449#issuecomment-372979253



반응형
블로그 이미지

Bryan_

,
반응형

내 블로그에도 구글 애드센스(AdSense)를 달아 놓았고, 인터넷을 다니면서 구글 광고는 흔하게 많이 접한다. 몇 년 전부터 지금까지 구글 광고를 보면서 느끼는 명백한 한계점이 하나 있는데, 바로 "내가 이미 구입을 완료한 제품에 대한 광고를 지속적으로 나에게 노출시키 것"이다.


직접 확인한 두 가지 사례가 있다.

첫 번째로, 해외에 잠시 다녀오기 위해서 호텔 검색 사이트(호X스닷컴)에서 특정 지역의 호텔들을 검색해서 몇 개를 살펴보았고, 그렇게 며칠 동안 검색한 뒤에 하나를 정해서 예약과 결제를 모두 완료했다. 그런데 그 뒤로 일주일이 지나도록 내가 인터넷을 돌아다닐 때마다 거의 대부분의 구글 광고에서, 내가 이미 예약한 바로 그 호텔에 대한 광고를 보여주는 것이었다. 우스운 것은, 내가 며칠 전에 결제했을 때의 가격보다도 더 비싼 가격을 "특가"라고 광고하는 것이었다. ㅎㅎ


두 번째는, 얼마 전에 스마트폰 케이스를 사기 위해서 또 구글 검색을 여러 번 했고, 그 중에 매우 얇은 케이스 하나를 잘 구입했는데, 구입한 지 벌써 몇 주가 지났는데 오늘 갑자기 구글 광고에서 내가 구입한 것과 정확히 똑같은 제품을 광고의 한 가운데에 배치해서 보여주었다. 내가 그 케이스를 구입한 쇼핑몰에서 내보낸 광고였는데, 다른 모양의 케이스들이나 강화유리를 보여줬을 만도 한데 정확히 내가 구입한 그 물건만 일부러 강조해서 광고에서 표시되고 있었다.


결국 구글은 내가 검색하고 가장 많이 쳐다보고 있었던 페이지가 무엇인지는 알고 있지만, (쇼핑몰 사이트에 내장된 구글 애널리틱스와 내 구글 계정의 검색 기록을 종합하면 아마 쉽게 알 수 있을 것이다) 내가 이미 구입해서 더 이상 흥미가 없는 제품이라는 판단은 아직 못 하는 듯 하다.


솔직히 구매 내역도 내 계정의 지메일을 조사하면 알 수 있을 텐데, 내 지메일도 속속들이 다 들여다 보고 있으면서 (호텔이나 항공권을 결제하면 내가 시키지도 않았는데 자동으로 구글 캘린더에 모두 등록되는 것만 봐도 알 수 있다), 구글 광고에 보여 줄 제품을 표시할 때에 지메일을 적극적으로 확인하지 않는 것은 좀 의외다.

아직 특정 쇼핑몰에서 보내 주는 주문/구매 내역에 대한 이메일 내용을 "자신 있게(충분한 confidence level을 유지한 채)" 분석해 내지는 못하는 것인가 하는 생각이 든다. 쇼핑몰이나 각종 결제 사이트마다 워낙 레이아웃과 텍스트 내용이 제각각이라서 아마 정확도를 높이기가 아직은 쉽지는 않을 지도 모르겠다.


하지만 사실 구글 어시스턴트와 같이 음성인식 비서가 발전하는 속도로 봤을 때, 이메일에 적혀 있는 자연어와 표 형식으로 잘 구분된 데이터 (대부분의 주문 내역은 표를 이용해서 제품 이름과 구매수량, 단가, 결제금액, 시간 등을 정렬해서 보여주고 있으니까)를 머신러닝을 써서 분석해 내는 것은 마음만 먹으면 금새 해낼 수 있을 것 같다.

결국 구글이 애드센스의 광고 추천 정확도를 지금보다 조금 더 개선시키기 위해서 사용자의 지메일 상의 각종 구매 내역과 전세계 쇼핑몰 사이트에서의 구글 애널리틱스에 기록된 방문 기록을 종합해서 빅데이터 분석을 수행할 의지가 있느냐 없느냐의 문제로 귀결된다.


...물론 이렇게 소소하게 구글이 인터넷에서 나에게 추천하는 모든 것에 대한 정확도를 높여 갈 수록 사람들은 오히려 구글을 더 무서워하게 될 지도 모른다. (이미 돌이킬 수 없게 무서운 존재인 것은 사실이지만...) 구글은 너무 무서워지지 않기 위해서 일부러 안하고 있는 것일까?




반응형
블로그 이미지

Bryan_

,
반응형

연구에 대한 실험 코드를 고쳐 가며 새로 데이터를 뽑고, 또 문제가 있거나 개선할 부분이 보이면 다시 고치기를 반복하고 있다. 이 과정에서 내가 개인적으로 유난히 시간을 많이 소비하는 단계가 있음을 알게 되었는데, 바로 어떤 설계(design)으로 개선해서 목적을 달성할 것인지 결정하는 단계이다.


예를 들어, 라우팅 프로토콜을 고치는 과정에서, source node가 자신이 트래픽을 보내기 위해서 먼저 경로를 탐색(route discovery)하고 선택해야 하는데, 이러한 과정을 자주 하게 되면 그만큼 네트워크 전체에 부정적인 영향을 끼치게 된다. 이러한 route discovery 자체를 줄이기 위해서 먼저 실제로 route discovery를 몇 번씩 했는지 파악을 할 필요가 생겼다. 이것을 어떻게 기록할 것인지 생각을 해 보았는데,

  1. 그냥 각 source node의 ID로 된 텍스트 파일을 만들고, 매 초마다 route discovery를 몇 번 했는지 숫자를 텍스트 파일에 시간 순서대로 한 줄씩 기록하는 방법
  2. Route discovery 전체를 기록하는 텍스트 파일 한 개를 만들고, 모든 source node가 같은 파일 포인터에 접근해서 시간, 노드ID, route discovery를 수행했다는 flag를 한 줄로 기록하는 방법

위의 두 가지 외에도 다양한 방법들로 기록할 수 있어 보였다.


그런데 나중에 통계를 내고 엑셀 파일 같은 곳에 가져다 쓸 것까지 생각을 해 봤을 때 어느 방법이 가장 좋은지 쉽게 판단이 잘 안 되는 것이었다. 이게 깔끔하게 마음 편한 방법으로 잘 정리가 되지 않자, 이것 때문에 하루 종일 다른 작업을 못하고 그냥 고민만 하고 딴짓만 하다가 시간을 보내고 말았다.


사실은 내가 연구 측면에서 정의한 문제를 해결하는 방법이 아니고, 라우팅프로토콜의 성능을 측정하는 데 필요한 작은 통계 생성 방법일 뿐이고 어떤 설계를 따르던지 어차피 시뮬레이션 성능에 큰 영향을 주지는 않기 때문에 무시하고 한 가지를 얼른 정해서 진행을 해도 되는 것이었는데, 어느 한 가지를 고르는 것이 속 시원하지 못하다는 이유로 연구 전체를 진행하지 못하고 마치 트랩에 걸리듯이 꼼짝하지 못했다.


결국 지금 밤이 되어서 그냥 첫 번째 방법으로 진행해서 얼른 경로 탐색에 대한 기록부터 만들어내고, 그렇게 각 source node별로 만들어진 기록을 합산하는 스크립트를 파이썬으로 빨리 만들어서 붙이기로 했다. 사실 이미 각 노드마다 flow 트래픽 사용량에 대한 통계를 똑같은 방식으로 만들어 내고 똑같이 파이썬 코드로 후처리(post-processing)를 하고 있었기 때문에 기존의 코드를 재활용해서 가장 적은 시간을 들여서 통계를 만들어낼 수 있는 것이기도 했다. (지저분하게 파일 개수가 많아지는 것, ns-3 코드 상에서 파일 포인터가 많아지는 것 외에는 그 어떤 문제도 없기도 하고...)


나는 지나치게 조심스러운 것이 단점이므로, 그냥 가급적이면 조금 더 빨리 결정한 다음, 뒤도 돌아보지 말고 밀어붙인 뒤에 나중에 문제가 터지면 그것을 그 시점에서 재빨리 고쳐 나가서 목적부터 달성하기 위해 노력해야겠다.



그러므로 내일 일을 걱정하지 말아라. 내일 일은 내일 걱정할 것이오. 한 날의 괴로움은 그 날의 것으로 충분하다 (마태복음 6:34)





반응형
블로그 이미지

Bryan_

,