동명의 만화 원작의 에니메이션. 2022.2분기 기대작이었고 역시나 기대에 부응하고 있다.
- 줄거리
세계 각국이 수면 아래에서 치열한 정보전을 벌이고 있던 시대. 동국과 서국은 수십년간 냉전 상태에 있다. 서국의 정보국 대동과 〈WISE〉 소속인 유능한 스파이인 〈황혼〉은 동서평화를 위협하는 위험인물, 동국의 국가통일당 총재 도노반·데즈몬드의 동향을 탐구하기 위해 극비임무를 부여받는다. 오퍼레이션〈올빼미〉(스트릭스). “일주일 이내에 가족을 만들어 데스몬드의 아들이 다니는 명문학교의 친목회에 잠입하라”. 〈황혼〉은 정신과 의사 로이드 포저로 변장하여 가족을 만들었다. 하지만, 그가 만난 딸 아냐는 마음을 읽을 수 있는 초능력자, 아내 요르는 살인청부업자 〈가시공주〉였다! 3명의 이해가 일치해, 서로의 정체를 숨기면서 함께 살게 된다. 해프닝이 계속되는 임시 가족에게, 세계의 평화가 달려있다――.
- 기본적으로 가족물이다. 아직까지는 잔인하거나 무시무시한 설정이 부각되지는 않는다. 하지만 주인공 및 주인공들 주변의 대치 상태를 보면 엔딩까지 가는길이 순탄치만은 않을듯. 넷플릭스에서 매주 일요일 공개되기 때문에 계속 챙겨보고 있다.
기계식 키보드를 이야기 할 때 갈축이나 청축이나 하는 이야기가 독일 체리사의 Cherry MX 스위치 축 색상에서 나온 단어다. 체리에서는 스위치의 특성에 따라 축의 색상을 구분했는데, 이게 사실상 산업 표준이 된거다.
갈축, 청축, 적축. 이 3가지 색상을 기반으로 여러가지 사양이 있다.
- 적축: 45g 리니어 스위치. 2.0mm/4.0mm 타건감 없음. 가장 소음이 적음. 눌렀다는 느낌이 적음. 소리가 작음 - 청축: 60g 클릭 스위치. 2.2mm/4.0mm 경쾌한 타건감. 클릭 소리 남. 가장 소리가 큼. - 갈축: 55g 넌클릭 스위치. 2.0mm/4.0mm 청축보다 덜한 타건감. 소리가 청축보다 작음.
※ 아래 영상을 보면 어떤 차이가 있는지 확인해볼 수 있다.
- 흑축: 60g 적축과 같은 리니어 타입에서 강한 스프링을 사용한 축. 같은 키를 자주 입력하는 작업에는 필요하나 키압이 강해 쉽게 피로를 느낄 수 있다. - 백축: 65g 제품명은 MX CLEAR다. 갈축과 같은 넌클릭 타입에서 강한 스프링을 사용한 축. 같은 키를 자주 입력하는 작업에는 필요하나 키압이 강해 쉽게 피로를 느낄 수 있다. - 회축: 80g 갈축의 스프링 강화버전이다. - 은축: 45g 적축과 같은 넌클릭 타입에서 누르는 깊이를 줄인 제품. (2mm -> 1.2mm)
May 8 21:07:59 wl gda: [ID 107833 kern.warning] WARNING: /pci@0,0/pci-ide@1f,2/ide@1/cmdk@1,0 (Disk1): May 8 21:07:59 wl Error for command 'read sector' Error Level: Retryable May 8 21:07:59 wl gda: [ID 107833 kern.notice] Sense Key: ICRC error during UDMA May 8 21:07:59 wl gda: [ID 107833 kern.notice] Vendor 'Gen-ATA ' error code: 0x16
ICRC: ATAPI 장치(예를 들어 SATA 방식의 HDD)에서 UDMA 를 사용시 ICRC(Interface CRC) 비트를 사용함 기본적으로 "전송 오류"
0x16 은 뭔가 응답이 오지 않은 경우에 해당되는듯. 재시도 가능.
일반적으로 "read sector" 커맨드에 대한 오류는 HDD 배드섹터에 기인하긴 하지만, 이 경우는 좀 아리송하다. 약 7시간 동안 45번 나고 더 이상 오류가 발생하지 않았음. 뭐징. OS 패치를 대량으로 하면 안보이던 오류가 많히 보인다. 일단 백업을 자주하는걸로 결정.
----
2024.11.27 추가
2022.05. 이후 별 이상 없다가 어제부터 이 메시지가 다시 보였다. 약 24시간 동안 267회 발생. 일단 조치사항은 없긴 한데 역시 백업은 해 놔야할듯.
블로그를 백업본으로 복구했다. 갑자기 아래와 같은 로그를 내면서 MySQL 이 죽어서 그렇다.
2022-04-20T09:00:24.015047Z 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4554ms to flush 164 and evict 0 pages 17:00:26 UTC - mysqld got signal 11 ; Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. Thread pointer: 0x2b42e148 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 7fffbf04df10 thread_stack 0x46000 /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19my_print_stacktracePKhm+0x2e [0x385a3ee] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'handle_fatal_signal+0x2f7 [0x26a6cb7] /lib/amd64/libc.so.1'__sighndlr+0x6 [0x7fffbe14ebe6] /lib/amd64/libc.so.1'call_user_handler+0x2f1 [0x7fffbe1406b1] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z27free_blob_buffers_and_resetP5TABLEj+0x77 [0x2658077] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z18close_thread_tableP3THDPP5TABLE+0xdc [0x24b192c] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19close_thread_tablesP3THD+0x28b [0x24b1c1b] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_ZN18Prepared_statement7prepareEPKcmPP10Item_param+0x881 [0x25807f1] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19mysqld_stmt_prepareP3THDPKcjP18Prepared_statement+0xb6 [0x2581016] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x2097 [0x2556917] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z10do_commandP3THD+0x174 [0x2557344] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'handle_connection+0x278 [0x2698468] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'pfs_spawn_thread+0x161 [0x3d8e4b1] /lib/amd64/libc.so.1'_thrp_setup+0xa4 [0x7fffbe14e7e4] /lib/amd64/libc.so.1'_lwp_start+0x0 [0x7fffbe14eac0]
Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (2b436af0): SHOW TABLES LIKE 'piwik_archive_numeric%' Connection ID (thread ID): 1903317 Status: NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.
- 구글링도 해봤지만 흔한 에러는 아닌듯 하다. 메시지만 보면 Data Dictionary 를 초기화하다가 오류. 그렇다면 mysql.ibd 파일에 문제가 있다는 거긴 하지만, MySQL 지원을 받을 수 있는건 아니라 포기. 만약 업체였다면 비용 들여서라도 지원받으면 되지 않을까 하는 생각이다. 예전에 5.x 버전에서 8 로 업그레이드가 제대로 안된것 같기도 하다.
- 처음에 난 덤프도 DataDictionary 를 조회하다가 오류난 것이기도 하다. 결국은 복구 불가로 판정했고 바로 백업본을 리스토어 했다. 이래서 백업은 중요하다. 매우 중요하다.
- 어쨌든 복구하느라고 MySQL 8을 재설치하고 백업본을 복구한거기 때문에, 서버가 꽤 빨라졌다. my.cnf 파일도 처음부터 재작성했다. 어쨌든 괜찮아진 느낌.
----
2022.04.26 추가
MySQL 8을 작년에 설치한것도 MySQL 5.x 에서 업그레이드한거였는데, 지금 생각해보면 뭔가 업그레이드가 잘못되었을 거 같다. my.cnf 에 문제가 있었는데도 작동했기 때문. MySQL 8 설치하고 첫 실행했을때 기동이 안되었다. my.cnf 를 초기화(내용을 전부 지움)하면 기동이 되었고. 뭔가 설정에 문제가 있긴 했던 느낌.