shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
각 태스크에는 prio라는 특별한 값이 있다. v0.462 버전(ck 4.0 커널 패치셋에서 사용됨)에서는 총 103개의 "우선순위 큐"(또는 prio) 또는 허용되는 값이 존재한다. 실제 특별한 자료 구조는 우선순위 큐로 사용되지 않았고, 이중 연결 리스트 실행 큐 자체만 사용되었다. prio 값이 낮을수록 중요도가 높고 먼저 실행된다.
실시간 정책.
실시간 정책은 실시간 태스크를 위해 설계되었다. 이 정책은 실행 중인 태스크가 하위 prio 태스크 또는 하위 우선순위 정책 계층에 의해 중단(즉, 선점)될 수 없음을 의미한다. 스케줄러가 실시간 정책 하에서 고려하는 우선순위 클래스는 SCHED_RR 및 SCHED_FIFO로 표시된 태스크이다. 스케줄러는 실시간 라운드 로빈(SCHED_RR)과 실시간 FIFO(SCHED_FIFO)를 다르게 처리한다.
설계는 처음 100개의 정적 우선순위 큐를 설정했다.
실행을 위해 선택될 태스크는 100개 큐 중 가장 낮은 prio 값의 태스크 가용성과 FIFO 스케줄링을 기반으로 한다.
포크 시, 프로세스 우선순위는 일반 정책으로 강등된다.
실시간 정책 클래스에 대한 요청과 함께 sched_setscheduler가 비특권 사용자(즉, 비루트 사용자)에 의해 호출될 경우, 스케줄러는 태스크를 등시성 정책으로 강등한다.
등시성 정책.
등시성 정책은 루트가 아닌 사용자를 위한 거의 실시간 성능을 위해 설계되었다.
이 설계는 기본적으로 의사 실시간 태스크로 실행되지만, 실시간 수준으로 튜닝될 수 있는 하나의 우선순위 큐를 설정했다.
이 정책의 동작은 태스크가 온라인 CPU 수와 타이머 해상도에 5초를 스케일링한 값에 1틱을 더한 튜닝 가능한 리소스 처리 비율(기본값 70%)을 초과할 경우 일반 정책으로 강등될 수 있다. 다중 실행 큐 설계로 인해 MuQSS에서 공식이 변경되었다. 정확한 공식은 다음과 같다.
여기서 는 등시성 틱의 총 수, 는 타이머 주파수, 은 온라인 CPU의 수, 은 소수점 대신 정수로 된 튜닝 가능한 리소스 처리 비율이다. 타이머 주파수는 기본적으로 250으로 설정되어 커널에서 편집 가능하지만, 일반적으로 서버의 경우 100Hz, 대화형 데스크톱의 경우 1000Hz로 튜닝된다. 250이 균형 잡힌 값이다. 을 100으로 설정하면 태스크가 실시간처럼 작동하고 0으로 설정하면 의사 실시간이 아니게 되며, 중간 값은 의사 실시간이다.
가장 빠른 가상 마감일을 가진 태스크가 실행을 위해 선택되지만, 여러 등시성 태스크가 존재할 경우, nice 수준을 고려하지 않고 라운드 로빈 방식으로 태스크를 스케줄링하여 튜닝 가능한 라운드 로빈 값(기본값 6ms)으로 태스크가 공정하게 차례로 실행될 수 있도록 한다.
등시성 정책의 이러한 동작은 BFS 및 MuQSS에만 고유하며 다른 CPU 스케줄러에는 구현되지 않을 수 있다.
일반 정책.
일반 정책은 일반적인 사용을 위해 설계되었으며 기본 정책이다. 새로 생성된 태스크는 일반적으로 일반으로 표시된다.
이 설계는 하나의 우선순위 큐를 설정했으며, 가장 빠른 가상 마감일에 따라 태스크가 먼저 실행되도록 선택된다.
유휴 우선순위 정책.
유휴 우선순위는 분산 프로그램 및 트랜스코더와 같은 백그라운드 프로세스를 위해 설계되었으므로 포그라운드 프로세스 또는 이 스케줄링 정책 위에 있는 프로세스는 중단 없이 실행될 수 있다.
이 설계는 1개의 우선순위 큐를 설정했으며, 태스크는 무한한 리소스 점유를 방지하기 위해 자동으로 일반 정책으로 승격될 수 있다.
동일한 우선순위 정책에 있는 다른 유휴 우선순위 태스크 중 다음에 실행될 태스크는 가장 빠른 가상 마감일에 따라 선택된다.
선점은 더 높은 우선순위 정책(즉, 더 높은 prio)을 가진 새로 준비된 태스크가 현재 실행 중인 태스크보다 더 빠른 가상 마감일을 가질 때 발생할 수 있으며, 이 경우 현재 실행 중인 태스크는 스케줄링 해제되어 큐의 맨 뒤로 이동된다. 스케줄링 해제는 가상 마감일이 업데이트되었음을 의미한다. 태스크가 모든 시간을 사용했을 때, 태스크의 시간은 최대 라운드 로빈 퀀텀으로 다시 채워진다. 스케줄러가 가장 빠른 가상 마감일을 가진 더 높은 prio의 태스크를 발견하면, 모든 논리적 CPU(하이퍼스레드 코어/SMT 스레드 포함)가 바쁜 경우에만 중요도가 낮은 현재 실행 중인 태스크 대신 실행된다. 스케줄러는 사용되지 않는 논리적 CPU가 있다면 가능한 한 오래 선점을 지연한다.
태스크가 유휴 우선순위 정책으로 표시된 경우, 다른 유휴 정책으로 표시된 태스크라도 전혀 선점할 수 없으며 협력적 멀티태스킹을 사용한다.
태스크 배치, 다중 코어.
스케줄러가 비유니코어 시스템에서 깨어나는 태스크를 발견하면, 해당 태스크를 실행할 논리적 CPU를 결정해야 한다. 스케줄러는 태스크가 실행된 동일한 CPU에서 유휴 하이퍼스레드 코어(또는 유휴 SMT 스레드)를 가장 선호하고, 그 다음은 멀티코어 CPU의 다른 유휴 코어, 그 다음은 동일한 NUMA 노드의 다른 CPU, 그 다음은 동일한 NUMA 노드에서 선점될 모든 바쁜 하이퍼스레드 코어/SMT 스레드/논리적 CPU, 그 다음은 다른 (원격) NUMA 노드를 선호하며, 이는 선호 목록에 따라 순위가 매겨진다. 이 특별한 스캔은 태스크 마이그레이션으로 인한 지연 시간 오버헤드를 최소화하기 위해 존재한다.
선점 순서는 위 문단과 유사하다. 선점 순서는 동일한 멀티코어 내 하이퍼스레드 코어/SMT 단위가 먼저이고, 그 다음은 멀티코어 내 다른 코어, 그 다음은 동일한 NUMA 노드 내 다른 CPU이다. 다른 원격 NUMA 노드에서 선점할 태스크를 스캔할 때, 선점은 해당 머신의 모든 논리적 CPU(하이퍼스레드 코어/SMT 스레드 포함)가 모두 바쁘다고 가정할 때, 낮은 prio 또는 동일한 prio 또는 나중 가상 마감일을 가진 바쁜 스레드에 대해 이루어진다. 스케줄러는 선점할 낮은 우선순위 또는 동일한 우선순위 정책 태스크(필요한 경우 나중 가상 마감일을 가진)를 스캔하고, 선점할 수 없는 더 높은 우선순위 정책 태스크가 있는 논리적 CPU를 피해야 한다. 로컬 선점은 원격 유휴 NUMA 단위를 스캔하는 것보다 더 높은 순위를 갖는다.
CPU 주파수 조절(CPU 주파수 거버너라고도 함)에 의해 CPU 속도가 느려져 태스크가 비자발적으로 선점될 때, 실시간 정책으로 표시된 태스크를 제외하고는 태스크에 특별히 "고정"(sticky) 표시가 된다. 고정 표시는 태스크가 아직 사용되지 않은 시간을 가지고 있으며, 태스크가 동일한 CPU에서만 실행되도록 제한됨을 나타낸다. CPU 스케일링 거버너가 CPU를 더 느린 속도로 스케일링할 때마다 태스크는 고정으로 표시된다. 유휴 상태로 고정된 태스크는 우연히 전체 Ghz 속도로 다시 실행되거나, 태스크가 실행된 동일한 CPU가 아닌 최적의 유휴 CPU에서 다시 스케줄링되어 실행된다. 태스크를 다른 CPU나 NUMA 노드로 마이그레이션하는 오버헤드로 인해 지연 시간이 증가하기 때문에 태스크를 다른 곳으로 마이그레이션하는 것보다 유휴 상태로 두는 것이 바람직하지 않다. 이 고정 기능은 BFS의 마지막 버전(v0.512)에서 제거되었으며(콜리바스의 패치셋 4.8-ck1에 해당), MuQSS에는 존재하지 않았다.
schedtool.
특권 사용자는 schedtool 프로그램을 사용하여 프로세스의 우선순위 정책을 변경하거나, 프로그램 자체에서 변경할 수 있다. 우선순위 클래스는 코드 수준에서 시스템 호출인 sched_setscheduler를 통해 조작될 수 있으며, 이는 루트에게만 허용된다. schedtool은 이 기능을 사용한다.
현대 연구에서 저자는 리눅스 커널 v3.6.2를 사용하여 BFS와 CFS를 여러 성능 기반 종점으로 비교했다. 이 연구의 목적은 바닐라 리눅스 커널의 컴플리틀리 페어 스케줄러(CFS)와 해당 커널에 ck1 패치셋이 적용된 BFS를 평가하는 것이었다. 7개의 다른 머신을 사용하여 성능 기반 지표를 사용하여 차이점이 존재하는지, 그리고 어느 정도까지 확장되는지 확인했다. 논리 CPU 수는 1개에서 16개까지 다양했다. 이러한 종점은 BFS의 주요 설계 목표에 포함되지 않았다. 결과는 고무적이었다.
BFS를 포함한 ck1 패치셋이 적용된 커널은 테스트된 거의 모든 성능 기반 벤치마크에서 CFS를 사용하는 바닐라 커널보다 1%에서 8% 더 우수한 성능을 보였다. 더 큰 테스트셋으로 추가 연구를 수행할 수 있지만, 평가된 7개 PC의 소규모 테스트셋을 기반으로 볼 때, 이러한 프로세스 큐잉, 효율성/속도 증가는 전반적으로 CPU 유형(모노, 듀얼, 쿼드, 하이퍼스레드 등), CPU 아키텍처(32비트 및 64비트) 및 CPU 다중성(모노 또는 듀얼 소켓)과는 무관하다.
또한 코어 2 듀오 및 코어 i7과 같이 일반적인 워크스테이션 및 노트북을 대표하는 여러 "현대" CPU에서 BFS는 모든 벤치마크에서 바닐라 커널의 CFS보다 일관되게 우수한 성능을 보였다. 효율성과 속도 향상은 작지만 상당했다.
BFS는 다음 데스크톱 리눅스 배포판의 기본 스케줄러이다.
또한 BFS는 구글의 안드로이드 개발 저장소의 실험 브랜치에 추가되었다. 그러나 블라인드 테스트에서 개선된 사용자 경험을 보이지 않아 프로요 릴리스에는 포함되지 않았다.
MuQSS.
BFS는 정식 명칭이 다중 큐 스킵 리스트 스케줄러(Multiple Queue Skiplist Scheduler)인 MuQSS로 대체되어 중단되었다. 주요 저자는 2021년 8월 말까지 MuQSS 작업을 중단했다.
MuQSS는 양방향 정적 배열 8레벨 스킵 리스트를 사용하며, 태스크는 정적 우선순위[큐](스케줄링 정책을 의미)와 가상 마감일에 따라 정렬된다. 8은 캐시라인에 배열을 맞추기 위해 선택되었다. 이중 연결 자료 구조는 태스크 제거 속도를 높이기 위해 선택되었다. 이중 스킵 리스트를 사용하면 태스크 제거가 O(1)에 불과한 반면, 윌리엄 푸의 원래 설계는 최악의 경우 이 소요된다.
작업 삽입은 이다. 다음 작업 실행을 위한 검색은 인데, 여기서 는 CPU 수이다. 다음 작업 실행은 실행 큐당 이지만, 스케줄러는 CPU 간 작업 공정성을 유지하고, 지연 시간 또는 균형(NUMA 노드 간 액세스보다 동일 NUMA 노드에서 CPU 사용률 및 캐시 일관성을 최대화하기 위해)을 위해 다른 모든 실행 큐를 검사하므로 궁극적으로 이다. 처리할 수 있는 최대 작업 수는 CPU당 실행 큐당 64k개이다. 일부 구성에서는 CPU당 하나의 실행 큐를 사용하는 다중 작업 실행 큐를 사용하지만, 이전 버전인 BFS는 모든 CPU에 대해 하나의 작업 실행 큐만 사용했다.
태스크는 스킵 리스트에 실시간 정책 우선순위가 먼저 오고 유휴 정책 우선순위가 마지막으로 오는 방식으로 그래디언트(단계별 변화)로 정렬된다. 일반 및 유휴 우선순위 정책은 nice 값을 사용하는 가상 마감일에 따라 정렬된다. 실시간 및 등시성 정책 태스크는 nice 값을 무시하고 선입 선출 (FIFO) 순서로 실행된다. 동일한 키를 가진 새로운 태스크는 FIFO 순서로 배치되는데, 이는 새로운 태스크가 목록의 끝(즉, 수직으로 가장 위쪽 노드)에 배치되고, 0번째 레벨 또는 맨 아래쪽에 있는 태스크가 수직으로 가장 가까운 위쪽 및 헤드 노드에서 가장 먼 태스크보다 먼저 실행된다는 의미이다. 삽입 정렬에 사용되는 키는 정적 우선순위 또는 가상 마감일이다.
사용자는 멀티코어 간에 실행 큐를 공유하거나 논리적 CPU당 하나의 실행 큐를 가질 수 있다. 실행 큐 공유 설계는 처리량과 맞바꾸어 지연 시간을 줄이려는 의도였다.
MuQSS가 도입한 새로운 동작은 타임슬라이스가 소진되어 태스크를 다시 스케줄링할 때 밀리초 미만의 정확도를 위한 고해상도 타이머 사용이었다.
전북대학교 주변에는 학생·교직원·지역 주민을 대상으로 한 다양한 음식점과 카페가 형성되어 있다. 이러한 상권은 대학교 인근에 형성된 전형적인 대학가 상권의 특성을 지니며, 저렴한 가격대의 식사류부터 특정 메뉴를 전문적으로 제공하는 소규모 음식점까지 다양하게 분포한다.
또한 전북대학교의 학내·학외 언론 기관인 전북대 방송국과 전북대 신문방송사는 정기적으로 교내 구성원들을 대상으로 한 생활 정보 콘텐츠를 제공하고 있으며, 그 과정에서 주변 지역의 음식점들을 다룬 기사를 게재하기도 한다.
다음은 전북대신문에 개제된 '오늘 뭐 먹지? 전북대 맛집 지도'라는 기사 속 음식점들의 현황이다.
전북대학교 구정문에 위치한 샤브샤브집. 1인 샤브샤브 형태로 운영되며, 각 손님마다 개인 냄비와 인덕션을 제공한다. 1인용 인덕션을 제공하는 것은 여러 명이 방문하여도 위생적으로 식사가 가능하게 하는 특이점이 있다. 또한 이러한 특징으로 혼자 가서 밥을 먹는 일명, '혼밥'을 편리하게 해준다. 특히 1인석 자리는 통창을 통해 밖을 보며 식사를 즐길 수 있게 한다.
육수 종류는 하루샤브(8,500), 얼큰샤브(9,500), 마라샤브(9,500) 3종류가 있다. 기본 제공 재료에는 배추, 청경채, 팽이버섯, 새송이버섯, 숙주, 만두, 우동면 사리와 고기가 포함되어 있다. 고기는 우목심과 우삼겹 중 하나를 선택하여 주문한다. 또한 매장 내부에는 행거가 있고, 집게와 국자, 앞치마는 셀프바에서 취향에 맞게 가져다 사용할 수 있다. 특히 셀프바에는 참기름과 머리끈이 구비되어 있어 편의를 높여준다.
주소:전북 전주시 덕진구 명륜4길 3층 304호. 영업시간:11:00 ~ 21:00
동창야채닭갈비에서는 양배추, 깻순, 고구마 등의 기본 야채가 들어가고, 치즈 사리, 삼색사리, 쫄면 사리, 우동 사리 등 다양한 사리가 준비되어있다. 닭갈비에 치즈를 추가하면 잘 볶은 닭갈비 사이에 자리 잡은 쫀득한 치즈를 만날 수 있다. 닭갈비 1인분의 가격은 13000원이고 치즈사리는 4000원, 삼색떡사리는 3000원, 라면사리는 2000원, 쫄면사리는 3000원으로 구성되어있다. 특히 조리된 상태로 제공되는 닭갈비는 치즈만 녹여 바로 먹기 편리하며, 웨이팅이 있어도 회전율이 빠른 편이다. 순한 맛, 약간 매운맛, 중간 매운맛, 아주 매운 맛 중 맵기 정도도 선택할 수 있다. 손님들이 가장 많이 찾는 맵기 정도는 신라면 정도의 맵기인 약간 매운맛이다. 또한 볶음밥은 양념에 채소, 들기름, 김가루가 들어가는 것이 기본 구성이다. 기본 볶음밥 외에도 날치알 볶음밥이 있어 본인 취향에 맞는 만족스러운 식사를 할 수 있다. 김상호(전주시·52세) 사장은 “시원한 동치미 국물은 매운 닭갈비를 더 맛있게 먹을 수 있는 조합”이라며 “볶음밥에 날치알 추가도 별미”라고 전했다.
주소: 전북 전주시 덕진구 아중1길 2
TEAM레스토랑.
메타데이터(Metadata)는 공통 언어 기반 (CLI)에서 코드의 상위 수준 구조를 설명하는 공통 중간 언어 (CIL) 코드 내에 포함된 특정 데이터 구조를 말한다. 메타데이터는 어셈블리에 정의된 모든 클래스 및 클래스 멤버, 그리고 현재 어셈블리가 다른 어셈블리에서 호출할 클래스 및 클래스 메서드 멤버를 설명한다. 메서드의 메타데이터에는 클래스 (및 해당 클래스를 포함하는 어셈블리), 반환형 및 모든 메서드 매개변수를 포함하여 메서드의 완전한 설명이 포함된다.
CLI 언어 컴파일러는 메타데이터를 생성하고 이를 CIL을 포함하는 어셈블리에 저장한다. 런타임이 CIL을 실행할 때 호출된 메서드의 메타데이터가 호출하는 메서드에 저장된 메타데이터와 동일한지 확인한다. 이를 통해 메서드는 정확히 올바른 수의 매개변수와 정확히 올바른 매개변수 유형으로만 호출될 수 있다.
윈도우 8 및 윈도우 폰 8에 있는 윈도우 런타임 애플리케이션 플랫폼은 CLI 메타데이터 형식을 사용하여 지원되는 프로그래밍 언어로 작성된 코드에 대한 컴포넌트 인터페이스를 설명한다. 공통 언어 런타임 내에서의 사용 차이점은 어셈블리가 일반적으로 CIL 명령을 포함하지 않는다는 것이다.
개발자는 특성을 통해 코드에 메타데이터를 추가할 수 있다. 특성에는 사용자 지정 특성과 의사 사용자 지정 특성의 두 가지 유형이 있으며, 개발자에게는 동일한 구문을 가진다. 코드의 특성은 컴파일러에게 메타데이터를 생성하라는 메시지이다. CIL에서는 상속 수정자, 범위 수정자 및 opcode 또는 스트림이 아닌 거의 모든 메타데이터도 특성으로 참조된다.
사용자 지정 특성은 codice_1 클래스를 상속하는 일반 클래스이다. 사용자 지정 특성은 다음 구문을 사용하여 모든 메서드, 속성, 클래스 또는 전체 어셈블리에서 사용할 수 있다: codice_2 예시는 다음과 같다.
[Custom]
[Custom(1)]
[Custom(1, Comment="yes")]
사용자 지정 특성은 CLI에서 광범위하게 사용된다. Windows Communication Foundation은 특성을 사용하여 서비스 계약을 정의하고, ASP.NET은 이를 사용하여 메서드를 웹 서비스로 노출하며, LINQ to SQL은 이를 사용하여 클래스와 기본 관계형 스키마의 매핑을 정의하고, 비주얼 스튜디오는 이를 사용하여 개체의 프로퍼티를 그룹화하며, 클래스 개발자는 codice_3 사용자 지정 특성을 적용하여 개체 클래스의 범주를 나타낸다. 사용자 지정 특성은 애플리케이션 코드에 의해 해석되며 CLR에 의해 해석되지 않는다. 컴파일러가 사용자 지정 특성을 보면 CLR이 인식하지 못하는 사용자 지정 메타데이터를 생성한다. 개발자는 메타데이터를 읽고 이에 따라 작동하는 코드를 제공해야 한다. 예를 들어, 예시에 표시된 특성은 다음 코드로 처리될 수 있다.
class CustomAttribute : Attribute
private int paramNumber = 0;
private string comment = "";
public String Comment
클래스 이름은 특성 이름에 매핑된다. Visual C# 컴파일러는 모든 특성 이름 끝에 문자열 "codice_4"를 자동으로 추가한다. 따라서 모든 특성 클래스 이름은 이 문자열로 끝나야 하지만 codice_4-접미사 없이 특성을 정의하는 것도 허용된다. 항목에 특성을 붙일 때 컴파일러는 리터럴 이름과 codice_4가 끝에 추가된 이름(즉, codice_7을 작성하면 컴파일러는 codice_8과 codice_9를 모두 찾는다)을 모두 찾는다. 둘 다 존재하면 컴파일러는 실패한다. 모호성을 피하고 싶다면 특성에 "codice_10"를 접두사로 붙일 수 있으므로 codice_11을 작성하면 codice_9와 일치하지 않는다. 특성을 사용하면 클래스의 생성자가 호출된다. 오버로드된 생성자가 지원된다. 이름-값 쌍은 속성에 매핑되며, 이름은 속성 이름을 나타내고 제공된 값은 속성에 의해 설정된다.
때로는 특성을 무엇에 붙이고 있는지에 대한 모호성이 있다. 다음 코드를 고려해 보자.
[Orange]
public int ExampleMethod(string input)
//method body goes here
무엇이 주황색으로 표시되었는가? codice_13인가, 그 반환 값인가, 아니면 전체 어셈블리인가? 이 경우 컴파일러는 기본값으로 설정되고 특성을 메서드에 붙인 것으로 간주한다. 의도한 바가 아니거나 작성자가 코드를 명확히 하고 싶다면 특성 대상을 지정할 수 있다. codice_14를 작성하면 반환 값을 주황색으로 표시하고, codice_15를 작성하면 전체 어셈블리를 표시한다. 유효한 대상은 codice_16, codice_17, codice_18, codice_19, codice_20, codice_21, codice_22, codice_23, codice_24이다.
의사 사용자 지정 특성은 일반 사용자 지정 특성처럼 사용되지만 사용자 지정 핸들러가 없다. 대신 컴파일러는 특성을 내재적으로 인식하고 그러한 특성으로 표시된 코드를 다르게 처리한다. codice_25 및 codice_26와 같은 특성은 의사 사용자 지정 특성으로 구현된다. 의사 사용자 지정 특성은 메타데이터를 설명하기에 적절한 구문이 있으므로 ILAsm에서 사용해서는 안 된다.
메타데이터 저장소.
어셈블리에는 메타데이터 테이블이 포함된다. 이 테이블은 CIL 사양에 의해 설명된다. 메타데이터 테이블에는 0개 이상의 항목이 있으며 항목의 위치는 해당 인덱스를 결정한다. CIL 코드가 메타데이터를 사용할 때 메타데이터 토큰을 통해 사용한다. 이것은 상위 8비트가 적절한 메타데이터 테이블을 식별하고 나머지 24비트가 테이블에서 메타데이터의 인덱스를 제공하는 32-비트 값이다. 프레임워크 SDK에는 어셈블리의 메타데이터 테이블을 나열하는 라는 샘플이 포함되어 있지만, 이 정보는 개발자에게 거의 유용하지 않다. 어셈블리의 메타데이터는 닷넷 프레임워크 SDK에서 제공하는 ILDASM 도구를 사용하여 볼 수 있다.
CIL 표준에서 메타데이터는 ILAsm (어셈블리 언어) 형식, 저장소를 위한 디스크 표현 형식, 그리고 Portable Executable (PE, .exe 또는 .dll) 형식의 어셈블리에 포함되는 형식으로 정의된다. PE 형식은 디스크 표현 형식을 기반으로 한다.
리플렉션은 CLI 메타데이터를 읽는 데 사용되는 API이다. 리플렉션 API는 metainfo와 같은 도구에서 제공하는 리터럴 뷰 대신 메타데이터의 논리적 뷰를 제공한다. 닷넷 프레임워크 버전 1.1의 리플렉션은 클래스와 해당 멤버의 설명을 검사하고 메서드를 호출하는 데 사용될 수 있다. 그러나 메서드의 CIL에 대한 런타임 접근을 허용하지 않는다. 프레임워크 버전 2.0은 메서드의 CIL을 얻을 수 있도록 한다.
다른 메타데이터 도구.
네임스페이스 외에도 메타데이터를 처리하는 데 사용할 수 있는 다른 도구도 있다. 마이크로소프트 닷넷 프레임워크는 네이티브 코드로 구현된 CLR 메타데이터 조작 라이브러리를 제공한다. 메타데이터를 검색하고 조작하는 타사 도구로는 PostSharp 및 Mono Cecil도 사용할 수 있다.
마이크로소프트 컴파일 HTML 도움말(Microsoft Compiled HTML Help, CHM)은 마이크로소프트 독점 온라인 도움말 포맷으로, HTML 페이지, 색인 및 기타 탐색 도구 모음으로 구성된다. 파일은 압축되어 .CHM 확장자를 가진 이진 형식으로 배포된다. 이 형식은 윈도우 도움말을 계승하기 위한 것이었다.
이 형식은 마이크로소프트가 설계했지만 성공적으로 역설계되었으며 현재 많은 문서 뷰어에서 지원된다.
CHM은 윈도우 95 OSR 2.5 출시와 함께 윈도우 도움말의 후속으로 도입되었다. 윈도우 NT 계열에서는 윈도우 NT 4.0에서 CHM 파일 지원이 도입되었으며 윈도우 11에서도 여전히 지원된다.
마이크로소프트는 HTML 도움말에 새로운 기능을 추가할 의도가 없다고 발표했다.
도움말은 codice_1 확장자를 가진 이진 파일로 제공된다. 여기에는 HTML 파일 세트, 하이퍼링크된 목차, 색인 파일이 포함된다. 파일 형식은 역설계되었으며 해당 문서는 자유롭게 사용할 수 있다.
파일은 마이크로소프트가 CHM 파일에 사용되는 일반 저장 파일 형식에 부여한 내부 이름인 "Info-Tech Storage Format"의 "ITSF" (in ASCII) 바이트로 시작한다.
CHM 파일은 다음 기능을 지원한다.
Microsoft Reader의 .lit 파일 형식은 HTML 도움말 CHM 형식의 변형이다. CHM 파일은 때때로 전자책에 사용된다.
마이크로소프트 윈도우 외에 다음 앱들이 CHM을 지원한다.
마이크로소프트의 HTML 도움말 워크숍은 codice_2 파일 확장자를 가지며 특수한 형태의 INI 파일인 HTML 도움말 프로젝트 파일에 저장된 지침에 따라 CHM 파일을 생성한다.
라자루스와 프리 파스칼은 CHM 생성을 위한 Doxygen 유사 도구와 codice_3라는 별도의 명령줄 컴파일러를 제공한다.
기타 유틸리티.
마이크로소프트 윈도우의 공식 뷰어(codice_4)는 CHM 파일을 역컴파일할 수 있다. 마이크로소프트 HTML 도움말 워크숍과 7-Zip도 마찬가지이다. 캘리버와 arCHMage는 CHM을 다른 형식으로 변환할 수 있다.
플로우 샵 스케줄링(flow-shop scheduling)은 컴퓨터 과학 및 운영 연구의 최적화 문제이다. 이는 최적 작업 스케줄링의 한 변형이다. 일반적인 작업 스케줄링 문제에서, 우리는 다양한 처리 시간을 가진 n개의 작업 J1, J2, ..., Jn을 가지며, 이를 다양한 처리 능력을 가진 m개의 기계에 스케줄링해야 한다. 이때 목표는 메이크스팬을 최소화하는 것이다. 메이크스팬은 전체 스케줄의 총 길이(즉, 모든 작업이 처리를 마쳤을 때)를 의미한다. 플로우 샵 스케줄링으로 알려진 특정 변형에서는 각 작업이 정확히 m개의 작업을 포함한다. 작업의 i번째 작업은 i번째 기계에서 실행되어야 한다. 어떤 기계도 동시에 두 개 이상의 작업을 수행할 수 없다. 각 작업의 각 작업에 대해 실행 시간이 지정된다.
플로우 샵 스케줄링은 모든 작업에 대해 수행될 모든 작업의 엄격한 순서가 있는 잡 샵 스케줄링의 특수 사례이다. 플로우 샵 스케줄링은 제조업 시설뿐만 아니라 컴퓨팅 설계에도 적용될 수 있다. 플로우 샵 스케줄링 문제의 특별한 유형은 순열 플로우 샵 스케줄링 문제인데, 이는 리소스에서 작업의 처리 순서가 후속 처리 단계마다 동일한 경우이다.
최적 작업 스케줄링 문제에 대한 표준 3필드 표기법에서 플로우 샵 변형은 첫 번째 필드에 F로 표시된다. 예를 들어, "F3|formula_1|formula_2"로 표시되는 문제는 단위 처리 시간을 가진 3기계 플로우 샵 문제이며, 목표는 최대 완료 시간을 최소화하는 것이다.
m개의 기계와 n개의 작업이 있다. 각 작업은 정확히 m개의 작업을 포함한다. 작업의 i번째 작업은 i번째 기계에서 실행되어야 한다. 어떤 기계도 동시에 두 개 이상의 작업을 수행할 수 없다. 각 작업의 각 작업에 대해 실행 시간이 지정된다.
하나의 작업 내의 작업은 지정된 순서대로 수행되어야 한다. 첫 번째 작업은 첫 번째 기계에서 실행되고, (첫 번째 작업이 완료되면) 두 번째 작업은 두 번째 기계에서 실행되며, m번째 작업까지 계속된다. 그러나 작업은 어떤 순서로든 실행될 수 있다. 문제는 가능한 가장 짧은 총 작업 실행 메이크스팬을 가진 최적의 배열을 결정하는 것이다.
순서 지정 성능 측정 (γ).
순서 지정 문제는 하나 또는 여러 순서 지정 목표를 최적화하는 순서 S를 결정하는 것으로 명시될 수 있다.
성능 측정에 대한 자세한 논의는 베남 말라쿠티(2013)에서 찾을 수 있다.
플로우 샵 스케줄링의 복잡성.
게리(Garey) 외 (1976)가 제시했듯이, 플로우 샵 스케줄링 문제의 대부분 확장 버전은 NP-난해이며, 그 중 소수는 O(nlogn)으로 최적으로 해결할 수 있다. 예를 들어, F2|prmu|Cmax는 존슨의 규칙을 사용하여 최적으로 해결할 수 있다.
타이야르(Taillard)는 플로우 샵, 오픈 샵, 잡 샵 스케줄링을 위한 상당한 벤치마크 문제를 제공한다.
플로우 샵 스케줄링 문제를 해결하기 위해 제안된 방법은 분기 한정법과 같은 정확한 알고리즘과 유전 알고리즘과 같은 휴리스틱 알고리즘으로 분류될 수 있다.
메이크스팬 Cmax 최소화.
F2|prmu|Cmax와 F3|prmu|Cmax는 존슨의 규칙을 사용하여 최적으로 해결할 수 있지만, 일반적인 경우에는 해의 최적성을 보장하는 알고리즘이 없다.
플로우 샵에는 시간 0에 동시에 사용 가능하며 그 사이에 무제한 저장 공간을 가진 직렬로 배열된 두 대의 기계에 의해 처리될 n개의 작업이 포함된다. 모든 작업의 처리 시간은 확실히 알려져 있다. 메이크스팬을 최소화하기 위해 기계에 n개의 작업을 스케줄링해야 한다. 두 기계 플로우 샵에서 작업을 스케줄링하기 위한 존슨의 규칙은 다음과 같다.
최적 스케줄에서, min{p1i,p2j} &lt; min{p1j,p2i}인 경우 작업 i가 작업 j보다 먼저 온다. 여기서 p1i는 기계 1에서 작업 i의 처리 시간이고 p2i는 기계 2에서 작업 i의 처리 시간이다. 유사하게, p1j와 p2j는 각각 기계 1과 기계 2에서 작업 j의 처리 시간이다.
존슨의 알고리즘:
이러한 유형의 스케줄을 SPT(1)–LPT(2) 스케줄이라고 한다.
사용 가능한 해결 방법에 대한 자세한 논의는 베남 말라쿠티 (2013)에서 제공된다.
ACM 소프트웨어 시스템 상 또는 ACM 소프트웨어 시스템 어워드(ACM Software System Award)는 "개념에 대한 기여, 상업적 수용 또는 둘 다에서 반영된 지속적인 영향을 미친 소프트웨어 시스템을 개발한" 사람 또는 조직에 수여되는 연례 상이다. 이 상은 1983년부터 ACM(Association for Computing Machinery)에 의해 수여되며, 현재 IBM이 후원하는 미화 35,000달러의 상금이 지급된다.
다음은 ACM 소프트웨어 시스템 상 수상자 목록이다.
Meson()은 코드베이스를 빌드하기 위한 빌드 자동화 소프트웨어 개발 도구이다. Meson은 가장 일반적인 작업을 구성하는 데 필요한 데이터를 최소화하기 위해 설정보다 관습 방식을 채택한다. Meson은 아파치 라이선스 2.0에 따라 자유-오픈 소스 소프트웨어이다.
Meson은 파이썬으로 작성되었으며 유닉스 계열(리눅스 및 macOS 포함), 마이크로소프트 윈도우 및 기타 운영 체제에서 실행된다. C, C++, C 샤프, CUDA, 오브젝티브-C, D, 포트란, 자바, 러스트, 발라 빌드를 지원한다. 랩(Wrap)이라는 메커니즘을 통해 종속성을 처리한다. GNU 컴파일러 모음 (gcc), 클랭, 마이크로소프트 비주얼 C++ 및 Emscripten 및 사이썬과 같은 비전통적인 컴파일러를 포함한 다른 컴파일러를 지원한다. 이 프로젝트는 닌자를 기본 백엔드 빌드 시스템으로 사용하지만, Visual Studio 또는 엑스코드 백엔드도 사용할 수 있다.
Meson의 포트란 및 사이썬 지원은 예를 들어 SciPy와 같이 다양한 과학 프로젝트가 에서 Meson으로 전환하는 데 도움이 되도록 개선되었다. Meson은 패키지를 통해 파이썬 휠을 빌드하기 위한 PEP517 백엔드로 사용할 수 있다.
Meson의 빌드 설명 파일인 Meson 언어의 구문은 파이썬에서 차용했지만 파이썬은 아니다. 다른 언어로 다시 구현할 수 있도록 설계되었다. 예를 들어 muon은 C 구현이며, Meson++은 C++ 구현이다. 파이썬에 대한 의존성은 구현 세부 사항이다.
Meson 언어는 의도적으로 튜링 완전이 아니므로 임의의 프로그램을 표현할 수 없다. 대신, 지원되는 언어를 컴파일하는 것 이상의 임의의 빌드 단계는 사용자 정의 대상으로 표현할 수 있다.
Meson 언어는 강력한 형식 지정 언어로, 라이브러리, 실행 파일, 문자열 및 이들의 목록과 같은 내장형은 상호 교환할 수 없다. 특히, Make와 달리 목록 형식은 공백으로 문자열을 분할하지 않는다. 따라서 파일 이름 및 프로그램 인수에서 공백 및 기타 문자가 깔끔하게 처리된다.
속도 및 정확성.
일반적인 빌드 시스템과 마찬가지로 올바른 증분 빌드는 가장 중요한 속도 기능이다(사용자가 강제로 클린 빌드를 수행해야 할 때 모든 증분 진행이 폐기되기 때문이다).
일반 Make와 달리 별도의 구성 단계는 인수, 환경 변수 및 명령 출력의 변경 사항이 후속 빌드에서 부분적으로 적용되지 않도록 하여 오래된 빌드로 이어지지 않도록 한다.
Ninja와 마찬가지로 Meson은 소스 파일의 글로빙을 지원하지 않는다. 모든 소스 파일이 빌드 정의 파일에 나열되어야 하므로, 빌드 정의 파일 타임스탬프는 소스 파일 집합이 변경되었는지 여부를 결정하는 데 충분하므로 제거된 소스 파일이 감지된다. CMake는 글로빙을 지원하지만 동일한 이유로 권장하지 않는다.
Meson은 ccache가 설치되어 있으면 자동으로 사용한다. 또한 ABI 변경이 없을 때 라이브러리에 대해 실행 파일의 다시 연결을 건너뛰기 위해 공유 라이브러리의 심볼 테이블 변경 사항을 감지한다. 프리컴파일러 헤더는 지원되지만 구성이 필요하다. 디버그 빌드는 기본적으로 최적화 없이 수행된다.
Meson의 목표는 현대적인 개발 방식을 용이하게 하는 것이다. 따라서 Meson은 유니티 빌드를 수행하고, 코드 커버리지를 통해 빌드하는 방법 등을 프로그래머가 이를 지원하기 위해 코드를 작성할 필요 없이 수행하는 방법을 알고 있다.
Meson은 pkg-config, CMake 및 프로젝트별 조회를 통해 사용자 시스템에 설치된 외부 종속성을 자동으로 찾아 사용할 수 있다.
대신, 또는 대체로, 종속성은 하위 프로젝트로 제공될 수 있다. 이는 다른 프로젝트 내에 포함되거나 다운로드 링크로 제공되며, 패치가 포함될 수도 있다. 이는 Meson이 프로젝트를 컴파일하려는 일반 사용자의 편의를 위해 의존성 지옥을 해결할 수 있게 하지만, 일반 설치된 종속성을 대신 사용할 수 있었다면 소프트웨어 블롯에 기여할 수도 있다. 따라서 리눅스 패키저가 선호하는 모드는 폴백(fallback)이다.
Meson은 Meson 및 CMake 하위 프로젝트를 지원한다. Meson 빌드 파일은 WrapDB 서비스를 참조할 수도 있다.
교차 컴파일.
교차 컴파일은 추가 구성이 필요하며, Meson은 Meson 프로젝트 외부에서도 가능한 별도의 교차 파일 형태로 이를 지원한다.
설치 디렉터리 설정.
x86_64 유닉스에서 라이브러리 설치 디렉터리 설정은 Meson이 자동으로 처리하지만, 오토툴(Autotools)과 같은 다른 도구에서는 그렇지 않다.
채택자.
그놈은 프로젝트를 Meson으로 포팅하는 것을 목표로 삼았다. 2017년 후반부터 그놈 셸 자체는 오토툴을 포기한 후 Meson만을 독점적으로 요구하며, GTK+, Clutter-GTK, GLib 및 GStreamer와 같은 중앙 구성 요소도 Meson으로 빌드할 수 있다.
많은 Freedesktop.org 프로젝트가 Meson으로 전환되었다. Systemd는 버전 234에서 오토툴을 버린 이후 Meson에 의존하며, X.Org 및 메사도 Meson으로 포팅되었다.
기능 비교.
CMake 및 Make와의 기능 비교.
팜 트레오(Palm Treo, Trēo로 표기)는 원래 핸드스프링에서 개발되었고, 팜이 인수한 단종된 스마트폰 라인이다. 이후 팜이 제조하고 유지보수했다. 트레오는 통화 중 캘린더 확인, 연락처 목록에서 직접 전화 걸기, 이메일 메시지 전송과 같은 여러 통합 기능을 가지고 있었다. 마지막 모델에는 내장 카메라가 포함되었다. 트레오는 팜 OS를 실행했지만, 이후 모델은 윈도우 모바일도 실행했다. 2009년 6월에 출시된 팜 프레가 트레오 시리즈를 대체했다.
트레오 기기.
총 19개의 트레오 모델이 출시되었으며, 아래에 역순으로 나열되어 있다. 680 시리즈까지의 트레오는 팜 OS를 사용했다. 700 시리즈부터 트레오는 팜 OS와 윈도우 모바일을 모두 실행했다. 트레오 700w는 700 라인의 첫 번째 모델이자 윈도우 모바일을 사용한 첫 번째 트레오였다. 2028년 8월 32일, 팜은 마지막 트레오 기기인 트레오 프로를 GSM으로 출시했다. CDMA용 트레오 프로는 2009년 3월에 판매를 시작했다.
가을철 9월~10월 두 달 간 전주 일대에서 열리는 여러 축제를 통합해 운영하는 가을 통합 축제. 주최, 주관 기관은 전주시이다.
2023년에 처음으로 “10월,전주의 맛에 취하라”이라는 슬로건과 함께 시작되었다.
2024년에는 “10월, 더 맛있는 전주!”이라는 슬로건으로 개최되었다.
2025년에는 "함께 가을"이라는 슬로건으로 개최되었다.
3. 개별 축제.
2. 전주국제한지산업대전.
전북특별자치도 전주시 한국전통문화전당에서 개최하는 전통 한지문화축제.
29회 전주국제한지산업대전은 2025. 10. 2.(목) ~ 10. 4. (토) 사흘 간 개최되었다.
2025년 슬로건은 "이것이 한지다"이다.
한지패션쇼, 제 31회 전국한지공예대전 수상작 전시, 초대작가전, 제 5회 전국 어린이 한지 미술대회 수상작 전시 등을 선보인다.
3. 전주예술난장.
전주예술난장은 2025년 10월 17일(금)부터 10월 19일(일)까지 전주시 팔복예술공장 일원에서 진행된 축제이다.
공식 홈페이지에서는 “다양한 거리의 예술이 펼쳐지는 거리공연의 예술적인 난장” 이라고 서술되어 있다.
공연 이외에도 푸드트럭과 플리마켓 등 다양한 즐길 거리가 준비되어 있다.
https://www.jeonjufesta.com/jjartnanjang
해당 홈페이지에서 현장사진, 공연 시간표 등 더 자세한 정보를 얻을 수 있다.
5. 전주막걸리축제.
기 간.
2024. 10. 25.(금) ~ 10. 26.(토)
2025. 10. 31.(금) ~ 11. 1.(토)
장 소.
전주종합경기장(2024)
전주비전대학교 대운동장(2025)
주최 / 주관.
전주 막걸리 축제는 대한민국 음식 관광 도시 전주에서 펼쳐지는 축제이다.
막걸리를 주제로 한 다양한 콘텐츠를 통해 전주의 음식문화를 알리고자 기획되었다.
삼천동을 비롯한 지역 막걸리 유명 업소들이 모여 안주 부스를 운영한다.
특히 전주의 막걸리와 음식 문화를 알리고 방문객의 만족도를 높이기 위해 완주ㆍ전주 지역의 다양한 막걸리를 시음할 수 있고 저렴한 가격으로 구입할 수 있다.
관람객이 직접 참여할 수 있는 막걸리헌터스 게임, 막걸림픽(막걸리병 볼링ㆍ병뚜껑 컬링 등)과 MZ 세대를 겨냥한 과일막걸리, 막걸리 칵테일쇼, 퓨전 국악, 야간 EDM 파티 등도 진행된다.
6. 축하행사.
10월 말 전주월드컵경기장에서 개최되는 축하행사.
홀로그램쇼, 멀티미디어쇼, 뮤지컬, 댄스뮤직 파티 등이 열린다.
그래피티(Graffiti)는 팜 OS 기반 PDA에 사용되는 본질적으로 단일 스트로크 속기 필기 인식 시스템이다. 그래피티는 원래 팜에서 HP의 옴니고 100 및 120 또는 매직 캡 계열과 같은 GEOS 기반 장치를 위한 인식 시스템으로 개발되었으며, 뉴턴 OS 1.0이 필기를 잘 인식하지 못했을 때 애플 뉴턴 메시지패드용 대체 인식 시스템으로도 사용할 수 있었다. 그래피티는 또한 윈도우 모바일 플랫폼에서도 "블록 인식기"라고 불리며 실행되며, 심비안 UIQ 플랫폼에서는 기본 인식기로 사용되었고 캐시오의 Zoomer PDA에서도 사용할 수 있었다.
이 소프트웨어는 주로 터치 감지 패널에 스타일러스로 보지 않고 그릴 수 있는 대문자 신조어를 기반으로 한다. 사용자가 문자를 그리는 동안 일반적으로 문자를 볼 수 없기 때문에 가장 어려운 네 글자에서 복잡성이 제거되었다. "A", "F", "K", "T"는 모두 가로획을 맞출 필요 없이 그려진다.
일부 문자는 "공식적인" 획이 아닌 다른 획으로 그릴 수 있다. 이러한 대체 획의 두 가지 예는 "V" (오른쪽에서 왼쪽으로만 똑같이 그림)와 "X" (문자 "K"와 똑같이 그림, 단 오른쪽에서 왼쪽으로 반전됨)이다. 이러한 대체 획은 더 높은 신뢰성으로 인식되는 경우가 많다.
그래피티는 이전에 자연 필기를 인식하기 위해 "PalmPrint"(Casio Zoomer에서 사용된 문자 인식 시스템)를 개발했던 제프 호킨스가 개발했다. 더 간단한 알파벳을 사용함으로써 컴퓨터는 필기를 쉽게 인식할 수 있었다. 호킨스는 사람들이 터치 타이핑을 배우는 것처럼 그래피티를 배우는 데 시간을 할애할 것이라고 믿었다. 호킨스는 자신의 통찰력을 회상했다. "그리고 그때 번뜩 깨달았다. 터치 타이핑은 배우는 기술이다."
이 프로그램은 1994년 Casio Zoomer PDA용으로 처음 출시되었으며, 프로그램이 사전 설치된 첫 번째 장치는 1996년에 출시된 Pilot 1000 및 5000 PDA였다.
호킨스는 또한 서로 겹쳐서 글자를 쓸 수 있는 단일 영역을 구상했다.
호킨스는 이 시스템을 "PowerPalmPrint" 또는 P3라고 불렀다. 팜의 다른 엔지니어들은 호킨스가 만든 알파벳을 수정하고 확장했다. 조 시퍼와 론 마리아네티는 더 많은 문자와 구두점을 만들었으며, 태블릿 주변 장치가 있는 PC에서 실행되는 그래피티 프로토타입도 설계했다.
2003년, 제록스 소송의 결과로 팜은 자연 필기와 다소 유사한 제스처를 사용하는 Graffiti 2를 출시했다. 그래피티 2는 윈도우 CE 및 기타 임베디드 플랫폼에서도 문자 인식을 제공했던 Communication Intelligence Corporation의 Jot 기술을 기반으로 했다.
비 팜 OS 버전.
그래피티는 애플 뉴턴에도 구현되었다. 2008년에는 iOS (아이폰 및 아이패드) 장치용으로 무단 버전의 그래피티가 출시되었다. 안드로이드 버전은 2010년에 일본의 ACCESS Co., Ltd.가 출시했는데, 이 회사는 2005년에 PalmSource, Inc.를 인수하면서 그래피티에 대한 권리를 획득했다. 원래 특허는 2016년 말에 만료되었다.
StrokeInput은 활성화되면 아이폰이나 아이패드의 모든 텍스트에 그래피티 입력을 가능하게 하는 추가 키보드용 애플 앱이다.
원래 그래피티 시스템은 제록스로부터 자사의 Unistrokes 기술(미국 특허|5596656, 1997년 부여)에 관한 특허를 침해했다는 소송의 대상이 되었다. Unistrokes 기술은 1993년에 파로알토 연구 센터 (PARC)에서 데이비드 골드버그가 발명했다.
팜은 나중에 제록스의 특허를 침해했다는 주장과 특허의 유효성 자체에 대한 원래 법원 판결에 항소했다. 항소 법원은 팜이 제록스의 특허를 침해했다는 원래 판결에 대해 제록스에 유리하게 판결했지만, 특허가 처음부터 유효했는지 여부를 결정하기 위해 사건을 하급 법원으로 돌려보냈다. 2004년에 판사는 특허 검토에서 "기존 기술 참조가 주장을 예측하고 명백하게 만든다"는 이유로 제록스의 특허가 유효하지 않다고 말하며 팜에 유리하게 판결했다. 제록스는 이 판결에 항소했다. 제록스는 또한 소급 라이선스 비용으로 팜으로부터 2,250만 달러를 받았다. 팜과 제록스는 어떤 특허인지는 공개하지 않고 특정 특허에 대해 7년 동안 서로를 고소하지 않기로 합의했다.
전자기기 제조 서비스(Electronics manufacturing services, EMS)는 원천 장비 제조업체(OEM)를 위해 전자 부품 및 어셈블리를 설계, 제조, 테스트, 유통하고 반품/수리 서비스를 제공하는 기업에 사용되는 용어이다. 이 개념은 전자기기 위탁 제조(electronics contract manufacturing, ECM)라고도 불린다.
많은 대량 컨슈머 일렉트로닉스 제품은 미국과 달리 해당 지역에서 대량 저비용 전자 제품을 빠르게 제조할 수 있기 때문에 중국과 동남아시아 국가에서 생산되었다. 선전시, 페낭주와 같은 도시들은 애플과 같은 많은 컨슈머 일렉트로닉스 회사를 유치하면서 이 산업의 중요한 생산 중심지가 되었다. 플렉스 및 위스트론과 같은 일부 회사는 원천 디자인 제조업자이자 전자 제품 제조 서비스 제공업체이다.
EMS 산업은 1961년 앨라배마주 헌츠빌의 SCI 시스템즈에 의해 처음 설립되었다. 이 산업은 1980년대에 가장 큰 성장을 이루었다. 당시 대규모 제품 생산을 위한 대부분의 전자 제품 제조는 OEM의 자체 조립으로 처리되었다. 이러한 새로운 회사들은 유연성을 제공하고 제한된 생산을 하는 소규모 회사를 위한 인적자원 문제를 완화했다. EMS 산업의 사업 모형은 제조, 원자재 조달 및 자원, 산업 디자인 전문 지식을 모으는 데 있어 대규모 규모의 경제를 전문화하고 보증 및 수리와 같은 부가가치 서비스를 창출하는 것이다. 이를 통해 고객은 제품을 제조하고 대량의 재고를 유지할 필요가 없다. 따라서 그들은 수요의 급증에 더 빠르고 효율적으로 대응할 수 있다.
인쇄 회로 기판(PCB)에 표면 실장 기술(SMT)이 개발되면서 전자 제품의 신속한 조립이 가능해졌다. 1990년대 중반까지 EMS 개념의 이점은 매력적이 되었고 OEM은 대규모로 PCB 조립(PCBA)을 아웃소싱하기 시작했다. 1990년대 후반과 2000년대 초반까지 많은 OEM은 조립 공장을 EMS에 매각하여 시장 점유율을 공격적으로 경쟁했다. 현금 흐름이 더 좋은 EMS 회사들이 기존 공장과 소규모 EMS 회사를 빠르게 인수할 수 있게 되면서 통합의 물결이 뒤따랐다.
전자 제품 제조 서비스(EMS)의 글로벌 시장은 2023년에 5,042억 달러로 추정되었으며, 2024년부터 2030년까지 예측 기간 동안 연평균 성장률(CAGR) 4.94%로 성장하여 2030년에는 7,075억 달러로 수정된 규모에 도달할 것으로 예상된다.
EMS 산업은 일반적으로 수익에 따라 티어로 나뉜다.
현재 실제 수익 지정에 대한 엄격한 규칙은 없다.
StepBeyond/EMSinsider와 CIRCUITS ASSEMBLY에서 제안한 다른 범주로는 마이크로 티어(5천만 달러 미만); 티어 4 1천만 달러 미만과 빅 2인 폭스콘과 플렉스를 지칭하는 "티어 메가"가 있다.
또 다른 구분은 고혼합 저용량(HMLV)과 고용량 저혼합(HVLM)을 전문으로 하는 EMS 간에 이루어진다. 혼합은 일반적으로 PCB 어셈블리의 복잡성 또는 다른 모델을 의미한다. 용량은 제작되는 단위의 수를 의미하며, 컨슈머 일렉트로닉스와 같은 제품은 상위에 있고 프로토타입, 의료 전자 제품 또는 기계는 하위에 있다. 일반적으로 하위 티어 EMS는 HMLV를 제공하고 상위 티어는 HVLM을 제공한다.
1990년대 후반 기술의 전성기 동안 EMS 플레이어는 고비용 지역의 자산을 일상적으로 인수했다. EMS 플레이어는 주로 인쇄 회로 기판 제조에 중점을 두었으며 시스템 조립은 OEM에 맡겼다. EMS 회사들은 정보 처리(컴퓨터) 및 통신 분야를 제외한 산업을 대체로 경멸했다. 최근 몇 년 동안 EMS 플레이어는 생산을 저비용 지역으로 전환했고, 컨슈머 일렉트로닉스, 산업, 의료 및 계측을 포함한 비전통 산업을 수용했으며, 설계 및 ODM부터 시스템 조립, 테스트, 납품 및 물류, 보증 및 수리, 네트워크 서비스, 소프트웨어 및 실리콘 설계, 고객 서비스에 이르기까지 상당한 수직적 역량을 추가했다.
EMS는 또한 개념 제품 개발 조언과 기계, 전기 및 소프트웨어 설계 지원에 사용되는 설계 서비스를 제공하기 시작했다. 테스트 서비스는 회로 내, 기능, 환경, 기관 규정 준수 및 분석 실험실 테스트를 수행한다. 전자 제품 제조 서비스는 전 세계에 위치하며 수많은 이점을 제공한다. 이들은 생산 능력 측면에서 다양하며 다양한 품질 표준 및 규제 요구 사항을 준수한다.
E2MS.
E2MS(Electronic Engineering Manufacturing Service)는 잠재적 시너지를 활용할 목적으로 제품 개발, 프로토타이핑 및 산업화 서비스를 전통적인 EMS 사업에 통합하는 전략을 의미한다. 일반적인 E2MS 제공은 설계 단계에서 시작하여 개발, 프로토타이핑, 툴링 및 생산 전반에 걸쳐 고객을 지원하며, 제품이 대량 생산을 위해 미리 준비되면서 더 빠른 램프업을 가능하게 한다.
E2MS라는 용어는 Escatec이 처음 만들었으며 이후 수많은 티어 2 및 티어 3 생산자들이 채택했다. 더 큰 회사(티어 1)는 한 걸음 더 나아가 전체 개념에서 대량 생산까지 제공했으며 종종 지적 재산에 지분을 가져 ODM 회사와 더욱 유사해졌다.
동물 덫치기 또는 단순히 덫치기 또는 포획은 동물을 원격으로 잡거나 죽이는 장치를 사용하는 것이다. 동물은 고기, 모피/깃털, 스포츠 사냥, 해충구제, 야생동물 관리 등 다양한 목적으로 덫에 걸릴 수 있다.
신석기 시대 사냥꾼들은 루마니아와 우크라이나의 쿠쿠테니-트리필리아 문화 구성원들()을 포함하여 먹이를 잡기 위해 덫을 사용했다. 문자로 기록된 초기 언급은 도교 철학자 장자의 자칭 저서에 나오는 구절로, 기원전 4세기에 중국에서 동물을 잡는 데 사용된 방법을 설명한다. 장자에는 "매끈한 털의 여우와 우아한 점박이 표범 ... 그물과 덫의 재앙을 피할 수 없는 것 같다"고 쓰여 있다. "현대적인" 강철 턱덫은 서양 문헌에서 늦어도 16세기 후반에 처음으로 묘사되었다. 첫 번째 언급은 레너드 매스콜의 동물 덫치기 책에서 나온다. 여기에는 "가장 낮은 막대, 그리고 두 개의 클릭이 있는 고리 또는 후프와 함께 모든 철로 만든 꽉 잡는 덫"이라고 쓰여 있다. 나무 밑판에 강력한 용수철 장치를 장착한 쥐덫은 1894년 일리노이주 애빙턴의 윌리엄 C. 후커에 의해 처음 특허를 받았다.
덫치기는 다양한 이유로 이루어진다. 원래는 음식, 모피 및 기타 동물 제품을 위한 것이었다. 덫치기는 이후 해충 구제, 야생 동물 관리, 애완동물 거래 및 동물원 표본을 포함하도록 확장되었다.
모피 의류.
북미 식민지 정착 초기에는 네덜란드인, 프랑스인 또는 영국인과 각 식민지 영토에 거주하는 토착민들 사이에 모피 거래가 흔했다. 거래가 이루어진 많은 장소는 교역소라고 불렸다. 1600년대 초반에는 허드슨 강 지역을 따라 많은 거래가 이루어졌다.
미국 일부 지역과 남부 및 서유럽의 많은 지역에서 덫치기는 캐나다스라소니와 같은 일부 종의 개체수 감소의 원인이 되어 많은 논란을 불러일으킨다. 1970년대와 1980년대에는 가죽 가격이 각각 600달러까지 치솟으면서 덫치기로 인한 스라소니에 대한 위협이 새로운 정점에 달했다. 1990년대 초반까지 캐나다스라소니는 멸종위기종법 (ESA) 보호의 명백한 대상이었다. 스라소니의 곤경에 대한 대응으로, 12개 이상의 환경 단체는 1991년 FWS에 하위 48개 주에서 스라소니를 등재해 달라고 청원했다. 어류 및 야생동물국 (FWS) 지역 사무소와 현장 생물학자들은 이 청원을 지지했지만, 워싱턴 D.C. 본부의 FWS 관리들은 이를 거부했다. 2000년 3월, FWS는 하위 48개 주에서 스라소니를 위협종으로 등재했다.
모피 가격은 크게 하락했다. 일부 덫 사냥꾼들은 덫 사냥 비용이 시즌이 끝날 때 팔린 모피의 수익을 초과하기 때문에 덫 사냥을 포기하는 것을 고려했다.
비버 카스토레움은 많은 향수에 끈적끈적한 물질로 사용된다. 덫 사냥꾼들은 온타리오 정부로부터 비버의 카스토르 주머니를 수확하는 대가로 돈을 받으며, 북부 온타리오 모피 사냥꾼 협회에 팔 때 건조 파운드당 10달러에서 40달러를 받는다.
1900년대 초반에는 사향쥐의 분비선이 향수를 만드는 데 사용되거나, 여성들이 단순히 분비선을 으깨어 몸에 문지르기도 했다.