hotchpotch/wikipedia-multilingual-ir-related-paragraph-pairs huggingface dataset:
키예프 (카메라 브랜드)
Section: 키예프 35mm 레인지파인더 카메라

아르세날 공장에서는 전쟁배상금으로 얻은 제2차 세계 대전 콘탁스 II 및 콘탁스 III 카메라를 생산했었다.

키예프 레인지파인더는 자이스의 콘탁스 거리계 연동 카메라와 동일한 렌즈 마운트를 유지하여 두 브랜드 간에 같은 렌즈를 교체할 수 있었다. 소위 '콘탁스/키예프 마운트'은 실제로는 두 개의 마운트로 구성되어 있으며, 내부 마운트와 더불어 외부 렌즈에 사용하는 외부 마운트가 있다. 이 마운트의 경우, 카메라가 렌즈를 잡고 돌기에 헬리코이드가 필요가 없으며, 또한 이런 구조로 인해 다른 마운트들과 호환이 쉽게 되지 않으며, 변환기가 비싼 경향이 있다.

키예프 레인지파인더 카메라는 1987년에 생산 중단되었으며, 생산품은 전전 드레스덴 및 전후 예나와 슈투트가르트 콘탁스보다 훨씬 많았었다.

제2차 세계 대전이 끝난 후, 1946년부터 소련은 드레스덴 자이스 공장의 도면, 기술자, 제품 부품들을 키예프로 이전시켰다. 이런 이유로 일부 아주 초기 키예프 카메라의 전면을 제거하면, 금속에 원래 콘탁스 이름이 찍혀 있었고, 그 다음 압출되어 키예프로 다시 찍혀 있었다. 1950년대 초에 키예프 카메라의 모든 부품은 우크라이나에서 생산되었다.
키예프 (카메라 브랜드)
Section: 키예프 35mm SLR

키예프 10의 발전된 형태로, 소량만 생산되었다. 주요 차이점은 노출계가 상단에서 측면으로 이동한 것이었다. 이는 키예프 10의 중앙에 위치한 노출계가 반짝이는 크롬 렌즈에 태양광이 반사되어 부정확했기 때문인 것으로 보여진다.

키예프 10은 소련에서 생산된 가장 혁신적인 카메라 중 하나였다. 자동 노출을 제공하는 최초의 카메라 중 하나였으며, 또한 후속 모델들과 공유하는 자체 렌즈 마운트를 특징으로 했다. 카메라는 셀레늄 노출계를 가지고 있었지만, 정확도는 시간이 지남에 따라 감소했다.
Pax (명령어)
Section: 표준화, 수용 및 인기도

2001년에 IEEE에 의해 표준화되었음에도 불구하고, 2010년 기준으로 pax는 비교적 인기가 적거나 채택률이 낮다. 이는 부분적으로 유닉스 사용자들로부터 이에 대한 필요성이 없었기 때문이며, 단지 POSIX 위원회가 더 일관된 인터페이스를 원했을 뿐이다. Pax는 또한 상당히 수다스럽고 문제가 발생하면 사용자 상호 작용을 기대한다.

pax는 2005년 7월 6일에 출시된 버전 3.0부터 리눅스 기본 규격에 의해 모든 준수 시스템에 존재해야 하지만 지금까지 기본적으로 이를 탑재하고 설치하는 리눅스 배포판은 거의 없다. 그러나 대부분의 배포판은 pax를 별도로 설치 가능한 패키지로 포함한다.
Pax (명령어)
Section: 역사

pax의 첫 공개 구현은 마크 H. 콜번(Mark H. Colburn)이 1989년에 작성했다. 콜번은 이를 comp.sources.unix에 유즈닉스/IEEE POSIX의 TAR 및 CPIO 대체 프로그램으로 게시했다. HP-UX, IRIX, SCO UNIX의 pax 매뉴얼 페이지는 pax를 콜번의 작품으로 언급한다.

1990년 7월의 POSIX.2 드래프트 10부터 pax 명령어를 다룬다. 또한 1991년 POSIX.2 및 IEEE 1003.1b 드래프트는 cpio 및 ustar 아카이브 형식을 특징으로 하는 pax 명령어를 다룬다.
Pax (명령어)

pax는 다양한 운영체제에서 사용할 수 있으며 1995년부터 정의된 아카이빙 유틸리티이다. tar와 cpio 사이에 발생한 호환되지 않는 옵션들과 다양한 유닉스 버전에서 이들의 구현을 정리하기보다는, IEEE는 두 아카이버의 유용한 옵션을 모두 지원할 수 있는 새로운 아카이브 유틸리티인 pax를 설계했다. pax 명령어는 유닉스 및 유닉스 계열 운영체제와 IBM i, 그리고 마이크로소프트 윈도우 NT에서 윈도우 2000까지 사용할 수 있다.

2001년에 IEEE는 기본적으로 확장 속성이 추가된 tar와 유사한 새로운 pax 형식을 정의했다. 이 형식은 대부분의 리눅스 배포판 및 FreeBSD의 pax 명령어에서는 지원되지 않지만, GNU 및 FreeBSD의 tar 명령어에서는 지원된다. 이 형식은 AIX, Solaris 및 HP-UX의 pax 명령어에서도 지원된다.
Tput
Section: 역사

시스템 V 릴리스 3은 서로 다른 초기화 기능을 새로운 옵션 init으로, 재설정 기능을 reset으로 통합하여 터미널을 초기화하거나 재초기화하는 tput 사용을 간소화한 개선된 버전을 제공했다. 시스템 V 릴리스 3.2는 terminfo 데이터베이스에 swidm (enter_doublewide_mode)와 같은 몇 가지 프린터 관련 기능을 추가하여 tput이 사용할 수 있게 했다. 또한 색상 기능도 추가했다.

시스템 V 릴리스 4는 tput이 사용할 수 있는 표준화된 ANSI 색상 기능 setaf와 setab를 포함한 추가 terminfo 기능을 정의했다.

BSD 플랫폼은 4.3BSD-Reno (1990년 6월)에 tput의 다른 구현을 제공했다. 이 구현은 termcap을 사용했으며, termcap 기능 이름만 인식했고, 커서 주소 지정에 대한 명령줄 매개변수를 허용하지 않았다. FreeBSD는 1994년에 이를 사용하여 하나 또는 두 개의 숫자 명령줄 매개변수를 허용하도록 개선했다.
Terminfo
Section: 제한 및 확장

14자 제한은 파일 이름이 그 이상 길 수 없었던 매우 오래된 파일 시스템을 대상으로 한다. 그러한 파일 시스템은 일반적으로 구식이 되었지만, 이 제한은 1980년대 후반부터 문서화되어 있었고 그 이후로 검토되지 않았다.

오픈 그룹은 terminfo의 제한(최소 보장 값)을 문서화하는데, 이는 소스 파일에만 적용된다.
이 중 특히 중요한 두 가지는 다음과 같다.

단말기 별칭의 최대 14자

숫자 값의 최대 32,767
Terminfo
Section: 데이터 모델

설명에는 관례적인 이름을 가진 하나 이상의 기능이 포함된다.
기능은 불리언, 숫자, 문자열 유형을 가진다.
terminfo 라이브러리는 각 기능 이름에 대해 미리 정의된 유형을 가지고 있다.
다음 구문을 통해 각 기능의 유형을 확인한다.

terminfo 데이터베이스는 하나 이상의 단말기 설명으로 구성된다.

각 설명은 단말기의 표준 이름을 포함해야 한다. 또한 단말기 이름에 대한 하나 이상의 별칭을 포함할 수 있다. 표준 이름 또는 별칭은 라이브러리가 terminfo 데이터베이스를 검색하는 키이다.
Terminfo

terminfo 데이터베이스는 수백 가지의 다른 단말기 디스플레이 기능을 설명할 수 있다. 이를 통해 외부 프로그램은 단말기 유형에 독립적으로 문자 기반 디스플레이 출력을 가질 수 있다.

Terminfo는 프로그램이 단말기를 장치 독립적인 방식으로 사용할 수 있도록 하는 라이브러리이자 데이터베이스이다. 메리 앤 호턴은 termcap에 대한 개선책으로 1981-1982년에 최초의 terminfo 라이브러리를 구현했다. 개선 사항은 다음과 같다.
Termcap
Section: 제한 및 확장

원래 termcap 구현은 적은 메모리를 사용하도록 설계되었다.

첫 번째 이름은 16비트에 맞도록 두 글자이다.

기능 이름은 두 글자이다.

설명은 1023자로 제한된다.

정의가 있는 하나의 termcap 항목만 포함될 수 있으며, 반드시 끝에 있어야 한다.

terminfo 라이브러리의 termcap 에뮬레이션은 위치를 제한하지 않고 여러 다른 항목을 포함할 수 있도록 한다. termcap 라이브러리의 몇 가지 다른 최신 구현도 이 기능을 제공할 수 있지만, 잘 문서화되어 있지는 않다.
Termcap
Section: 저장 모델

TERMCAP 환경 변수에는 termcap 데이터베이스가 포함될 수 있다. 이는 터미널 에뮬레이터가 셸 및 종속 프로그램에 터미널 특성을 제공하기 위해 설정하는 단일 termcap 설명을 저장하는 데 가장 자주 사용된다.

Termcap 데이터는 텍스트로 저장되므로 쉽게 수정할 수 있다. 텍스트는 파일이나 환경 변수에서 termcap 라이브러리에 의해 검색될 수 있다.

TERM 환경 변수에는 터미널 유형 이름이 포함되어 있다.
Termcap
Section: 데이터 모델

Termcap 설명은 하나의 설명의 내용을 다른 설명에 포함시키고, 포함된 설명에서 기능을 억제하거나, 기능을 재정의하거나 추가하여 구성할 수 있다. 어떤 저장 모델이 사용되든, termcap 라이브러리는 요청 시 요청된 설명에서 터미널 설명을 구성하며, 포함, 억제 또는 재정의를 수행한다.

문자열 기능은 기능 이름과 해당 값 사이에 "="이 있다.

숫자 기능은 기능 이름과 해당 값 사이에 "#"이 있다.

불리언 기능은 연결된 값이 없다(지정되면 항상 참이다).

termcap을 사용하는 애플리케이션은 일반적으로 사용되는 기능에 대해 특정 유형을 기대하며, 데이터베이스 내용이 가정된 유형과 일치할 때만 성공적으로 반환되는 라이브러리 호출을 사용하여 termcap 데이터베이스에서 기능 값을 얻는다.
NILFS
Section: 설계

로그 구조화 파일 시스템으로 알려진 카피 온 라이트 기술을 사용하여 NILFS는 모든 데이터를 연속적인 로그와 같은 형식으로 기록하며, 이 형식은 덮어쓰지 않고 오직 추가만 된다. 이 방식은 탐색 시간을 줄이고 기존 파일 시스템에서 충돌 후 발생하는 데이터 손실을 최소화하도록 설계되었다. 예를 들어, 시스템이 쓰기 작업 중에 충돌하면 Ext3 파일 시스템에서 데이터 손실이 발생한다. 시스템이 재부팅되면 저널은 쓰기가 완료되지 않았음을 기록하고 부분 데이터 쓰기는 손실된다.

솔라리스 운영체제 및 BSD에서 사용되는 UFS 파생 파일 시스템과 같은 일부 파일 시스템은 이러한 데이터 손실을 방지하는 스냅샷 기능을 제공하지만, 대규모 파일 시스템에서는 스냅샷 구성이 길어질 수 있다. 반대로 NILFS는 NTT Labs에 따르면 "서비스를 중단하지 않고 파일 시스템의 즉각적인 상태를 지속적이고 자동으로 [저장]할 수 있다."
NILFS
Section: 개발자

사토 코지

가미무라 나루히코

기하라 세이지

아마가이 요시지

히후미 히사시 및

모리아이 사토시.

다른 주요 기여자는 다음과 같다.

안드레아스 로너

댄 맥기

데이비드 아렌트

NTT Corporation 연구소에서 일했거나 현재 일하고 있는 nilfs-utils의 일본인 주요 저자 및 주요 기여자는 다음과 같다.

고니시 류스케 (주요 관리자, 2008년 2월 ~ 현재)
NILFS
Section: 기능

백그라운드 쓰레기 수집 (GC)
여러 스냅샷 유지 가능
사용자 공간 데몬에 의해 제공되는 GC 정책 선택 가능

마운트 시 빠른 충돌 복구

메타데이터 파일 및 데이터 파일에 대한 미리 읽기

스냅샷
자동으로 지속적으로 생성됨
볼륨이 가득 찰 때까지 스냅샷 수에 제한 없음
읽기 전용 파일 시스템으로 마운트 가능
쓰기 가능한 마운트와 동시에 마운트 가능 (사용 중 일관된 백업 생성에 편리함)
빠른 목록 생성
FTPFS

리눅스 시스템에서 FTPFS는 처음에는 사용자가 FTP 서버를 로컬 파일 시스템에 마운트할 수 있도록 하는 리눅스 커널 모듈로 구현되었지만, 완벽한 방법으로 여겨지지는 않았다. 2003년에는 LUFS를 사용하도록 전환되었고, 이후 FUSE로 전환되었다. 현재는 FTP 트랜잭션에 보편적인 libcurl을 사용하기 때문에 CurlFtpFS라고 불리며 주요 리눅스 배포판의 일부가 되고 있다. FTP 사이트의 스마트 미러링을 위한 LftpFS도 존재한다.

FTPFS는 표준 API를 통해 파일 전송 프로토콜(FTP) 서버에 대한 액세스를 지원하는 파일 시스템을 의미한다.

플랜 9의 ftpfs 명령어는 데니스 리치가 고안했으며 시스템의 첫 번째 릴리스(1992년)에 포함되었다. 이는 FTP를 통해 접근 가능한 원격 파일 시스템을 로컬 파일 시스템의 일부처럼 보이게 했다.
AdvFS
Section: 기능

파일 세트는 균형을 이룰 수 있으며, 이는 파일 세트의 파일 내용이 물리적 볼륨 전체에 걸쳐 균형을 이룰 수 있음을 의미한다. 파일 세트의 특정 파일은 사용 가능한 볼륨에 걸쳐 스트라이프될 수 있다.

주요 기능은 다음과 같다:

빠른 충돌 복구를 위한 저널

삭제 복구 지원

고성능

관리자가 파일 시스템을 즉석에서 관리할 수 있는 동적 구조

즉석 스냅샷 생성

도메인에 활성 사용자가 있는 동안 조각 모음
AdvFS
Section: 역사

Tru64 UNIX Advanced File System으로도 알려진 AdvFS는 1980년대 후반부터 벨뷰의 디지털 이큅먼트 코퍼레이션 공학자들이 개발하기 시작했다(DECwest). 이 프로젝트는 취소된 OZIX 운영체제 프로젝트의 파일 시스템으로 시작되었다.

1996년, 리와 데카스는 Petal로 알려진 새로운 디스크 가상화 계층 위에 AdvFS를 사용하는 방법을 설명했다. 나중 논문에서, 데카스 등은 Petal 위에 구축된 자체 파일 시스템(Frangipani)을 설명하고 동일한 저장 계층에서 실행되는 AdvFS의 성능과 비교했다.
GPFS
Section: 정보 수명 주기 관리

파일셋(fileset)은 파일 시스템 이름 공간의 하위 트리이며, 이름 공간을 더 작고 관리하기 쉬운 단위로 분할하는 방법을 제공한다. 파일셋은 할당량을 설정하고 초기 데이터 배치 또는 데이터 마이그레이션을 제어하는 정책에 지정될 수 있는 관리 경계를 제공한다. 단일 파일셋의 데이터는 하나 이상의 저장 풀에 존재할 수 있다. 파일 데이터가 어디에 존재하고 어떻게 마이그레이션되는지는 사용자 정의 정책의 규칙 세트를 기반으로 한다.

두 가지 유형의 사용자 정의 정책이 있다: 파일 배치 및 파일 관리. 파일 배치 정책은 파일이 생성될 때 파일 데이터를 적절한 저장 풀로 보낸다. 파일 배치 규칙은 파일 이름, 사용자 이름 또는 파일셋과 같은 속성으로 선택된다. 파일 관리 정책은 파일 데이터를 이동하거나 복제하거나 파일을 삭제할 수 있도록 한다. 파일 관리 정책은 디렉터리 구조에서 파일의 위치를 변경하지 않고 데이터를 한 풀에서 다른 풀로 이동하는 데 사용될 수 있다. 파일 관리 정책은 마지막 접근 시간, 경로 이름 또는 파일 크기와 같은 파일 속성으로 결정된다.
GPFS
Section: 아키텍처

HDFS 또한 파일을 블록으로 나누어 다른 파일 시스템 노드에 저장한다.

GPFS는 완전한 POSIX 파일 시스템 시맨틱스를 가진다.

GPFS는 디렉터리 인덱스 및 기타 메타데이터를 파일 시스템 전체에 분산한다. 대조적으로 하둡은 이를 기본 및 보조 네임노드에 보관하며, 이들 대규모 서버는 모든 인덱스 정보를 RAM에 저장해야 한다.

다른 기능으로는 고가용성, 이기종 클러스터에서의 사용 가능성, 재해 복구, 보안, DMAPI, HSM 및 ILM이 있다.

하둡의 HDFS 파일 시스템은 상품 하드웨어, 즉 RAID 디스크 및 스토리지 에어리어 네트워크(SAN)가 없는 데이터 센터에 유사하거나 더 많은 양의 데이터를 저장하도록 설계되었다.
GPFS
Section: 역사

또 다른 조상은 1992년부터 1995년 사이에 IBM 토마스 J. 왓슨 연구 센터의 연구 프로젝트로 개발된 IBM의 베스타(Vesta) 파일 시스템이다. 베스타는 고성능 멀티컴퓨터에 병렬 I/O 서브시스템이 실행되는 병렬 애플리케이션의 요구를 수용하기 위해 파일 파티셔닝 개념을 도입했다. 파티셔닝을 통해 파일은 바이트 시퀀스가 아니라 병렬로 접근할 수 있는 여러 개의 분리된 시퀀스이다. 파티셔닝은 파일 시스템을 호스팅하는 I/O 노드의 수와 유형을 추상화하고, I/O 노드 내의 물리적 데이터 분배와 관계없이 다양한 논리적으로 파티션된 파일 보기를 허용한다. 분리된 시퀀스는 병렬 애플리케이션의 개별 프로세스에 대응하도록 배열되어 확장성을 향상시킨다.

베스타는 1994년경 PIOFS 파일 시스템으로 상용화되었으며, 1998년경 GPFS가 그 뒤를 이었다. 이전 파일 시스템과 새로운 파일 시스템의 주요 차이점은 GPFS가 Vesta/PIOFS에서 제공하는 특수화된 API를 표준 유닉스 API로 대체했다는 점이다. 고성능 병렬 I/O를 지원하는 모든 기능은 사용자에게 숨겨져 백그라운드에서 구현되었다. GPFS는 또한 관련 제품인 IBM 멀티미디어 서버(IBM Multi-Media Server) 및 IBM 비디오 충전기(IBM Video Charger)와 많은 구성 요소를 공유하며, 이 때문에 많은 GPFS 유틸리티가 접두사 mm—멀티미디어(multi-media)로 시작한다.:xi
동래읍성역사축제

[제3장 : 침 략] 전령으로부터 전해진 왜군침략소식
전령으로부터 전쟁소식이 들려온다
혼란에 빠진 백성들
나라를 지킬지 도망을 갈지에 대한 의견이 분분하다.

[제4장 : 맹 세] 나라를 지키기 위한 조건없는 맹세
송상현 부사는 나라를 지키는 이유에 대해 노래한다.
송상현 부사에게 동화된 백성들은 나라에 대한 조건없는 맹세를 다짐한다.

임진년, 첫 전투지 ‘부산진성’이 함락되었다는 소식을 전해들은 경상좌병사(현재의 육군 부대장) 이각(李珏)은 송상현(宋象賢) 동래부사에게 모든 것을 떠넘기고 성문을 열고 도망갔다. 그래서 동래읍성은 고립무원의 상태에서 적의 대군을 맞아 격전을 벌일 수 밖에 없었다.
Zswap
Section: 역사

zswap (zbud와 함께)은 2013년 9월 2일에 출시된 커널 버전 3.11에서 리눅스 커널 메인라인에 병합되었다.

2014년 6월 8일에 출시된 리눅스 커널 버전 3.15부터 zswap은 여러 스와프 장치를 제대로 지원한다.

zswap과 zbud는 모두 세스 제닝스(Seth Jennings)가 만들었다. 첫 공개 발표는 2012년 12월이었고, 개발은 2013년 5월까지 계속되어 코드베이스가 실험적 커널 기능 상태였음에도 불구하고 성숙 단계에 도달했다.
Zswap

I/O 감소의 결과로, zswap은 임베디드 장치, 넷북 및 유사한 저가형 하드웨어 장치를 포함한 다양한 플래시 메모리 기반 저장 장치를 사용하는 장치뿐만 아니라, SSD를 저장 장치로 사용하는 다른 장치에도 이점을 제공한다. 플래시 메모리는 쓰기 증폭으로 인해 수명이 제한적이므로, 이를 스와프 공간으로 사용하는 것을 피하면 빠르게 마모되는 것을 방지할 수 있다.

zswap은 가상 메모리 압축의 한 형태로, 스와프된 페이지를 위한 압축된 쓰기 저장(write-back) 캐시를 제공하는 리눅스 커널 기능이다. 메모리 페이지가 스와프 아웃될 때 스와프 장치로 이동하는 대신, zswap은 해당 페이지를 압축한 다음 시스템 RAM에 동적으로 할당된 메모리 풀에 저장한다. 실제 스와프 장치로의 쓰기 저장은 지연되거나 완전히 회피되어, 스와핑이 필요한 리눅스 시스템의 I/O를 크게 줄인다. 대신 압축을 수행하기 위해 추가적인 CPU 사이클이 필요하다.
Zswap
Section: 대안

이에 비해 zswap은 스와프 장치를 위한 RAM 기반 캐시 역할을 한다. 이는 zswap에 덜 사용된 스와프 페이지에 대한 캐시 축출 메커니즘을 제공하는데, zram은 커널 버전 4.14에서 CONFIG_ZRAM_WRITEBACK이 도입되기 전까지는 이 기능이 없었다. 하지만 설계상 zswap을 사용하려면 이미 존재하는 스와프 장치가 적어도 하나 필요하다.

zswap의 대안 중 하나는 zram으로, 리눅스 커널에 유사하지만 여전히 다른 "RAM에 압축된 페이지 스와프" 메커니즘을 제공한다.

주요 차이점은 zram이 데이터를 저장하기 위해 RAM을 사용하여 압축된 블록 장치를 제공한다는 점이다. 이는 일반적이고 별개의 스와프 장치 역할을 한다.
ISACA
Section: 인증

IT 감사 기초 자격증

IT 위험 기초 자격증

클라우드 감사 지식 자격증

사이버 보안 감사 자격증

컴퓨팅 기초 자격증

네트워크 및 인프라 기초 자격증

사이버 보안 기초 자격증

소프트웨어 개발 기초 자격증

데이터 과학 기초 자격증

클라우드 기초 자격증

블록체인 기초 자격증

IoT 기초 자격증

인공지능 기초 자격증

COBIT 설계 및 구현

COBIT 2019를 사용하여 NIST 사이버 보안 프레임워크 구현
Readahead

많은 리눅스 배포판은 일반적으로 사용되는 파일 목록에 readahead를 사용하여 부팅 속도를 높인다. 이러한 설정에서 커널이 profile 부트 파라미터로 부팅되면, 부팅 중 모든 파일 접근을 기록하고 나중 부팅 시퀀스에서 읽을 새 파일 목록을 작성한다. 이는 기본 readahead 목록에 포함되지 않은 추가 설치된 서비스가 더 빨리 시작되도록 할 것이다.

Systemd를 사용하는 리눅스 배포판에서는 (부팅 시퀀스의 일부로) readahead 바이너리가 systemd-readahead로 대체되었다. 그러나 systemd 버전 217에서 readahead 지원이 제거되었으며, 유지 관리되지 않고 예상 성능 이점을 제공할 수 없다고 설명되었다.
브레인 퍽 스케줄러
Section: MuQSS

사용자는 멀티코어 간에 실행 큐를 공유하거나 논리적 CPU당 하나의 실행 큐를 가질 수 있다.:ln 947–1006 실행 큐 공유 설계는 처리량과 맞바꾸어 지연 시간을 줄이려는 의도였다.:ln 947–1006

MuQSS가 도입한 새로운 동작은 타임슬라이스가 소진되어 태스크를 다시 스케줄링할 때 밀리초 미만의 정확도를 위한 고해상도 타이머 사용이었다.:ln 618–630, 3829–3851, 3854–3865, 5316
브레인 퍽 스케줄러
Section: 벤치마크

BFS를 포함한 ck1 패치셋이 적용된 커널은 테스트된 거의 모든 성능 기반 벤치마크에서 CFS를 사용하는 바닐라 커널보다 1%에서 8% 더 우수한 성능을 보였다. 더 큰 테스트셋으로 추가 연구를 수행할 수 있지만, 평가된 7개 PC의 소규모 테스트셋을 기반으로 볼 때, 이러한 프로세스 큐잉, 효율성/속도 증가는 전반적으로 CPU 유형(모노, 듀얼, 쿼드, 하이퍼스레드 등), CPU 아키텍처(32비트 및 64비트) 및 CPU 다중성(모노 또는 듀얼 소켓)과는 무관하다.

현대 연구에서 저자는 리눅스 커널 v3.6.2를 사용하여 BFS와 CFS를 여러 성능 기반 종점으로 비교했다. 이 연구의 목적은 바닐라 리눅스 커널의 컴플리틀리 페어 스케줄러(CFS)와 해당 커널에 ck1 패치셋이 적용된 BFS를 평가하는 것이었다. 7개의 다른 머신을 사용하여 성능 기반 지표를 사용하여 차이점이 존재하는지, 그리고 어느 정도까지 확장되는지 확인했다. 논리 CPU 수는 1개에서 16개까지 다양했다. 이러한 종점은 BFS의 주요 설계 목표에 포함되지 않았다. 결과는 고무적이었다.
브레인 퍽 스케줄러

"브레인 퍽 스케줄러"라는 이름은 의도적으로 도발적인데, 당시 기존 리눅스 프로세스 스케줄러의 복잡성에 대한 좌절감을 표현하기 위해 창시자 콘 콜리바스가 선택했다. 콜리바스는 컴플리틀리 페어 스케줄러 (CFS)와 같은 다른 스케줄러에서 튜닝 가능한 매개변수와 휴리스틱 기반 설계가 확산되면서 비전문가가 이해하거나 최적화하기 어렵다는 점을 강조하고자 했다. 이와 대조적으로 BFS는 사용자 수준의 구성 없이 데스크톱 상호작용성과 응답성 향상을 목표로 단순성과 예측 가능성을 염두에 두고 설계되었다.

BFS의 목표는 다른 스케줄러와 비교하여, 특정 유형의 컴퓨테이션 작업 부하에 대한 성능을 맞추기 위해 휴리스틱 이론 조정이나 매개변수 튜닝이 필요 없는 더 간단한 알고리즘을 가진 스케줄러를 제공하는 것이다. 콜리바스는 이러한 튜닝 매개변수가 일반 사용자가 이해하기 어렵다고 주장했으며, 특히 여러 매개변수 간의 상호작용 측면에서 더욱 그러하다고 했다. 또한 이러한 튜닝 매개변수를 사용하면 특정 대상 컴퓨테이션 유형에서 성능이 향상될 수 있지만, 일반적인 경우에는 성능이 저하될 수 있다고 주장했다. BFS는 16개 미만의 CPU 코어를 가진 리눅스 데스크톱 컴퓨터에서 응답성을 향상시키는 것으로 보고되었다.
메타데이터 (CLI)
Section: 특성

개발자는 특성을 통해 코드에 메타데이터를 추가할 수 있다. 특성에는 사용자 지정 특성과 의사 사용자 지정 특성의 두 가지 유형이 있으며, 개발자에게는 동일한 구문을 가진다. 코드의 특성은 컴파일러에게 메타데이터를 생성하라는 메시지이다. CIL에서는 상속 수정자, 범위 수정자 및 opcode 또는 스트림이 아닌 거의 모든 메타데이터도 특성으로 참조된다.

사용자 지정 특성은 System.Attribute 클래스를 상속하는 일반 클래스이다. 사용자 지정 특성은 다음 구문을 사용하여 모든 메서드, 속성, 클래스 또는 전체 어셈블리에서 사용할 수 있다: [AttributeName(optional parameter, optional name=value pairs)] 예시는 다음과 같다.
메타데이터 (CLI)

CLI 언어 컴파일러는 메타데이터를 생성하고 이를 CIL을 포함하는 어셈블리에 저장한다. 런타임이 CIL을 실행할 때 호출된 메서드의 메타데이터가 호출하는 메서드에 저장된 메타데이터와 동일한지 확인한다. 이를 통해 메서드는 정확히 올바른 수의 매개변수와 정확히 올바른 매개변수 유형으로만 호출될 수 있다.

윈도우 8 및 윈도우 폰 8에 있는 윈도우 런타임 애플리케이션 플랫폼은 CLI 메타데이터 형식을 사용하여 지원되는 프로그래밍 언어로 작성된 코드에 대한 컴포넌트 인터페이스를 설명한다. 공통 언어 런타임 내에서의 사용 차이점은 어셈블리가 일반적으로 CIL 명령을 포함하지 않는다는 것이다.
마이크로소프트 컴파일 HTML 도움말
Section: 파일 형식

CHM 파일은 다음 기능을 지원한다.

데이터 압축 (LZX 사용)

내장 검색 엔진

여러 .chm 도움말 파일 병합 기능

유니코드를 완전히 지원하지는 않지만 확장 문자 지원.

파일은 마이크로소프트가 CHM 파일에 사용되는 일반 저장 파일 형식에 부여한 내부 이름인 "Info-Tech Storage Format"의 "ITSF" (in ASCII) 바이트로 시작한다.
플로우 샵 스케줄링
Section: 해결 방법

플로우 샵에는 시간 0에 동시에 사용 가능하며 그 사이에 무제한 저장 공간을 가진 직렬로 배열된 두 대의 기계에 의해 처리될 n개의 작업이 포함된다. 모든 작업의 처리 시간은 확실히 알려져 있다. 메이크스팬을 최소화하기 위해 기계에 n개의 작업을 스케줄링해야 한다. 두 기계 플로우 샵에서 작업을 스케줄링하기 위한 존슨의 규칙은 다음과 같다.

최적 스케줄에서, min{p1i,p2j} < min{p1j,p2i}인 경우 작업 i가 작업 j보다 먼저 온다. 여기서 p1i는 기계 1에서 작업 i의 처리 시간이고 p2i는 기계 2에서 작업 i의 처리 시간이다. 유사하게, p1j와 p2j는 각각 기계 1과 기계 2에서 작업 j의 처리 시간이다.
플로우 샵 스케줄링
Section: 정의

하나의 작업 내의 작업은 지정된 순서대로 수행되어야 한다. 첫 번째 작업은 첫 번째 기계에서 실행되고, (첫 번째 작업이 완료되면) 두 번째 작업은 두 번째 기계에서 실행되며, m번째 작업까지 계속된다. 그러나 작업은 어떤 순서로든 실행될 수 있다. 문제는 가능한 가장 짧은 총 작업 실행 메이크스팬을 가진 최적의 배열을 결정하는 것이다.

m개의 기계와 n개의 작업이 있다. 각 작업은 정확히 m개의 작업을 포함한다. 작업의 i번째 작업은 i번째 기계에서 실행되어야 한다. 어떤 기계도 동시에 두 개 이상의 작업을 수행할 수 없다. 각 작업의 각 작업에 대해 실행 시간이 지정된다.
플로우 샵 스케줄링

최적 작업 스케줄링 문제에 대한 표준 3필드 표기법에서 플로우 샵 변형은 첫 번째 필드에 F로 표시된다. 예를 들어, "F3||"로 표시되는 문제는 단위 처리 시간을 가진 3기계 플로우 샵 문제이며, 목표는 최대 완료 시간을 최소화하는 것이다.

플로우 샵 스케줄링은 모든 작업에 대해 수행될 모든 작업의 엄격한 순서가 있는 잡 샵 스케줄링의 특수 사례이다. 플로우 샵 스케줄링은 제조업 시설뿐만 아니라 컴퓨팅 설계에도 적용될 수 있다. 플로우 샵 스케줄링 문제의 특별한 유형은 순열 플로우 샵 스케줄링 문제인데, 이는 리소스에서 작업의 처리 순서가 후속 처리 단계마다 동일한 경우이다.
Meson
Section: 속도 및 정확성

일반적인 빌드 시스템과 마찬가지로 올바른 증분 빌드는 가장 중요한 속도 기능이다(사용자가 강제로 클린 빌드를 수행해야 할 때 모든 증분 진행이 폐기되기 때문이다).

일반 Make와 달리 별도의 구성 단계는 인수, 환경 변수 및 명령 출력의 변경 사항이 후속 빌드에서 부분적으로 적용되지 않도록 하여 오래된 빌드로 이어지지 않도록 한다.

Ninja와 마찬가지로 Meson은 소스 파일의 글로빙을 지원하지 않는다. 모든 소스 파일이 빌드 정의 파일에 나열되어야 하므로, 빌드 정의 파일 타임스탬프는 소스 파일 집합이 변경되었는지 여부를 결정하는 데 충분하므로 제거된 소스 파일이 감지된다. CMake는 글로빙을 지원하지만 동일한 이유로 권장하지 않는다.
Meson
Section: 채택자

그놈은 프로젝트를 Meson으로 포팅하는 것을 목표로 삼았다. 2017년 후반부터 그놈 셸 자체는 오토툴을 포기한 후 Meson만을 독점적으로 요구하며, GTK+, Clutter-GTK, GLib 및 GStreamer와 같은 중앙 구성 요소도 Meson으로 빌드할 수 있다.

많은 Freedesktop.org 프로젝트가 Meson으로 전환되었다. Systemd는 버전 234에서 오토툴을 버린 이후 Meson에 의존하며, X.Org 및 메사도 Meson으로 포팅되었다.
Meson
Section: 기능

Meson은 Meson 및 CMake 하위 프로젝트를 지원한다. Meson 빌드 파일은 WrapDB 서비스를 참조할 수도 있다.

교차 컴파일은 추가 구성이 필요하며, Meson은 Meson 프로젝트 외부에서도 가능한 별도의 교차 파일 형태로 이를 지원한다.

Meson의 목표는 현대적인 개발 방식을 용이하게 하는 것이다. 따라서 Meson은 유니티 빌드를 수행하고, 코드 커버리지를 통해 빌드하는 방법 등을 프로그래머가 이를 지원하기 위해 코드를 작성할 필요 없이 수행하는 방법을 알고 있다.
그래피티 (팜 OS)

이 소프트웨어는 주로 터치 감지 패널에 스타일러스로 보지 않고 그릴 수 있는 대문자 신조어를 기반으로 한다. 사용자가 문자를 그리는 동안 일반적으로 문자를 볼 수 없기 때문에 가장 어려운 네 글자에서 복잡성이 제거되었다. "A", "F", "K", "T"는 모두 가로획을 맞출 필요 없이 그려진다.

일부 문자는 "공식적인" 획이 아닌 다른 획으로 그릴 수 있다. 이러한 대체 획의 두 가지 예는 "V" (오른쪽에서 왼쪽으로만 똑같이 그림)와 "X" (문자 "K"와 똑같이 그림, 단 오른쪽에서 왼쪽으로 반전됨)이다. 이러한 대체 획은 더 높은 신뢰성으로 인식되는 경우가 많다.
그래피티 (팜 OS)
Section: 역사

2003년, 제록스 소송의 결과로 팜은 자연 필기와 다소 유사한 제스처를 사용하는 Graffiti 2를 출시했다. 그래피티 2는 윈도우 CE 및 기타 임베디드 플랫폼에서도 문자 인식을 제공했던 Communication Intelligence Corporation의 Jot 기술을 기반으로 했다.

호킨스는 또한 서로 겹쳐서 글자를 쓸 수 있는 단일 영역을 구상했다.

호킨스는 이 시스템을 "PowerPalmPrint" 또는 P3라고 불렀다. 팜의 다른 엔지니어들은 호킨스가 만든 알파벳을 수정하고 확장했다. 조 시퍼와 론 마리아네티는 더 많은 문자와 구두점을 만들었으며, 태블릿 주변 장치가 있는 PC에서 실행되는 그래피티 프로토타입도 설계했다.
전자기기 제조 서비스
Section: 시장 부문

전자 제품 제조 서비스(EMS)의 글로벌 시장은 2023년에 5,042억 달러로 추정되었으며, 2024년부터 2030년까지 예측 기간 동안 연평균 성장률(CAGR) 4.94%로 성장하여 2030년에는 7,075억 달러로 수정된 규모에 도달할 것으로 예상된다.
EMS 산업은 일반적으로 수익에 따라 티어로 나뉜다.

티어 1: 50억 달러 이상

티어 2: 5억 달러 ~ 50억 달러

티어 3: 1억 달러 ~ 5억 달러

티어 4: 1억 달러 미만

현재 실제 수익 지정에 대한 엄격한 규칙은 없다.
StepBeyond/EMSinsider와 CIRCUITS ASSEMBLY에서 제안한 다른 범주로는 마이크로 티어(5천만 달러 미만); 티어 4 1천만 달러 미만과 빅 2인 폭스콘과 플렉스를 지칭하는 "티어 메가"가 있다.
전자기기 제조 서비스

전자기기 제조 서비스(Electronics manufacturing services, EMS)는 원천 장비 제조업체(OEM)를 위해 전자 부품 및 어셈블리를 설계, 제조, 테스트, 유통하고 반품/수리 서비스를 제공하는 기업에 사용되는 용어이다. 이 개념은 전자기기 위탁 제조(electronics contract manufacturing, ECM)라고도 불린다.

많은 대량 컨슈머 일렉트로닉스 제품은 미국과 달리 해당 지역에서 대량 저비용 전자 제품을 빠르게 제조할 수 있기 때문에 중국과 동남아시아 국가에서 생산되었다. 선전시, 페낭주와 같은 도시들은 애플과 같은 많은 컨슈머 일렉트로닉스 회사를 유치하면서 이 산업의 중요한 생산 중심지가 되었다. 플렉스 및 위스트론과 같은 일부 회사는 원천 디자인 제조업자이자 전자 제품 제조 서비스 제공업체이다.
덫치기
Section: 논란

덫치기는 시간, 노고, 돈이 필요하지만 효율적일 수 있다. 덫치기는 덫 사냥꾼에게는 비용이 많이 들고, 현대에는 논란이 되고 있다. 이러한 우려를 해결하기 위해 1996년 미국 주 및 연방 어류 및 야생동물 기관 전문가들로 구성된 어류 및 야생동물 기관 협회는 덫을 테스트하고 "과학적 연구를 통해 덫치기 기술을 개선하고 현대화하기 위한" 권장 사항인 최적 관리 관행을 수집하기 시작했다. 2013년 2월 현재, 북미 전역의 19종의 일반적인 모피 동물을 다루는 20가지 최적 관리 관행 권장 사항이 발표되었다.

덫치기는 덫의 종류에 따라 동물에게 스트레스, 고통 또는 죽음을 초래할 수 있다. 사지를 잡는 덫은 특히 부적절하게 사용되어 덫 사냥꾼이 올 때까지 동물을 방치하면 사지에 부상을 입힐 수 있다. 동물은 부상, 굶주림 또는 다른 동물들의 공격으로 죽을 수도 있다. 많은 주에서는 동물의 위험을 최소화하기 위해 덫을 최소 36시간마다 확인해야 한다는 규정을 시행하고 있다.
덫치기
Section: 유형

끈끈이 덫에 우연히 잡힌 반려동물은 접촉 부위에 식용유나 베이비 오일을 조심스럽게 바르고 동물이 풀려날 때까지 부드럽게 작업하여 풀어줄 수 있다. 미국인도주의협회와 동물방어동맹과 같은 많은 동물 권리 단체는 동물을 잔인하게 대하는 끈끈이 덫 사용에 반대한다.

끈끈이 덫은 영국에서 처음으로 웨일스에서 2023년 10월에 불법화되었다. 2024년 1월에는 캘리포니아주 웨스트 할리우드에서 설치류 끈끈이 덫의 판매 및 사용이 금지되어 미국에서 최초의 도시 금지 조치가 되었다. 끈끈이 덫은 또한 호주의 오스트레일리아 수도 준주, 태즈메이니아주, 빅토리아주에서도 금지되어 있다.
덫치기
Section: 원치 않는 포획

덫 사냥꾼들은 원치 않는 포획을 피하기 위해 다양한 장치와 전략을 사용할 수 있다. 이상적으로는 비대상 동물(가정 고양이 또는 개 등)이 비살상 덫에 걸리면 해를 입히지 않고 풀어줄 수 있다. 설치 및 유인 장치의 신중한 선택은 비대상 동물을 피하면서 대상 동물을 잡는 데 도움이 될 수 있다. 덫 사냥꾼이 원치 않는 동물이 잡히지 않도록 항상 보장할 수는 없지만, 원치 않는 포획을 피하거나 해를 입히지 않고 풀어줄 수 있도록 예방 조치를 취할 수 있다.

올가미에 비대상 동물이 잡히는 것을 최소화하기 위해 대상 동물보다 크거나 작은 동물을 제외하는 방법을 사용할 수 있다. 예를 들어, 사슴 정지 장치는 사슴이나 소가 다리에 걸리는 것을 방지하도록 설계되었으며, 미국 일부 지역에서는 필수이다. 다른 예방 조치로는 올가미를 특정 높이, 직경 및 위치에 설정하는 것이 있다. 영국에서 여우를 연구하는 동안 연구원들은 방법을 개선하기 전까지 의도치 않게 갈색 토끼를 목표 여우만큼 자주 올가미로 잡았는데, 토끼 정지 장치가 있는 더 큰 철사를 사용하여 갈색 토끼의 원치 않는 포획을 제거했다.
계기 장비
Section: 응용

계기 장비 시스템의 매우 간단한 예는 가정용 화로를 제어하고 실내 온도를 제어하는 데 사용되는 기계식 온도조절기이다. 일반적인 장치는 바이메탈 스트립으로 온도를 감지한다. 스트립의 자유단에 있는 바늘로 온도를 표시한다. 수은 스위치로 화로를 작동시킨다. 스위치가 스트립에 의해 회전하면 수은이 전극 사이에 물리적(따라서 전기적) 접촉을 만든다.

계기 장비 시스템의 또 다른 예는 가정용 보안 시스템이다. 이러한 시스템은
센서(움직임 감지, 문 열림 감지 스위치), 침입 감지를 위한 간단한 알고리즘, 로컬 제어(설정/해제) 및 경찰을 호출할 수 있도록 시스템 원격 모니터링으로 구성된다. 통신은 설계의 필수적인 부분이다.
계기 장비
Section: 현대 개발의 영향

데이비스 베어드는 제2차 세계 대전 이후 플로리스 코헨'이 "네 번째 큰 과학 혁명"으로 확인한 주요 변화가 화학뿐만 아니라 과학 전반에 걸친 과학 계측의 발전이라고 주장했다. 화학 분야에서 1940년대에 새로운 계측의 도입은 "과학 기술 혁명 그 자체"였다:28–29 이는 구조 유기 화학의 고전적인 습식 및 건식 방법이 폐기되고 새로운 연구 분야가 개척되었음을 의미한다.:38

1954년에 이미 W. A. 와일드핵은 공정 제어에 내재된 생산적 잠재력과 파괴적 잠재력 모두에 대해 논의했다.
과학 계측을 사용하여 이전에 관찰할 수 없었던 수준에서 자연 세계를 정밀하고 검증 가능하며 재현 가능한 측정을 할 수 있는 능력은 "세상의 다른 질감을 제공했다". 이 계측 혁명은 DDT 모니터링과 자외선 가시광선 분광법 및 기체 크로마토그래피를 사용하여 수질 오염 물질을 모니터링하는 예에서 알 수 있듯이 인간의 모니터링 및 대응 능력을 근본적으로 변화시킨다.
계기 장비
Section: 역사

계기 장비의 역사는 여러 단계로 나눌 수 있다.

산업 계기 장비의 요소들은 오랜 역사를 가지고 있다. 무게를 비교하는 저울과 위치를 나타내는 간단한 지시기는 고대 기술이다. 가장 초기의 측정 중 일부는 시간 측정이었다. 가장 오래된 물시계 중 하나는 기원전 1500년경에 매장된 고대 이집트의 파라오 아멘호테프 1세의 무덤에서 발견되었다. 시계에는 개선 사항이 통합되었다. 기원전 270년경에는 자동 제어 시스템 장치의 기본을 갖추고 있었다.

1663년 크리스토퍼 렌은 왕립 학회에 "날씨 시계" 디자인을 발표했다. 그림은 시계 장치로 구동되는 종이 위로 펜을 움직이는 기상 센서를 보여준다. 이러한 장치는 2세기 동안 기상학에서 표준이 되지 못했다. 압력 벨로스가 펜을 변위시키는 공압식 차트 기록계에서 볼 수 있듯이 이 개념은 거의 변하지 않았다. 산업 혁명 전에는 센서, 디스플레이, 기록계 및 제어 장치를 통합하는 것이 필요와 실용성 모두에서 제한되어 일반적이지 않았다.
배란일 계산기
Section: 관련 도구

배란일 계산기와 함께 제공되는 여성 건강 관련 도구들은 다음과 같다.

생리 주기 캘린더

난포호르몬(배란테스트기) 예측 도구

임신 가능성 계산기

기초체온 기록기

수유량·임신 관련 육아 계산기

사용자가 제공한 URL(https://babyg.co.kr/pages/ovulation.html)은 대표적인 배란일 계산기 페이지이다.  해당 사이트는 배란 주기 설명, 가임기 계산, 주의사항 등을 함께 안내한다.
C와 C++의 호환성

그러나 C는 C++의 부분집합이 아니며, 사소하지 않은 C 프로그램은 수정 없이 C++ 코드로 컴파일되지 않는다. 마찬가지로 C++는 C에서 사용할 수 없는 많은 기능을 도입하며, 실제로 C++로 작성된 거의 모든 코드는 C 코드에 적합하지 않다. 그러나 이 문서에서는 C 코드에 적합한 것이 C++ 코드에서는 잘못된 형식으로 간주되거나, 두 언어 모두에서 적합/잘못된 형식으로 간주되지만 C와 C++에서 다르게 동작하는 차이점에 초점을 맞춘다.

C++의 창시자인 비야네 스트롭스트룹은 두 언어 간의 상호 운용성을 극대화하기 위해 C와 C++ 간의 비호환성을 가능한 한 줄여야 한다고 제안했다. 다른 이들은 C와 C++가 서로 다른 언어이므로 호환성은 유용하지만 필수적인 것은 아니라고 주장한다. 이들은 비호환성을 줄이려는 노력이 각 언어를 독립적으로 개선하려는 시도를 방해해서는 안 된다고 말한다. 1999년 C 표준 (C99)의 공식 근거는 C와 C++ 간의 "가장 큰 공통 부분집합을 유지하는 원칙을 지지[했고]" "동시에 둘 사이의 구분을 유지하고 개별적으로 발전할 수 있도록 허용한다"고 명시하며, 저자들은 "C++가 크고 야심 찬 언어가 되도록 만족한다"고 밝혔다.
C와 C++의 호환성
Section: C와 C++에서 다르게 동작하는 구성 요소

C++에는 단일 UTF 코드 단위를 인코딩하는 char8_t, char16_t, char32_t 타입이 있다. C23에는 이들이 포함되지만, 별개의 내장 타입이 아닌 다른 정수 타입에 대한 typedef로 포함되어 있어 해당 이름이 예약 키워드가 아니다.

C에서는 int 타입의 비트 필드가 부호 있는 것인지 부호 없는 것인지는 구현 정의이지만, C++에서는 기본 타입과 일치하도록 항상 부호 있는 타입이다.

이전 섹션의 다른 몇 가지 차이점도 두 언어 모두에서 컴파일되지만 다르게 동작하는 코드를 생성하는 데 활용될 수 있다. 예를 들어, 다음 함수는 C와 C++에서 다른 값을 반환할 것이다.
C와 C++의 호환성
Section: C 및 C++ 코드 연결

컴파일러 및 아키텍처에 따라 두 언어 간에 호출 규약이 다를 수도 있다.

이러한 이유로 C++ 코드가 C 함수 foo()를 호출하려면 C++ 코드는 extern "C"로 foo()를 프로토타입해야 한다. 마찬가지로 C 코드가 C++ 함수 bar()를 호출하려면 bar()에 대한 C++ 코드는 extern "C"로 선언되어야 한다.

헤더 파일이 C와 C++ 호환성을 모두 유지하는 일반적인 관행은 헤더 범위에 대해 선언을 extern "C"로 만드는 것이다.

foo.h에서

C와 C++ 연결 및 호출 규약의 차이점은 함수 포인터를 사용하는 코드에 미묘한 영향을 미칠 수도 있다. 일부 컴파일러는 extern "C"로 선언된 함수 포인터가 extern "C"로 선언되지 않은 C++ 함수를 가리키면 작동하지 않는 코드를 생성한다.
신생아 예방접종
Section: 주요 예방접종

출생 직후 24시간 이내 접종이 권장된다.

HBV 감염으로부터 영유아를 보호하며, B형간염 보균 산모의 경우 항체 형성을 위한 추가 면역글로불린(HBIG) 투여가 시행될 수 있다.

기본 접종 일정: 출생 → 1개월 → 6개월.

생후 4주 이내 접종 권장.

유아기 결핵, 특히 중증 결핵(결핵수막염, 파종성 결핵) 예방 효과가 크다.

피내용(도장형) 또는 경피용 방식이 국가별로 다르게 사용된다.
신생아 예방접종
Section: 관련 도구

신생아 예방접종과 함께 사용되는 육아·건강 도구로는 다음이 있다.

예방접종 일정표·캘린더

발달 단계 체크리스트

영유아 건강검진 일정 안내

육아·모유수유 계산기

배란일·생리주기 계산기

사용자가 제공한 URL(https://babyg.co.kr/pages/vaccination.html)은 신생아·영유아 예방접종 정보를 제공하는 페이지로, 기본 접종표와 설명을 포함한다.
전주 김장문화축제
Section: 주최

전라북도 전주시

전주푸드통합지원센터

2019년 11월 16 제 1회 전주김장문화축제 개최

2020년 11월 21일~11월 22일 제 2회 전주김장문화축제 개최

2021년 11월 2일~11월 30일 제 3회 전주김장문화축제 개최

2022년 11월 8일~11월 10일 제 4회 전주김장문화축제 개최

2023년 11월 24일~11월 25 제 5회 전주김장문화축제 개최

2024년 11월 22일~11월 24일 제 6회 전주김장문화축제 개최
쿠알라룸푸르 시티 센터
Section: 사무실

공식 명칭은 메나라 3 페트로나스이며, 이 타워는 2012년에 완공된 60층 타워이다. 이 타워는 쇼핑몰 수리아 KL과 연결되어 있다.

이 타워 역시 시저 펠리가 설계했으며, 2006년에 공사가 시작되어 2012년에 완공되었다. 이 타워는 만다린 오리엔탈 호텔을 향한 별도의 입구를 가지고 있으며, D1 필지로 이어지는 터널 링크도 있다. D1 필지는 소유주인 KLCC 프로퍼티의 미래 개발 부지가 될 것이다. 페트로나스 트윈 타워와 마찬가지로 건물 서비스 엔지니어는 플랙 + 커츠였다.

엑슨모빌 타워는 1997년 1월 1일에 완공되었으며, 세계에서 가장 큰 상장 기업 중 하나인 엑슨모빌 말레이시아 자회사의 본사이다.

126m (413피트) 높이의 30층 타워는 거의 기둥 없는 내부를 가진 직사각형 건물이다. 미적 측면에서 북쪽과 남쪽 입면은 5층에서 뒤로 물러나 있으며, 공원을 향하는 북쪽 입면은 22층과 26층에서 더 뒤로 물러나 있다.
쿠알라룸푸르 시티 센터
Section: 호텔

포시즌스 호텔 앤 리조트가 관리하는 포시즌스 플레이스 쿠알라룸푸르는 KLCC 인근에 위치해 있다.

그랜드 하얏트 쿠알라룸푸르는 컨벤션 센터 바로 옆 잘란 피낭을 마주보고 있다.

더 루마 레지던스는 KLCC 공원과 파빌리온 쇼핑몰에서 도보 거리에 있다.

현재 KLCC 지역에는 4개의 호텔이 있다:

만다린 오리엔탈은 수리아 KLCC와 쿠알라룸푸르 컨벤션 센터 사이에 위치한 주요 호텔이다.

페트로나스가 소유하고 샹그릴라 호텔이 운영하는 트레이더스 호텔은 컨벤션 센터와 직접 연결된다. 이 호텔은 571개의 객실을 보유하고 있다.
쿠알라룸푸르 시티 센터
Section: 접근성

쿠폰 시스템을 사용하는 전용 택시 승강장은 쇼핑몰 입구에 마련되어 있다. 시스템을 사용하지 않으려는 승객은 주요 도로에 위치한 다른 택시 승강장으로 걸어갈 수 있다.

이 지역은 5개의 주요 도로로 둘러싸여 있지만, 주요 도로 접근은 잘란 암팡, 잘란 술탄 이스마일 및 암팡-쿠알라룸푸르 고가도로 (AKLEH)를 통해 이루어진다. AKLEH 접근은 고속도로가 이 지역의 광범위한 지하 주차장으로 직접 터널 접근을 제공한다는 점에서 매우 독특하다.

KLCC는 지하 터널을 통해 잘란 암팡과도 연결된다.

개발자 (페트로나스)는 사회 공헌 프로그램의 일환으로 쿠알라룸푸르 컨벤션 센터에서 부킷빈탕 쇼핑 지구까지 고가 냉난방 보행자 통로를 건설하는 데 1억 링깃 (USD23 백만)을 지출했다. 그곳에서 보행자들은 KL 모노레일 노선의 부킷빈탕 및 라자 출란 역과 카장 선의 부킷빈탕 MRT 역에 접근할 수 있다.
배관 및 계장도
Section: 내용 및 기능

제어 및 종료 체계

안전 및 규제 요구 사항

시동 순서

운영 이해.

P&ID는 SCADA 및 분산 제어 시스템과 같은 대규모 산업 제어 시스템의 그래픽 사용자 인터페이스에 표시되는 라이브 모방 다이어그램의 기초를 형성한다.

P&ID는 초기 구축 후 공정의 유지보수 및 수정에도 중요한 역할을 한다. 수정 사항은 도면에 빨간색으로 표시되며 현재 플랜트 설계의 중요한 기록이 된다.

또한 다음의 개발에 필수적이다.
전주국제단편영화제
Section: 개막작

제1회 리멤버 Remember (이가령), 리메인 Remain (조미혜)

제2회 미수금 Video Mail (유훈영), 어느날 대박 What a big surprise (이가령), 쪽지 (최현지), 공 Zero (김해리), 아버지가방에들어가신다! Daddy in the Bag (이민섭)

제3회 와이파이 Wifi (김창현), 데드라인 Deadline (최병천), 무서워서 크게 부르는 노래 Ode to Misfit (조현진)

제4회 E14 (페이멘 제카밧), 사는게먼지 Dust Safe Guard (민현기), 마지막 한 번 One Last Time (어네스트 로우)
전주국제단편영화제

그리고 2021년, 전주단편영화제는 국내뿐만 아니라 국제단편영화도 상영하기로 결정하고 명칭을 ‘전주국제단편영화제’로 변경하게 되었다.

전주국제단편영화제는 영화 관람 후 많은 관객들과 대화를 통해 공감과 소통을 지향하며, 전주국제단편영화제를 통해 지역 문화의 발전과 가치 확산 및 미래지향적 예술 생태계 구축 그리고 지역 주민의 문화 예술 향유 증대를 위해 진행되고 있다.

전주국제단편영화제는 2018년 12월 7일 전주단편영화제로부터 시작 되었다.

2018년, 전주단편영화제는 단편영화에 대한 관심이 급증하고 있는 가운데 상대적으로 상영할 기회나 일반인들에게 소개될 기회가 적은 지역의 영화감독들이나 영화인들이 성장할 기회가 적어 전주단편영화제를 기획하게 되었다.
전주국제단편영화제
Section: 연혁

제 4회 2021.09.30 (목) ~ 2021.10.04 (월) 전주시네마타운

제 5회 2022.09.29 (목) ~ 2022.10.03 (월) 전주시네마타운

제 6회 2023.09.21 (목) ~ 2023.09.25 (월) 전주조이앤시네마

제 1회 2020.12.07 (금) ~ 2020.12.08 (토) 전주시네마타운 7관

제 2회 2020.12.12 (목) ~ 2020.12.14 (토) 전주시네마타운 8관

제 3회 2020.12.17 (목) ~ 2020.12.19 (토) 전주시네마타운