간단 간단하게 여행가면 정리하거나 간단한 타이핑만을 할만한 정도로 키보드가 있었으면 했고,
 그렇다고 정품을 사기에도 중고를 사기에도 가격은 만만치가 않아서 알아보던 중 구조독 매직 키보드를 알게 됬다.

간단하게 버전이 3가지 있는 것 같았다.

1. 초창기 버전 

2. 차기 버전

3. LCD 버전

초창기 버전은 간단하게 LED 3개의 빛으로 블루투스 연결이나 Capslock등을 확인할 수 있고, 블루투스 연결로 동작을 하며, 배터리는 자체 충전(USB 연결)으로 동작한다.

차기 버전은 별도의 USB 연결은 필요없고, 아이패드 배터리를 포고(POGO) 핀 연결로 아이패드의 배터리를 가져오기 때문에 사용시에 충전을 아이패드만 하면 된다는 장점이 있었고, 이 점이 매력적이 었으나 가격이 조금 더 비쌌다.

LCD 버전은 위의 두 버전 중에 어느 단계의 제품인지 찾아보려 했지만 찾기 쉽지 않았다. 하지만 가격이 저렴하게 나왔고(코인 등으로 인해 할인되어 $45에 구매함), 어차피 맨날 들고다니면서 쓸 목적이 아니라 간단하게 여행갔을 때 정도나 가끔 쓸 정도라 비싼거 살 필요가 없어서 LCD 버전으로 구매를 했다.

LCD 버전의 특징은 아래와 같다.

1. Keyboard lighting
    키보드에서 불 빛이 나오는데 상당히 이쁘다. 엄청 강력하게 나오지는 않아서 어두울때만 잘 보이긴 하지만 정말 이뻤으나, 배터리가 순삭되는게 확인되서 처음만 키고 다시는 켜지 않는다.

2. LCD
   LCD라 그래서 대단한 많은것을 보여주는 줄 알았는데 현재 배터리 %만 보여준다. 
   근데 단순히 배터리 정도가 몇단계가 아닌 백분율로 보여주니 사실 이 부분은 좀 마음에 든다.

3. 자체 충전
   USB C 타입으로 직접 연결해서 충전을 해줘야 한다. 이 부분 때문에 차기 버전을 고민했으나, 키보드 불빛만 끄니까 배터리가 그렇게 많이 닳지는 않아서 쓰다보니 별 생각은 들지 않는다.

구조독 키보드의 완성도는 상당히 칭찬을 받는 컨탠츠 등을 많이 보았다. 실제로 마감도 좋아보이고 만듬새가 괜찮고 $45달러 치고는 잘쓰겠다 싶었다. 이 포스팅도 해당 키보드로 하며, 테스트를 해보고 있는 것인데, 마음에 든다. 생각한거보다 가격보다 더 잘 쓸거 같다.

 하지만 처음 이런 키보드를 사서 그런지 원래 이런건지 블루투르가 아이패드랑 잘 안되는건지 트랙패드가 사용중에 느려지거나 뚝뚝 신호가 끊기는 것 같은 현상이 보인다. 아이패드 설정에서 속도나 터치에 대한 설정을 변경해봐도 동일한 현상이 보인다. 아무래도 안썼을 때에 키보드에서 Sleeping 모드로 들어가는 타이밍에 내가 다시 만지는건지, 자주는 아니고 가끔 발생해서 불편함을 준다.

 그렇다 하더라도 이 키보드는 잘 샀다는 생각이 든다. 모양새도 이쁘며, 강화유리를 붙였음에도 깔끔하게 접었을때 접혀서 모양도 이쁘고, 키보드 커버도 제공하는데 이 또한 품질이 나쁘지 않고, 낀 상태로 타이필을 할 경우 약간 쫀쫀해서 키감도 좋은 편이다.  혹시 누가 추천하는지 물어본다면, 가성비를 따지는 사람이라면 추천한다 라고 말하고 싶다. 항상 그랬듯 애플 제품은 정품의 완성도가 워낙 높아서 제일 좋은건 정품이지만, 가격을 분자로 두는 순간 가격이 높아 점수는 떨어지기 때문이다.

======================================================================

2주 정도 사용 후 사용기 추가

역시 좀 쓰다보니 장/단이 명확해서 추가로 남긴다.

장점
1. 저렴한 가격에 트랙패드와 키보드를 쓸 수 있다.
2. 자력이 충분해서 패드가 잘 달라 붙어 있음.
3. LCD가 있어서 배터리가 1% 단위로 어느정도 소모되는지를 체크하며 사용할 수 있음.
4. 기판 LED를 사용하지 않으면 배터리의 소모가 상당히 적어서 한번 충전으로 오래 쓸 수 있음.
5. Shotcut 키가 있어서 자주 쓰는 밝기, 음소거, 화면 잠금, 음량 조절, 등등 다양한 키를 사용할 수 있다.
6. 키판 보호 실리콘이 기본 제공이 된다.
7. 애플 트랙패드처럼 4점 컨트롤이 제공된다.
8. 마감이 나쁘지 않음.

단점
1. 트랙패드의 경우 뚝뚝 끊김 현상이 있다.
2. 트랙패드의 일부 기능이 안되는 현상이 자주 발생된다(예. 2점만 갑자기 안되는 경우가 있음)
    이럴 경우 키보드 전원을 껐다 키면 되는 경우도 있고 안되는 경우도 있음(키보느는 현재까지 이런 경우는 없음).
3. 애플 펜슬 보관/보호를 할 수 없음. 아얘 펜슬을 사용하지 않는다는 전제하의 제품으로 생각하면 됨.

결론
1. 가성비 좋다. 단점이 있음에도 가격 생각하면 충분히 용서된다(트랙패드 안되면 그냥 화면 터치 하면 되지)
2. 트랙패드가 너무 자주 사용이 원활하지 않을때가 발생하는데, 가격 생각하며 참고 쓰자

https://developer.ridgerun.com/wiki/index.php/How_to_Use_Gstreamer_Debug_Viewer

Buffer의 VideoMetadata 출력 방법

static void print_video_meta_data_all(GstBuffer *buf) {
  GstVideoMeta *meta = gst_buffer_get_video_meta(buf);
  if (meta) {
    g_print("Video Meta:\n");
    g_print("  format: %s\n", gst_video_format_to_string(meta->format));
    g_print("  width: %d\n", meta->width);
    g_print("  height: %d\n", meta->height);
    g_print("  flags: %d\n", meta->flags);
    g_print("  n_planes: %d\n", meta->n_planes);
    for (guint i = 0; i < meta->n_planes; i++) {
      g_print("  stride[%d]: %d\n", i, meta->stride[i]);
      g_print("  offset[%d]: %d\n", i, meta->offset[i]);
    }
    g_print("  map: %p\n", meta->map);
    g_print("  unmap: %p\n", meta->unmap);
  }
}

Buffer의 Metadata Count 출력 및 Metadata의 Type 출력 방법

static void print_all_meta_info(GstBuffer *buf){
  GstVideoMeta *meta = gst_buffer_get_video_meta(buf);
  if (meta)
  {
    gst_print("Video Meta Count : %d\n", meta->n_planes);
  }
  GstMeta *m;
  gpointer state = NULL;
  guint meta_count = 0;
  while ((m = gst_buffer_iterate_meta(buf, &state))) {
    g_print("Metadata API type: %s\n", g_type_name(m->info->api));
    meta_count++;
  }
  g_print("Meta count: %d\n", meta_count);
}

Buffer의 모든 Metadata 중에 LOCK 상태인 Metadata 찾는 방법

static void find_lock_meta(GstBuffer *buffer) {
  GstMeta *meta;
  gpointer state = NULL;

  while ((meta = gst_buffer_iterate_meta(buffer, &state))) {
    if (GST_META_FLAG_IS_SET(meta, GST_META_FLAG_LOCKED)) {
      g_print("Found locked meta: %s\n", g_type_name(meta->info->api));
    }
  }
}

gdb binary

일반적으로 gdb를 사용하려면 단순히 gdb binary 이렇게 간단하게 사용한다.
가끔 특정 library를 환경 변수를 주어 실해아 하는 경우가 있는데, 이럴 경우에는 env binary 이렇게 사용하는데,
gdb env binary 아니면 env gdb binary 이렇게 해도 안된다.
환경 변수는 gdb 에서 아래와 같이 사용한다.

binary 실행 예제

현재 폴더의 lib 폴더를 library path로 잡고 실행 예제

$ LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:./lib binary 

gdb 로 실행 방법

환경 변수 없이 gdb로 실행

$ gdb binary

환경 변수 설정

(gdb) set environment LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:./lib

Run

(gdb) run

Ubuntu에 LFS 설치하기

curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash
sudo apt install git-lfs

Repository에 git lfs 적용

git lfs install

Repository에 git lfs 해제

git lfs uninstall

LFS 적용하기

git lfs rm --cached FILE
git lfs track FILE

git add FILE
git commit FILE -m "MESSAGE"
git push

LFS 관리 해제

git lfs untrack FILE

LFS 관리 완전 해제

git lfs untrack FILE
git rm --cached FILE
git add FILE
git commit FILE
git push

LFS 적용 확인

${REPO ROOT}/.gitattributes에 추가되어 있음.

LFS 리스트 확인

git lfs ls-files

LFS 적용된 Repository clone

git clone URL
git lfs pull

참고 : https://newsight.tistory.com/330

Visual Studio Code가 업데이트가 되지 않고 있었다는것을 찾았다.

업데이트를 수작업을 실행하면 아래와 같이 오류가 발생한다.

아래와 같이 수정한 뒤에 정상적으로 업데이트가 되는 것을 확인했다.

1. APP의 위치 확인
    - APP의 위치가 Download의 상태에서 그대로 사용했다.
    - APP의 위치를 Application으로 이동시켰다.

2. 캐시 삭제
    - $ rm -rf ~/Library/Caches/com.microsoft.VSCode/*

$ git log origin/<branch name>..HEAD

Includes & Defines

#include <chrono>
using std::chrono::duration;
using std::chrono::duration_cast;
using std::chrono::high_resolution_clock;
using std::chrono::milliseconds;

Pre

auto before = high_resolution_clock::now();

Post

auto after = high_resolution_clock::now();

Milliseconds processing time(int type)

auto milliseonds_processing_time= duration_cast<milliseconds>(after - before).count();

NVIDIA PCI Vendor ID 로 잡히는 것이 있는지 확인

# NVIDIA Vendor ID : 10de
$ lspci -nn -d 10de:*

lspci update

최신 GPU일 경우 pci id 업데이트가 안되어서 안나올 수 있음.

$ sudo update-pciids

lspci에 Vendor ID 로 잡히는 것이 없을 경우

lspci에서 Veodor ID로 잡히는게 없을 경우 PCI Express 에서 잡히는게 없을 경우, 해당 카드가 인식자체가 되지 않았을 가능성이 있음.

• 소비 전력 확인 및 보조 전력 확인
  소비 전력이 300W이상인데 그 이하의 적절하지 않은 부족한 전력 연결시, 인식자체가 되지 않는 현상을 확인함.
  올바르게 연결(8 Pin * 2)한 이후 정상적으로 lspci에 리스팅 된 것을 확인할 수 있었음.

docker> $ cat /proc/self/cgroup | grep docker

마지막 Checksum을 OS Native에서 Docker container의 Checksum과 비교하면 된다.

$ docker container ls -a