shopkeeper/kowiki-cleaned-020126 huggingface dataset:
KDE e.V.

KDE e.V.는 법적 및 재정적 문제에서 KDE 커뮤니티를 대표하는 비영리 단체다. 1997년 11월 27일에 설립되었으며, 독일 베를린에 본사를 두고 있다. 이 협회는 현금, 하드웨어 및 기타 기부금을 통해 KDE를 지원하며, 이는 프로젝트의 개발 방향에 영향을 미치지 않으면서 개발 노력을 돕는 데 사용된다. 약어 'e.V.'는 독일어로 '등록 협회'를 의미하는 eingetragener Verein의 약자다.

 역사 
1997년 8월, 독일 아른스베르크에서 KDE One으로 알려진 첫 번째 KDE 커뮤니티 회의가 열렸다. 이 행사에는 15명의 참가자가 모였으며 14,000 마르크의 예산으로 운영되었다. 회의 기간 동안 조직자 마티아스 칼레 달하이머는 개인 은행 계좌를 통해 기부금과 비용을 처리하는 것이 비실용적이라는 것을 깨달았다. 그 결과, 그는 KDE 커뮤니티의 재정 및 법적 문제를 관리하기 위한 공식 조직 설립을 제안했다.

1997년 11월 27일, KDE e.V.는 튀빙겐에서 독일 법에 따른 비영리 등록 협회(eingetragener Verein)로 공식 등록되었다. 마티아스 에트리히가 조직의 첫 회장이 되었고, 달하이머가 부회장을 맡았다. 7명의 창립 멤버가 필요하다는 법적 요건을 충족하기 위해, 그들은 하우스메이트와 친구들을 영입하여 협회에 가입시켰다.

KDE e.V.는 기부금을 관리하고 행사를 조직함으로써 KDE 커뮤니티를 지속적으로 지원해 왔다. 시간이 흐르면서 그 역할이 확대되어 공식 회원 프로그램을 개발하고 직원을 고용했다.

2006년 10월, 마크 셔틀워스가 KDE의 첫 번째 개인 후원자가 되었고, 이어서 2007년 2월에 트롤테크가 첫 번째 기업 후원자가 되었다. 그해 말에 KDAB, 인텔, 노벨을 포함한 추가 후원자들이 합류했다. 2008년, KDE e.V.와 독일 위키미디어는 프랑크푸르트에 공동 사무실을 열었으며, 이는 KDE e.V.의 첫 직원 고용을 기록했다. 이후 조직은 유럽 자유 소프트웨어 재단(FSFE)과의 협력을 통해 사무실을 베를린으로 이전했다.

2010년, KDE e.V.는 시간적 헌신 없이 개인이 후원 회원이 될 수 있도록 독려하는 이니셔티브인 "Join the Game" 캠페인을 시작했다. FSFE의 창립자인 게오르크 그레베가 가장 먼저 가입했다.

 조직 

KDE e.V.에는 활동 회원, 특별 회원 및 후원 회원의 세 가지 유형의 멤버십이 있다. 자연인과 법인 모두 회원이 될 수 있다. 활동 회원은 KDE 커뮤니티에 기여한 사람들이다. 후원 회원은 재정적 기부를 통해 KDE를 지원하며, basysKom GmbH, Digia, 시리우스 코퍼레이션, 구글 등으로 구성된다. KDE의 후원자(Patron)는 후원 회원의 최고 단계로, SUSE, Klarälvdalens Datakonsult AB, 노키아 등이 있다. 협회의 모든 회원은 총회에 초대된다. 총회는 종종 Akademy의 일부로 개최된다.

이사회는 협회의 운영을 책임진다. 이사회는 총회에서 선출된 5명의 위원으로 구성된다. KDE e.V. 사무실은 베를린에 위치해 있다. 비즈니스 매니저라고 불리는 1명의 유급 행정 직원이 있다. 비즈니스 매니저는 일상적인 운영, 자원 확보 및 인턴 관리를 전담한다. KDE e.V.는 자격을 갖춘 학생들에게 인턴십 기회를 제공한다. 스페인에서 KDE e.V.의 공식 대표는 KDE España다. KDE e.V.는 FSFE의 제휴 조직이며 오픈 인벤션 네트워크의 라이선스 사용자다.

 활동 
KDE e.V.는 개발자 스프린트, Camp KDE 및 Akademy를 포함한 행사들을 조직하고 보조금을 지원한다. 또한 KDE 커뮤니티와 관련된 법적 문제를 처리한다.

워킹 그룹은 KDE 내의 일부 역할을 공식화하고 KDE 내부의 조정 및 각 부분 간의 의사소통을 강화하기 위한 구조다. 현재 활동 중인 워킹 그룹으로는 커뮤니티 워킹 그룹(CWG), 마케팅 워킹 그룹(MWG), 시스템 관리(sysadmin)가 있다. 해체된 워킹 그룹은 인간-컴퓨터 상호작용 워킹 그룹(HCI WG)과 기술 워킹 그룹(TWG)이다.

시스템 관리 워킹 그룹은 KDE 서버의 관리를 책임진다. 마케팅 워킹 그룹은 2005년 11월에 설립되어 마케팅 및 홍보 조정을 돕는다. 현재 멤버는 트로이 언라우, 프란츠 케퍼뵈크, 웨이드 올슨이다. 커뮤니티 워킹 그룹은 2008년 8월에 설립되어 필요할 때 커뮤니티 조언을 돕는다.

기술 워킹 그룹은 계획 및 릴리스를 조정하기 위한 것이다. 또한 어떤 소프트웨어를 KDE에 포함하거나 제거할지 결정하며, 서로 다른 프로그램이 모듈로 결합되는 방식과 모듈 간 및 외부 소프트웨어와의 의존성 허용 여부를 결정한다. 추가적인 과업으로, 프로젝트 개발자와 제작자 사이에서 KDE와 관련된 일반적인 기술적 질문에 대한 연락 창구 역할을 한다. 1년 후, 기술 워킹 그룹은 KDE e.V.로부터 독립된 릴리스 팀으로 대체되었다.

 각주 

분류:KDE
분류:자유 소프트웨어 프로젝트 재단
아바히

아바히(Avahi)는 멀티캐스트 DNS 및 DNS 서비스 검색 시스템을 포함하는 자유 소프트웨어 Zeroconf 구현체이다. GNU 약소 일반 공중 사용 허가서(LGPL)에 따라 라이선스가 부여된다.

아바히는 프로그램이 로컬 네트워크에서 실행 중인 서비스와 호스트를 게시하고 검색할 수 있도록 하는 시스템이다. 예를 들어, 사용자가 컴퓨터를 네트워크에 연결하면 아바히가 해당 기기에서 실행 중인 네트워크 서비스를 자동으로 알리게 하여 사용자가 해당 서비스에 쉽게 접근할 수 있도록 돕는다.

 소프트웨어 구조 
섬네일|right|아바히 소프트웨어 프레임워크의 아키텍처 개요

아바히는 애플의 Zeroconf 규격, mDNS, DNS-SD 및 RFC 3927/IPv4LL을 구현한다. 다른 구현체로는 애플의 봉주르 프레임워크가 있으며(mDNSResponder 구성 요소는 아파치 라이선스로 제공됨), 아바히는 이를 대체할 수 있도록 설계되었다.

아바히는 다양한 언어 바인딩(파이썬, 모노 등)을 제공하며 대부분의 리눅스 및 BSD 배포판에 포함되어 있다. 모듈화된 아키텍처 덕분에 그놈 가상 파일 시스템 및 KDE 입출력 아키텍처와 같은 주요 데스크톱 구성 요소에 이미 통합되어 있다.

 아바히 대 봉주르 
아바히 프로젝트는 2004년에 시작되었는데, 당시 애플의 Zeroconf 구현체인 봉주르가 GPL과 호환되지 않는 애플 공공 소스 라이선스를 사용했기 때문이다. 2006년 애플은 봉주르의 일부를 아파치 라이선스로 재라이선스했다.

아바히의 성능은 봉주르와 비슷하며 때로는 이를 능가하기도 한다. 하지만 아바히는 많은 수의 요청을 동시에 관리할 때 서비스를 놓치는 경우가 발생할 수 있다.

 역사 
아바히는 레나르트 페터링과 트렌트 로이드에 의해 개발되었다. 이는 2005년에 페터링의 원래 mDNS/DNS-SD 구현체인 "FlexMDNS"와 로이드의 원래 코드인 "아바히"가 합병된 결과물이다. 오늘날 코드의 대부분은 전자의 프로젝트에서 유래했지만, 공동 프로젝트의 이름은 후자의 것을 사용했다. "FlexMDNS" 개발은 2004년 말에 시작되었고, 원래 "아바히" 작업은 2004년 초에 시작되었다.

아바히는 원래 Freedesktop.org 산하에서 개발되었으나 현재는 별도의 프로젝트가 되었다. 그러나 아바히는 여전히 Freedesktop.org의 D-Bus IPC 계층을 활용한다.

아바히라는 이름은 마다가스카르 토착 영장류 가족인 양털여우원숭이 속의 말라가시어 이름이자 학명이다. 트렌트 로이드가 이 이름을 찾아내어 마음에 들어 했고, 그것이 프로젝트 이름으로 굳어졌다. 로고에도 이 동물이 반영되어 있다.

 같이 보기 
 리눅스 온 더 데스크톱
 LDAP
 네트워크 정보 서비스
 OSGi 연합

 각주 

 외부 링크 
 
 linux.conf.au 2007에서 페터링과 로이드가 진행한 발표 및 슬라이드

분류:KDE
분류:그놈
분류:Freedesktop.org
분류:자유 네트워크 소프트웨어
분류:C로 작성된 자유 소프트웨어
분류:LGPL 라이선스 소프트웨어
Fontconfig

Fontconfig(폰트콘피그)는 다른 프로그램에 글꼴의 설정, 나열 및 글꼴 대체 기능을 제공하도록 설계된 자유 소프트웨어 프로그램 라이브러리이다. Fontconfig는 원래 키스 패커드가 작성하고 유지 관리했으며, 현재는 베흐다드 에스파보드가 유지 관리를 맡고 있다.

Fontconfig는 일반적으로 Xorg 및 Wayland와 같은 그래픽 중심의 리눅스 (및 기타 유닉스 계열) 데스크톱에서 사용되며, 글꼴 처리의 중요한 부분으로 남아 있다. 그러나 때때로 다른 플랫폼에서도 사용되는데, 특히 김프와 같이 텍스트 레이아웃 및 렌더링을 위해 Pango를 사용하는 소프트웨어의 마이크로소프트 윈도우 버전 등에 포함된다.

 사용법 
최종 사용자는 시스템의 글꼴을 사용자 정의하고 설정하기 위해 직접 또는 간접적으로 fontconfig를 사용할 수 있다.

애플리케이션은 두 가지 방식으로 fontconfig를 사용할 수 있다.
 시스템에서 사용 가능한 글꼴을 쿼리(질의)하거나,
 특정 매개변수(패턴으로 구성됨)와 최대한 가깝게 일치하는 글꼴을 쿼리한다.

글꼴 일치를 수행하기 위해 fontconfig는 폰트 패밀리, 스타일, 두께, 도트 퍼 인치(DPI), 유니코드 지원 범위 등을 포함하여 설치된 모든 글꼴에 대한 조판 정보를 저장한다. 이 정보는 글꼴 대체를 수행하는 데에도 사용된다.

 설정 
Fontconfig는 설정 파일에 XML 형식을 사용한다. fontconfig 파일의 문서 형식 정의(DTD)는 일반적으로 /etc/fonts/fonts.dtd에 위치한다.

마스터 설정 파일(보통 /etc/fonts/fonts.conf)은 존재할 수도 있고 존재하지 않을 수도 있는 몇 가지 다른 설정 위치를 참조한다.
 /etc/fonts/fonts.conf
 /etc/fonts/conf.d
 $XDG_CONFIG_HOME/fontconfig/conf.d
 $XDG_CONFIG_HOME/fontconfig/fonts.conf
 ~/.fonts.conf.d
 ~/.fonts.conf

설정 파일의 간단한 예시는 다음과 같다.

true

 유틸리티 
Fontconfig에는 글꼴과 시스템의 글꼴 설정을 관리하고 쿼리하기 위한 8가지 명령줄 유틸리티가 함께 제공된다.
 fc-list: fontconfig가 알고 있는 모든 글꼴 또는 패턴과 일치하는 모든 글꼴을 나열한다.
 fc-match: 일반적인 fontconfig 일치 규칙을 사용하여 사용 가능한 가장 적절한 글꼴을 찾기 위해 글꼴 패턴(기본적으로 빈 패턴)을 일치시킨다.
 fc-cache: 지정된 디렉터리에 있는 모든 FreeType 읽기 가능 글꼴의 캐시를 생성하거나, 설정 파일에 지정된 모든 디렉터리에서 FreeType 읽기 가능 글꼴의 캐시를 생성한다.
 fc-cat: 캐시 파일 또는 글꼴 디렉터리와 관련된 글꼴 정보를 읽고 이를 ASCII 형식으로 출력한다.
 fc-query: 글꼴 파일을 쿼리하고 결과 패턴을 보고한다.
 fc-scan: 글꼴 파일과 디렉터리를 스캔하고 결과 패턴을 보고한다.
 fc-pattern: 제공된 패턴과 일치하는 최적의 글꼴을 나열한다.
 fc-validate: 글꼴 파일을 검증하고 결과를 보고한다.

 같이 보기 
 프리타입
 X 논리 글꼴 기술
 Xft

 각주 

 외부 링크 
 fontconfig 웹사이트
 fontconfig 매뉴얼
 오픈 소스 시스템을 위한 글꼴 설정 및 사용자 정의 (PDF)

분류:유닉스 소프트웨어
분류:C로 작성된 자유 소프트웨어
분류:MIT 라이선스 소프트웨어
하프버즈

하프버즈(HarfBuzz, 페르시아어 번역차용 harf-bāz의 느슨한 음차, 문자 그대로는 "오픈 타입")는 유니코드 텍스트를 자체 인덱스 및 위치로 변환하는 과정인 텍스트 셰이핑을 지원하기 위한 소프트웨어 라이브러리다. 최신 버전인 New HarfBuzz(2012년~현재)는 다양한 글꼴 기술을 대상으로 하는 반면, 첫 번째 버전인 Old HarfBuzz(2006~2012년)는 오픈타입 글꼴만을 대상으로 했다.

 역사 

하프버즈는 원래 프리타입 프로젝트의 일부였던 코드에서 발전했다. 그 후 Qt와 Pango에서 별도로 개발되었다가, 다시 MIT 허가서를 가진 공통 저장소로 통합되었다. 이것이 Old HarfBuzz이며, 현재는 New HarfBuzz가 개발 경로를 이어받으면서 더 이상 개발되지 않는다. 2013년, 베다드 에스파보드는 하프버즈에 대한 공로로 오라일리 오픈 소스 어워드를 수상했다.

New HarfBuzz의 주요 이정표는 다음과 같다:
 0.9.2, SIL 그래파이트 지원
 1.0, 마이크로소프트의 유니버설 셰이핑 엔진(Universal Shaping Engine) 개념 포함
 1.4, 오픈타입 가변 글꼴 지원
 1.6, 유니코드 10 지원
 1.8, 유니코드 11 지원
 2.0, 애플 어드밴스드 타이포그래피(AAT) 셰이핑 지원.
 2.1, 컬러 글꼴 지원 및 주요 AAT 셰이핑 기능 개선
 2.4, 유니코드 12 지원
 2.6.7, 유니코드 13 지원
 3.0, 안정적인 글꼴 서브세터 API, 유니코드 14 지원
 4.0, 65,536개 이상의 자체 및 메트릭 지원
 4.3, 대폭적인 속도 향상
 5.0, BE 글꼴 지원
 5.2, 유니코드 15 지원
 7.0, 새로운 API, 새로운 명령줄 유틸리티, 글꼴 엠볼드닝(emboldening) 지원 및 메모리 사용량 감소 도입
 8.0, 글꼴에 내장된 웹어셈블리 기반 셰이퍼 사용 지원 도입

 사용자 
대부분의 애플리케이션은 하프버즈를 직접 사용하지 않고, 하프버즈가 통합된 UI 툴킷 라이브러리를 사용한다.

하프버즈를 사용하는 UI 라이브러리는 다음과 같다:

 그놈 (GTK)
 KDE (Qt)
 크롬OS (Skia)
 플레이스테이션 4
 안드로이드
 자바
 플러터
 고도 (4.0 버전부터)
 유니티 (6.0 버전부터)
 오픈하모니 (훙멍)

하프버즈를 직접 사용하는 애플리케이션은 다음과 같다:

 크로미엄
 파이어폭스
 리브레오피스 (리눅스 전용 4.1 버전부터, 모든 플랫폼에서 5.3 버전부터)
 스크라이버스 (1.5.3 버전부터)
 잉크스케이프
 어도비 포토샵 (23.0 버전부터)
 어도비 인디자인 (인디자인 19.0부터 월드 레디 컴포저(World Ready Composer) 사용 시)
 피그마
 XeTeX (0.9999 버전부터)
 LuaTeX (1.11.1 버전부터)
 쿼크익스프레스

 같이 보기 
 그래파이트, SIL International에서 개발한 프로그래밍 가능한 유니코드 호환 스마트 폰트 기술 및 렌더링 시스템
 유니스크라이브 및 다이렉트라이트, 마이크로소프트 윈도우 플랫폼에서 유사한 기능을 제공하는 API
 Core Text, macOS에서 유사한 기능을 제공하는 API (macOS에서도 대신 하프버즈를 사용할 수 있음)

 각주 

 외부 링크 
 
 Old Harfbuzz

분류:디지털 타이포그래피
분류:Freedesktop.org
분류:C로 작성된 자유 소프트웨어
분류:MIT 라이선스 소프트웨어
분류:자유 라이브러리
텔레파시 (소프트웨어)

텔레파시(Telepathy)는 인스턴트 메신저, 음성 인터넷 프로토콜 또는 화상 회의와 같은 대인 통신용 소프트웨어를 만드는 데 사용할 수 있는 소프트웨어 프레임워크다. 텔레파시는 D-Bus 프로세스 간 통신 메커니즘을 통해 구성 요소를 사용하여 통신 애플리케이션을 생성할 수 있게 해준다. 이를 통해 애플리케이션과 기본 네트워크 프로토콜 사이에 논리적 경계를 정의함으로써 통신 애플리케이션의 개발을 단순화하고 자유 소프트웨어 및 오픈 소스 커뮤니티 내에서 코드 재사용을 촉진하는 것을 목표로 한다.

 구현 
텔레파시 인터페이스를 내보내는 다양한 프로토콜의 자유 소프트웨어 구현체가 존재한다:

 Gabble: 징글 지원을 포함한 XMPP용
 Butterfly: 윈도우 라이브 메신저용
 Idle: IRC용
 Salut: 링크 로컬 MPP 프로토콜용
 Haze: 피진 메시징 클라이언트에서 사용하는 라이브러리인 libpurple이 지원하는 프로토콜에 접근하기 위한 용도. 이는 2007년 구글 서머 오브 코드 프로젝트로 수행되었다.
 Spirit: 노키아 N900 및 노키아 N9의 스카이프 프로토콜용
 Rakia: 노키아의 오픈 소스 Sofia-SIP 라이브러리를 사용하는 세션 개시 프로토콜(SIP)용
 Morse: 텔레그램용

미션 컨트롤(Mission Control)은 엔드 유저 애플리케이션이 연결 관리자와 같은 저수준 텔레파시 구성 요소의 일부 세부 사항을 추상화할 수 있는 방법을 제공하는 구성 요소의 이름이다.

튜브(Tubes)는 임의의 데이터 전송 및 원격 IPC를 지원하기 위한 텔레파시의 메커니즘이다.

텔레파시는 노키아 770, N800, N810, N900, N9 및 욜라 기기들의 인스턴트 메시징 및 음성/영상 통화 소프트웨어의 기반을 형성한다.

 작동 원리 
프로토콜 구현체는 연결 관리자라고 불리는 D-Bus 서비스를 제공한다. 텔레파시 클라이언트는 이를 사용하여 서비스에 대한 연결을 생성한다. 연결이 설정되면, 연결에 요청된 채널이라는 객체를 사용하여 추가 통신이 이루어진다. 채널은 텍스트 메시지를 주고받거나, 연락처 목록을 나타내거나, VoIP 통화를 설정하는 데 사용될 수 있다.

 애플리케이션 
 엠퍼시
 KDE 텔레파시
 슈거

 같이 보기 
 Farstream (이전 명칭 Farsight)

 각주 

 외부 링크 
 프로젝트 웹사이트
 "IM/VOIP Communications Framework" 수석 개발자 로버트 맥퀸(Robert McQueen)의 텔레파시 관련 강연 비디오 다운로드 (77MB ogg). 스트리밍 플래시 비디오.
 KDE-Telepathy 현재 0.9.0
 텔레파시 개발자 매뉴얼

분류:Freedesktop.org
분류:자유 네트워크 소프트웨어
사운드 주서

사운드 주서(Sound Juicer)는 그놈의 공식 CD 리퍼 프로그램이다. 광학 디스크를 읽고 쓰기 위해 GTK, GStreamer, libburnia를 기반으로 한다. 광학 오디오 디스크에서 오디오 트랙을 추출하여 개인용 컴퓨터나 디지털 오디오 플레이어에서 재생할 수 있는 오디오 파일로 변환할 수 있다. Opus, MP3, Ogg Vorbis, FLAC 및 비압축 PCM 형식과 같이 GStreamer 플러그인이 지원하는 모든 오디오 코덱으로의 리핑을 지원한다. 2.12 이후 버전에서는 CD 재생 기능이 구현되었다. 최신 버전들은 기본 GStreamer 설정을 사용하여 손실 압축 형식을 생성한다.

사운드 주서는 사용하기 쉽고 사용자의 개입을 최소화하도록 설계되었다. 예를 들어, 컴퓨터가 인터넷에 연결되어 있으면 자유롭게 이용 가능한 뮤직브레인즈 서비스를 통해 트랙 정보를 자동으로 가져오려고 시도한다. 사운드 주서는 GNU GPL 조건에 따른 자유-오픈 소스 소프트웨어이다. 버전 2.10부터 그놈의 공식 구성 요소가 되었다.

 같이 보기 
 fre:ac

 각주 

 외부 링크 
 

분류:자유 오디오 소프트웨어
분류:C로 작성된 자유 소프트웨어
분류:GPL 라이선스 소프트웨어
그놈 사운드컨버터

그놈 사운드컨버터(GNOME SoundConverter)는 디지털 오디오 파일을 위한 비공식 그놈 기반 자유-오픈 소스 소프트웨어 트랜스코더이다. 입력 및 출력 파일 처리에 GStreamer를 사용한다. 멀티스레드 설계를 갖추고 있으며 비디오 파일에서 오디오를 추출할 수도 있다.

오래전부터 데비안, 페도라, 오픈수세, 우분투, 젠투 리눅스, 아치 리눅스를 포함한 많은 리눅스 배포판의 저장소에서 사용할 수 있다.

 기능 
 사용자 정의 패턴 또는 미리 정의된 패턴을 기반으로 파일 이름 변경
 태그 또는 선택한 위치에 따라 폴더 생성
 원본 파일 삭제 가능
 비트레이트 조절
 원본 파일에서 이미지를 포함한 모든 메타데이터 가져오기

 같이 보기 
 OggConvert

 각주 

 외부 링크 

 

분류:자유 오디오 소프트웨어
분류:2004년 소프트웨어
분류:파이썬으로 작성된 자유 소프트웨어
분류:GPL 라이선스 소프트웨어
칸타렐 유전

칸타렐 유전(Cantarell Field) 또는 칸타렐 단지(Cantarell Complex)는 멕시코에 위치한 노후화된 초거대 해상 유전이다. 1972년 어부인 루데신도 칸타렐 히메네스가 기름띠를 발견한 후, 1976년에 유전이 발견되었다. 2000년부터 질소 주입 공법이 도입되었으며, 2004년에 하루 210만 배럴(330,000 m3/d)의 생산량으로 정점에 도달했다. 현재까지의 누적 생산량 측면에서 멕시코 최대이자 세계에서 가장 큰 유전 중 하나였다. 그러나 2004년 이후 생산량이 감소하기 시작하여 2022년에는 하루 158,300 배럴(25,200 m3/d)로 떨어졌다. 2009년에는 쿠-말로브-자프 유전이 멕시코 최대 유전 자리를 대체하게 되었다.

 위치 
칸타렐은 캄페체만 해안에서 떨어진 곳에 위치해 있다. 이 단지는 아칼(Akal, 가장 규모가 큼), 노호치(Nohoch), 착(Chac), 쿠츠(Kutz)의 네 가지 주요 유전으로 구성된다. 저류층은 백악기 후기의 탄산염 각력암으로 형성되었으며, 이는 칙술루브 충돌구를 형성한 소행성 충돌 당시의 파편들이다. 최근 발견된 시힐(Sihil) 유전(1억 5천만~150억 배럴 규모)은 다른 저류층 아래의 쥐라기 지층에 경질유를 포함하고 있으며, 일반적으로 별개의 유전으로 간주되나 개발 시 기존 인프라를 활용할 수 있다. 칸타렐의 석유 생산은 2004년에 정점에 도달한 이후 계속 감소하고 있으며, 향후 더 큰 감소가 예상된다.

 지질 
칙술루브 충돌체는 칙술루브 충돌구와 그에 따른 탄산염 파편 각력암을 생성했으며, 이것이 비야에르모사 주변과 칸타렐 단지가 위치한 캄페체만 일대 유전의 석유 저류층이 되었다.
약 1500m 깊이 저류층의 공극률은 8%~12%이며, 입자 크기에 따라 유닛 1(조립질)과 유닛 2(세립질)로 나뉘고, 그 위를 유닛 3이라 불리는 셰일질 분출물 층이 덮어 덮개암 역할을 하고 있다.

충돌 이후 탄산염 대지가 붕괴되면서 조립질 각력암이 퇴적되었고, 그 뒤를 이어 발생한 쓰나미에 의해 세립질 각력암이 혼합되어 그 위를 덮었다. 마이오세 초부터 플라이오세 사이에 습곡 작용이 일어났으며, 압축력으로 인해 백악기 및 쥐라기 후기 블록들이 밀려 올라가면서 구조 트랩이 형성되었고, 마이오세에 탄화수소가 이곳으로 이동했다. 칸타렐 단지에는 아칼, 노호치, 착, 쿠츠의 네 개 블록이 있으며, 아칼 블록 아래에는 1998년에 석유가 발견된 다섯 번째 블록인 시힐이 존재한다.

 생산 이력 

1981년까지 칸타렐 유전는 하루 116만 배럴(180,000 m3/d)를 생산했다. 그러나 1995년 생산량은 하루 1백만 배럴(160,000 m3/d)로 떨어졌다. 아타스타 캄페체에 설치된 세계 최대 규모의 질소 공장을 포함한 질소 주입 프로젝트가 2000년에 가동을 시작하면서 생산량은 2002년에 하루 190만 배럴(300,000 m3/d)에서 2003년에는 210만 배럴(330,000 m3/d)로 증가했다. 이는 당시 칸타렐을 사우디아라비아의 가와르 유전에 이어 세계에서 두 번째로 생산량이 많은 유전으로 만들었다. 하지만 칸타렐은 가와르보다 매장량이 훨씬 적었기에 2000년대 후반부터 생산량이 급격히 감소하기 시작했다. 불행히도 주입된 질소가 가스층으로 유입되면서 가스의 열량과 경제적 가치가 낮아졌으며, 연료로 사용하기 위해서는 질소 제거 공정이 필요한 상황이다.

페멕스의 탐사 및 생산 부문 책임자인 루이스 라미레스 코르소는 2004년 8월 12일, 칸타렐의 실제 석유 생산량이 2006년부터 매년 14%씩 급격히 감소할 것이라고 발표했다. 2006년 3월 보고에 따르면 칸타렐은 이미 정점에 도달했으며 2005년에 이미 2년 연속 생산량 감소를 보였다. 페멕스의 총책임자인 헤수스 레예스 헤롤레스에 따르면 2006년 해당 유전의 생산량은 13.1% 감소했다.

2008년 7월, 일일 생산량은 전년 동기의 152만 6천 배럴(243×103 m3/d)에서 973,668 배럴(155,000 m3/d)로 36% 급락했다. 분석가들은 이러한 급격한 감소가 유전의 수명을 희생하면서 단기 생산량을 늘리려 했던 생산 증진 기술의 결과라고 이론화했다. 2009년 1월까지 칸타렐의 생산량은 77만 2천까지 떨어졌는데, 이는 1년 만에 38%가 감소한 것이다. 이로 인해 멕시코 전체 석유 생산량도 9.2% 감소하며 5년 연속 하락세를 이어갔다.

2008년 페멕스는 칸타렐의 감소세가 2012년까지 계속되다가 하루 약 500,000 배럴(80,000 m3/d) 수준에서 안정화될 것으로 예상했다. 그러나 2009년 9월에 이미 이 수치에 도달했으며, 이는 석유 산업 역사상 가장 극적인 급감 사례 중 하나로 기록되었다. 이후 생산량이 하루 40만 배럴(60,000 m3/d)에서 안정될 것으로 보였으나, 2012년 4월에는 하루 40만 8천 배럴(60,000 m3/d)까지 감소했다. 이러한 생산 차질은 멕시코 정부의 연간 예산과 국가 신용 등급에 부정적인 영향을 미쳤다. 생산량은 계속 줄어들어 2014년 6월에는 하루 34만 배럴을 기록했다. 페멕스는 감소를 저지하고 향후 10년 동안 생산량을 하루 32만 5천 배럴 수준으로 유지하기 위해 2017년까지 60억 달러를 투자할 계획을 세웠으나, 감소세는 멈추지 않아 2019년에는 하루 159,300배럴까지 떨어졌다.

캄페체만에서의 중질유 생산을 유지하기 위해 페멕스는 칸타렐의 기존 시설과 연결 가능한 인접 지역의 쿠-말로브-자프 단지 개발에 역량을 집중하고 있다. 쿠-말로브-자프 단지는 2010년대 말까지 하루 80만 배럴(130,000 m3/d)를 생산할 것으로 예상되었다. 2009년, 쿠-말로브-자프는 칸타렐을 대신해 멕시코에서 가장 생산적인 유전이 되었다.

 같이 보기 
 유전 목록
 멕시코의 석유 산업

 각주 

 외부 링크 
 Peak Oil is Now Official - 트레이 쇼네시, 2006년 3월 18일.
 Mexico Oil Production going down January 2007 
 Cantarell 주요 데이터
 Rigzone의 생산량 감소 관련 기사
 Cantarell is Dying (기사)

분류:페멕스
분류:석유
분류:유전
분류:멕시코의 에너지
탱고 데스크톱 프로젝트

섬네일|탱고 데스크톱 프로젝트의 색상 팔레트

탱고 데스크톱 프로젝트(Tango Desktop Project)는 일련의 디자인 가이드를 만들고 데스크톱 환경의 애플리케이션에 일관된 사용자 경험을 제공하기 위한 오픈 소스 구상이었다. 이 프로젝트는 탱고 아이콘 라이브러리(Tango Icon Library)로 알려진 일련의 아이콘들을 만들었으며, 이는 "개념 증명"으로 설명되었다. 탱고 데스크톱 프로젝트는 freedesktop.org의 프로젝트였으며, 표준 아이콘 테마 규격(Standard Icon Theming Specification)과 같은 다른 freedesktop.org 가이드라인과 밀접하게 연관되어 있었다.

 목표 
프로젝트의 목표는 소프트웨어 개발자들이 외관 측면에서 자신의 소프트웨어를 데스크톱 컴퓨터와 쉽게 통합할 수 있도록 하는 것이었다. 서로 다른 데스크톱 환경(KDE, 그놈, 또는 Xfce 등)과 커스텀 배포판으로 인해 발생하는 시각적 불일치는 제3자가 리눅스를 대상으로 개발하는 것을 어렵게 만든다. 이상적으로, 탱고 가이드라인을 따르는 모든 프로젝트는 해당 가이드라인을 따르는 다른 아이콘 및 애플리케이션과 잘 어울리는 룩 앤드 필을 갖게 된다.

이 스타일은 자신을 차별화하기 위해 시각적으로 독특해지는 것을 목표로 하지 않았다. 대신, 프로젝트의 부수적인 목표는 당시 일반적인 운영 체제에서 애플리케이션이 적절하게 보이도록 하는 표준 스타일을 만드는 것이었다. 이를 통해 독립 소프트웨어 개발 판매 회사들이 자신들의 애플리케이션이 윈도우 XP, Mac OS X, KDE, 그놈 또는 Xfce에서 어색해 보이지 않는다는 것을 알 수 있게 하려 했다.

시각적 가이드라인 외에도, 이 프로젝트는 아이콘에 대한 공통적인 은유(metaphor) 세트를 제공하는 것을 목표로 했다. 탱고는 freedesktop.org의 표준 아이콘 테마 규격을 따랐으며, 가장 일반적인 아이콘의 이름과 사용되는 은유를 정의하는 freedesktop.org의 표준 아이콘 명명 규격(Standard Icon Naming Specification)을 적극적으로 개발했다.

김프, 스크라이버스, 그놈과 같은 많은 자유 소프트웨어 프로젝트들이 그들의 아이콘에 탱고 스타일 가이드라인을 따르기 시작했다. 또한 ReactOS는 탱고 아이콘을 사용하며, 모질라 파이어폭스 3는 사용자가 설치한 아이콘 세트를 찾을 수 없거나 해당 아이콘 세트에 포함되지 않은 아이콘의 경우에 탱고 아이콘을 사용한다.

독점 소스 비공개 애플리케이션도 탱고 데스크톱 프로젝트 아이콘을 사용할 수 있다. 탱고 쇼룸(Tango Showroom)에서 강조된 예시로는 VM웨어 워크스테이션 6와 Medsphere OpenVista CIS가 있다.

 역사 
탱고 아이콘은 원래 카피레프트 크리에이티브 커먼즈 라이선스(저작자표시-동일조건변경허락)로 배포되었으나, 재사용을 더 쉽게 만들기 위해 2009년에 퍼블릭 도메인으로 배포되었다.

 팔레트 
다음은 탱고 데스크톱 프로젝트에서 사용되는 십육진법 색상 팔레트이며, 색상 그룹과 밝기에 따라 구성되어 있다:

 같이 보기 
 Adwaita (디자인 언어) – 그놈의 디자인 언어
 Bluecurve – 이전 페도라의 기본 GPL 아이콘 세트, Echo로 대체됨
 Crystal – 에베랄두 코엘류의 LGPL 아이콘 세트
 아이콘
 Nuvola – 다비데 비뇨니의 LGPL 아이콘 세트
 옥시즌 프로젝트 – KDE용 LGPL 아이콘 세트
 팔레트 (컴퓨팅)
 테마 (컴퓨팅)
 ReactOS – 탱고 아이콘 라이브러리 사용

 각주 

 외부 링크 

 
 탱고 아이콘 라이브러리 버전 0.8.90 — tar.gz 아카이브 형식
 "Tango project aims to clean up the desktop" - Linux.com
 표준 아이콘 테마 규격
 아이콘 명명 규격
 Tango Patcher 2600 8.06

분류:그놈
분류:자유 소프트웨어 프로젝트
분류:Freedesktop.org
분류:커뮤니케이션 디자인
분류:2009년 소프트웨어
분류:그래픽스
분류:아이콘
그놈 키링

그놈 키링(GNOME Keyring)은 소량의 관련 메타데이터와 함께 사용자 이름, 비밀번호, 키와 같은 보안 자격 증명을 저장하도록 설계된 소프트웨어 응용 프로그램이다. 민감한 데이터는 암호화되어 사용자의 홈 디렉토리에 있는 키링 파일에 저장된다. 기본 키링은 암호화를 위해 로그인 비밀번호를 사용하므로 사용자는 다른 비밀번호를 기억할 필요가 없다.

2009년 기준으로 그놈 키링은 운영 체제 오픈솔라리스의 데스크톱 환경 일부였다.

그놈 키링은 데몬으로 구현되며 gnome-keyring-daemon이라는 프로세스 이름을 사용한다. 응용 프로그램은 더 이상 사용되지 않는 libgnome-keyring 라이브러리를 대체하는 libsecret 라이브러리를 사용하여 비밀번호를 저장하고 요청할 수 있다.

그놈 키링은 그놈 데스크톱의 일부이다. 2006년 기준으로 WEP 비밀번호를 저장하기 위해 네트워크매니저와 통합되었다. 그놈 웹과 이메일 클라이언트인 Geary는 비밀번호를 저장하는 데 그놈 키링을 사용한다.

그놈 키링이 존재하는 시스템에서 발라로 작성된 소프트웨어는 이를 사용하여 비밀번호를 저장하고 검색할 수 있다. 그놈 키링 매니저(gnome-keyring-manager)는 그놈 키링을 위한 최초의 사용자 인터페이스였다. 그놈 2.22부터는 더 이상 사용되지 않으며 Seahorse로 완전히 대체되었다.

 같이 보기 
 비밀번호 관리자 목록
 KWallet
 애플 키체인
 네트워크매니저
 Seahorse (소프트웨어)

 각주 

 외부 링크 
 

분류:그놈
분류:C로 작성된 자유 소프트웨어
분류:GPL 라이선스 소프트웨어
Librsvg

librsvg 또는 LibRsvg는 그놈 프로젝트의 일부로 작성된 자유 소프트웨어 SVG 렌더링 라이브러리이며, 경량화와 이식성을 목표로 한다. 리눅스 명령줄 프로그램인 rsvg-convert는 이 라이브러리를 사용하여 SVG 파일을 래스터 이미지로 변환한다.

 백엔드 
librsvg는 파일 읽기부터 화면 렌더링까지의 작업을 수행하기 위해 두 개의 다른 라이브러리를 사용한다.
 libxml은 SVG 파일의 XML 표현을 라이브러리가 빠르게 접근할 수 있는 형태로 구문 분석하는 데 사용된다.
 카이로는 libxml에서 얻은 정보를 랜덤 액세스 메모리의 블록으로 렌더링하는 데 사용된다.

v2.41.0 이후로 많은 부분이 러스트로 재작성되었다.

 도입 
librsvg는 그놈 데스크톱 환경을 위해 개발되었으며 이에 따라 그놈 파일과 그놈 루페에서 사용되지만, 다른 소프트웨어 애플리케이션에서도 사용될 수 있도록 의도되었다. 주목할 만한 사례로, 위키미디어 재단이 호스팅하는 위키들은 SVG 이미지를 렌더링하기 위해 librsvg를 사용한다. 미디어위키에 따르면, 과거에 이 웹 애플리케이션들을 위해 librsvg가 선택된 이유는 "빠르지만 아주 정확하지는 않기" 때문이었다. 2025년 3월 기준, 위키백과와 위키미디어 공용은 SVG를 PNG로 렌더링하기 위해 librsvg 2.54 버전을 사용하고 있다.

2005년에 카이로 벡터 렌더링 엔진으로 전환하면서, librsvg는 더 정확해지고 시각적으로 더 좋아졌다. 2012년부터 독립 개발자가 Win32 콘솔 포트인 를 배포했으며, 2017년 12월 기준 버전은 2.40.20이다. 의 매뉴얼 페이지도 온라인에서 확인할 수 있다.

 버전 역사 

 각주 

 외부 링크 
 
 다운로드 페이지
 Librsvg 참조 매뉴얼
 

분류:C 라이브러리
분류:그래픽 라이브러리
분류:SVG
분류:C로 작성된 자유 소프트웨어
OpenAPI 사양

OpenAPI 사양(OpenAPI Specification, 이전 명칭 스웨거 사양)은 웹 API를 기술, 생성, 소비 및 시각화하기 위한 기계 판독 가능 인터페이스 정의 언어에 대한 표준 사양이다. 원래 스웨거 프레임워크를 지원하기 위해 개발되었으나, 2015년에 리눅스 재단의 오픈 소스 협력 프로젝트인 OpenAPI 이니셔티브(OpenAPI Initiative)가 관리하는 별도의 프로젝트가 되었다.

OpenAPI 설명(OAD)은 도구가 코드, 문서, 테스트 케이스 등을 생성하는 데 사용할 수 있는 API의 공식적인 설명을 나타낸다.

 역사 
섬네일|리눅스 재단 산하에서 OpenAPI 사양을 개발하는 조직인 OpenAPI 이니셔티브의 로고
스웨거 개발은 2010년 초 온라인 사전 업체인 워드닉(Wordnik)에서 근무하던 토니 탐(Tony Tam)에 의해 시작되었다.

2015년 3월, 스마트베어 소프트웨어(SmartBear Software)는 워드닉의 모회사인 리버브 테크놀로지스(Reverb Technologies)로부터 오픈 소스 스웨거 API 사양을 인수했다.

2015년 11월, 스마트베어는 리눅스 재단의 후원 하에 OpenAPI 이니셔티브라는 새로운 조직에 스웨거 사양을 기부한다고 발표했다. 다른 창립 멤버 기업으로는 3스케일(3scale), 아피지(Apigee), 캐피털 원, 구글, IBM, 인튜이트, 마이크로소프트, 페이팔, 레스트릿(Restlet) 등이 포함되었다.

2016년 1월 1일, 스웨거 사양은 OpenAPI 사양(OAS)으로 명칭이 변경되었으며 새로운 깃허브 소프트웨어 저장소로 이전되었다.

2017년 7월, OpenAPI 이니셔티브는 사양의 3.0.0 버전을 출시했다.

2021년 2월, OpenAPI 이니셔티브는 3.1.0 버전을 출시했다. OpenAPI 사양 3.1.0의 주요 변경 사항으로는 JSON 스키마 어휘 정렬, 대역 외에서 등록 및 관리되는 웹훅을 기술하기 위한 새로운 최상위 요소, 표준 SPDX 식별자를 사용한 API 라이선스 식별 지원, 스키마 참조 사용과 함께 설명 허용, 컴포넌트의 재사용 가능한 라이브러리 생성을 단순화하기 위해 PathItems 객체를 선택 사항으로 변경한 것 등이 있다.

 형식의 통합 

뮤직소프트(MuleSoft)의 RESTful API Modeling Language(RAML)와 에이피어리(Apiary)의 API 블루프린트(API Blueprint)라는 두 가지 다소 유사한 기술이 당시 스웨거 사양이라 불리던 것과 비슷한 시기에 개발되었다.

두 형식의 제작자들은 나중에 OpenAPI 이니셔티브에 합류했다. 에이피어리는 2016년에, 뮤직소프트는 2017년에 합류했다. 두 곳 모두 OAS에 대한 지원을 추가했다.

 출시일 

 사용법 
OAS는 다양한 애플리케이션, 라이브러리 및 도구에서 사용할 수 있는 OpenAPI 설명(OAD)의 형식을 규정한다.

애플리케이션은 OAD를 사용하여 메서드, 매개변수 및 데이터 모델의 문서를 자동으로 생성할 수 있다. 이는 문서, 클라이언트 라이브러리 및 소스 코드를 동기화된 상태로 유지하는 데 도움이 된다.

OAD를 사용하여 서버용 소스 코드 스텁을 생성할 때, 이 과정을 스캐폴딩이라고 한다.

 소프트웨어 공학 관행과의 관계 
프로그램을 먼저 코딩한 후 그 동작을 나중에 계약으로 기술하는 것과 반대로, API 계약에 먼저 합의한 후 비즈니스 로직을 프로그래밍하는 패러다임을 계약 우선(contract-first) 개발이라고 한다. 코드가 작성되기 전에 인터페이스가 결정되므로, 다운스트림 개발자는 서버 동작을 모방하여 즉시 테스트를 시작할 수 있다. 이러한 의미에서 계약 우선 개발은 쉬프트 레프트(shift-left) 테스트의 관행이기도 하다.

 특징 
OpenAPI 사양은 언어에 구애받지 않는다. OpenAPI의 선언적 리소스 사양을 사용하면, 클라이언트는 서버 구현에 대한 지식이나 서버 코드에 대한 접근 없이도 서비스를 이해하고 소비할 수 있다.

 OpenAPI와 작동하는 도구 
OpenAPI 이니셔티브는 구현체 목록을 유지 관리한다.

 연례 컨퍼런스 
OpenAPI 이니셔티브는 매년 API 사양 컨퍼런스(API Specifications Conference, ASC)를 후원한다. 이 행사는 수년 동안 운영된 API 전략 및 관행 컨퍼런스(API Strategy and Practice Conference, APIStrat)에서 유래되었으며 2016년에 OpenAPI 이니셔티브의 일부가 되었다.

 같이 보기 
 표현 상태 전송
 GRPC
 데이터 모델링

 각주 

 참고 자료 

 
 

 외부 링크 
 OpenAPI 이니셔티브 (OAI) 메인 웹사이트
 OAI 사양 웹사이트
 OAI OpenAPI 학습 웹사이트
 OAI 도구 웹사이트
 깃허브의 OpenAPI 사양
 OpenAPI 설명 디렉터리

분류:마크업 언어
분류:소프트웨어 구조
분류:API
분류:JSON
데이터 매퍼 패턴

소프트웨어 공학에서 데이터 매퍼 패턴(data mapper pattern)은 아키텍처 패턴의 하나다. 마틴 파울러가 2003년에 펴낸 저서 《기업 애플리케이션 아키텍처 패턴》(Patterns of Enterprise Application Architecture)에서 이 이름을 명명했다. 이 패턴을 따르는 객체의 인터페이스는 데이터 저장소 내의 도메인 엔티티 유형을 나타내는 객체들에 대해 작동하는 생성(Create), 읽기(Read), 갱신(Update), 삭제(Delete)와 같은 함수를 포함한다.

데이터 매퍼는 영구 데이터 저장소(흔히 관계형 데이터베이스)와 인메모리 데이터 표현(도메인 계층) 사이에서 데이터의 양방향 전송을 수행하는 데이터 접근 계층이다. 이 패턴의 목적은 인메모리 표현과 영구 데이터 저장소가 서로 독립적이면서 데이터 매퍼 자체와도 독립성을 유지하도록 하는 것이다. 이는 영구 데이터 저장소와 깔끔하게 매핑되지 않는 도메인 계층의 데이터에 대해 엄격한 비즈니스 프로세스를 모델링하고 강제해야 할 때 유용하다. 이 계층은 데이터 전송을 수행하는 하나 이상의 매퍼(또는 데이터 접근 객체)로 구성된다. 매퍼 구현은 그 범위에 따라 다양하다. 범용 매퍼는 다양한 도메인 엔티티 유형을 처리하며, 전용 매퍼는 하나 또는 소수의 엔티티 유형을 처리한다.

 구현 
이 개념의 구현체는 다양한 프로그래밍 환경을 위한 여러 소프트웨어 프레임워크에서 찾아볼 수 있다.

 Java/.NET 
 마이바티스(MyBatis) 영속성 프레임워크
 하이버네이트(NHibernate) 영속성 프레임워크

 Node.js / TypeScript 
 Bookshelf.js 라이브러리
 TypeORM 라이브러리
 Massive.js 라이브러리
 Prisma
 Objection.js 라이브러리
 MikroORM 라이브러리
 LDkit - RDF 데이터 소스를 위한 객체 그래프 매퍼(OGM)

 PHP 
 Atlas ORM (데이터 매퍼, 테이블 데이터 게이트웨이, 쿼리 빌더 및 PDO 래퍼)
 Doctrine2 객체 관계 매핑(ORM) 및 데이터베이스 추상화 계층
 Cycle ORM (PHP 데이터 매퍼 ORM 및 데이터 모델링 엔진)
 CakePHP ORM (PHP 데이터 매퍼 ORM, 쿼리 빌더 및 PDO 래퍼)

 Perl 
 DBIx

 Python 
 SQLAlchemy 라이브러리
 mincePy 라이브러리

 Ruby 
 DataMapper 라이브러리 (실제로 이 라이브러리는 액티브 레코드 디자인 패턴을 구현했으며, 그 후속작인 DataMapper 2(현재 ROM)는 이름에 걸맞은 디자인 패턴을 실제로 구현하는 것을 목표로 함)

 Elixir 
 Ecto 영속성 프레임워크

 같이 보기 
 
 

 각주 

분류:소프트웨어 디자인 패턴
분류:아키텍처 패턴
서비스 로케이터 패턴

섬네일|서비스 로케이터 패턴의 UML 클래스 다이어그램.
서비스 로케이터 패턴(service locator pattern)은 소프트웨어 개발에서 강한 추상화 계층을 통해 서비스를 얻는 것과 관련된 프로세스를 캡슐화하는 데 사용되는 디자인 패턴이다. 이 패턴은 "서비스 로케이터"라고 불리는 중앙 레지스트리를 사용하며, 요청이 들어오면 특정 작업을 수행하는 데 필요한 정보를 반환한다. 이 패턴의 지지자들은 모든 의존성이 전체 애플리케이션 설계의 시작 부분에 깔끔하게 나열되는 컴포넌트 기반 애플리케이션에서 접근 방식이 단순해지며, 결과적으로 전통적인 의존성 주입이 객체를 연결하는 더 복잡한 방법이 될 수 있다고 말한다. 반면 비판론자들은 이 패턴이 의존성을 모호하게 만들고 소프트웨어 테스트를 어렵게 만드는 안티패턴이라고 주장한다.

 장점 
 "서비스 로케이터"는 간단한 실행 시간 링커 역할을 할 수 있다. 이를 통해 애플리케이션을 다시 컴파일하지 않고도 실행 시간에 코드를 추가할 수 있으며, 어떤 경우에는 애플리케이션을 재시작하지 않아도 된다.
 애플리케이션은 서비스 로케이터에서 항목을 선택적으로 추가하거나 제거함으로써 실행 시간에 스스로를 최적화할 수 있다. 예를 들어, 애플리케이션이 기본 라이브러리보다 JPG 이미지를 읽는 데 더 나은 라이브러리가 있음을 감지하고 그에 따라 레지스트리를 변경할 수 있다.
 라이브러리나 애플리케이션의 큰 부분을 완전히 분리할 수 있다. 이들 사이의 유일한 연결 고리는 레지스트리가 된다.
 애플리케이션은 특정 기능이나 테스트를 목적으로 하는 구조화된 서비스 로케이터를 여러 개 사용할 수 있다. 서비스 로케이터는 프로세스당 하나의 단일 정적 클래스를 강제하지 않는다.
 잘 구조화된 컴포넌트/서비스 설계를 갖춘 애플리케이션의 경우 의존성 주입보다 서비스 로케이터를 사용하는 솔루션이 더 단순할 수 있다. 이러한 경우 단점은 오히려 장점으로 간주될 수 있다(예: 모든 클래스에 다양한 의존성을 제공하고 의존성 구성을 유지 관리할 필요가 없음).
 서비스 위치 확인 프로세스는 특정 비즈니스 사례를 나타낼 수 있는 호출 범위/컨텍스트에 민감하게 만들 수 있다. 일반적으로 생성자 매개변수 전달을 통해 객체에 의존성을 공급하는 고정된 DI에 의존하는 대신, 필요에 따라 비즈니스 컨텍스트 내에서 서비스 위치 호출을 수행할 수 있다. 예를 들어, 서비스 로케이터 호출을 통해 얻은 "IShippingStrategy" 인스턴스를 호출하면서 무엇이 어디서 어디로 배송되는지를 명시하는 "ShippingContext"를 서비스 로케이터에 매개변수로 전달하여 서비스 로케이터가 최상의 사례(예: 패턴 매치 점수 사용)를 일치시키도록 할 수 있다. 이는 실행 시간에 동적으로 위치한 최적의 매칭 전략의 점수화를 통해 복잡한 의사결정이 이루어질 수 있는 복잡한 비즈니스 애플리케이션 아키텍처(예: 의료 스코어링 시스템, 라우팅)를 크게 단순화한다.

 단점 
 레지스트리는 클래스의 의존성을 숨기므로, 의존성이 누락되었을 때 (생성자 주입을 사용할 때와 달리) 컴파일 타임 에러 대신 런타임 에러를 유발한다.
 모든 테스트가 테스트 대상 클래스의 가짜 의존성을 설정하기 위해 동일한 전역 서비스 로케이터 클래스와 상호작용해야 하므로, 레지스트리는 코드를 테스트하기 어렵게 만든다.

 같이 보기 
 의존성 주입
 의존관계 역전 원칙
 JNDI

 각주 

 외부 링크 
 샘플 코드

분류:소프트웨어 디자인 패턴
분류:아키텍처 패턴
런타임 오류 탐지

런타임 오류 탐지(Runtime error detection)는 소프트웨어 응용 프로그램이 실행될 때 이를 분석하고, 해당 실행 중에 탐지된 결함을 보고하는 소프트웨어 검증 방법이다. 이는 유닛 테스트, 컴포넌트 테스트, 통합 시험, 시스템 검사(자동/스크립트 또는 수동), 또는 침투 테스트 중에 적용될 수 있다.

런타임 오류 탐지는 실행 시에만 나타나는 결함(예: 파일 덮어쓰기)을 식별하고, 응용 프로그램의 충돌, 느린 실행 또는 예측 불가능한 동작의 근본 원인을 찾아낼 수 있다. 런타임 오류 탐지에 의해 일반적으로 탐지되는 결함은 다음과 같다:
 경쟁 상태
 예외
 자원 누수
 메모리 누수
 보안 공격 취약점 (예: SQL 삽입)
 널 포인터
 초기화되지 않은 메모리
 버퍼 오버플로

런타임 오류 탐지 도구는 응용 프로그램의 실행된 제어 흐름 내에 있는 오류만 탐지할 수 있다.

 같이 보기 
 개발 테스트
 소프트웨어 테스트
 메모리 디버거
 BoundsChecker
 런타임 검증

 각주 

분류:소프트웨어 테스트