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

출처 : https://fossbytes.com/systemd-vs-sys-v-vs-upstart/

제목 : Systemd vs SysV vs Upstart -- 리눅스 서비스 관리자를 쓰러뜨리다.

날짜 : 2017년 1월 31일

옮긴이 : cybertramp 2017.06.11

해석이 잘못된 부분 및 오타가 있을 수있습니다.

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


짧은 글 : 리눅스의 세계는 영원한 불꽃전쟁이다, 최근 오랜 논란은 시스템 서비스 관리자의 토픽이다. 우리는 현대 시스템 서비스 매니저가 필요했고 systemd는 아무것도 만날수 없는 줄을 설정했다. 지금 systemd는 기본이 되고 있다, 많은 사람들은 자유의 선택과 오픈소스 소프트줴어에 의존하는 systemd 주장에 대해 무기를 들고 있다. systemd 에대해 더 불길한 것이 있니?, 또는 이 불꽃전쟁이 단지 연기와 거울인 걸까?

 

시스템 서비스는 무엇일까? 그것은 매우 넓다, 그러나 문제에 쉽게 대답한다. 시스템 서비스들은, 리눅스와 유닉스 커뮤니티에서 데몬으로 자주불리고, 다른 프로그램들에게 기능을 제공하거나, 백그라운드에서 실행되는 간단한 프로그램이다, 마치 오디오 또는 네트워킹 기능, 또는 보안이벤트를 모니터하거나 알람을 제공하는 것 처럼. 어느쪽으로든, 이름에서 알 수 있듯이, 시스템에서 실행중인 다른 프로그램에 서비스를 제공한다.

 

그렇다면, 어떻게 매우 기본적이고 필수적인 것이 논란에 소지가 될수있을까요? 단지 그것은 선택 때문이다. 당신이 Windows와 OS X의 시스템 서비스 관리자를 사용한다면 불꽃전쟁을 둘러쌓여 볼 필요가 없다. 왜냐하면 거기엔 선택의 권한이 없기 때문이다. 그러나, Linux를 사용한다면, 항상 선택이 따를 것이다.

 

문제의 부분은 시스템 서비스 매니저들 또한 시스템을 초기화하는 것이다. 그리고 거기에는 그 일을 하려고 하는 많은 방법들이있다. SysVinit 스타일은 System V(System 5는 1983년에 출시) 가 생긴 이래로 계속 있었다. 이것은 POSIX를 준수하는 시스템으로 초기화 된 방법​을 위한 트렌드를 설정한다. SysV init 스타일은 거의 30년 동안 남아 있었다, 몇년을 제외하고는. 많은 IT 교수들과 소프트 엔지니어들은 SysV init을 버리기를 원하지 않는다 왜냐하면 그것은 수 년동안 잘 작동했었기 때문이다, 그리고 그것을 이해하는 과정은 매우 간단했다. 그래서, 대체 할수있던 모든 것을 소개 했지만 강력한 저항을 만났을 것이다.

 

SysV init 문제는, 그래도, 수 년전 부터 개념에 기초했다. 하지만 그것은 많은 네이티브 처리 능력 부족했다, 저장매체 제거 감지와 같은 것, 하드웨어를 정확히 감지하고 펌웨어를 읽기위해 허락하는 것, 그리고 싱글-유저 모드 컴퓨터의 가능한 상태는 지나치게 단순화 되었다. 싱글-유저 네트워킹, 멀티-유저 모드, 멀티-유저 그래픽 모드, 재부팅, 종료. 이것은 단지 커스텀화된 두 가지 모드들을 제공한다, 멀티유저모드, 그리고 그래픽 멀티유저 모드. 이것은 관리의 관점으로부터 시스템의 관리성이 심하게 단순화되어 제한되었다. 이것은 개인용 컴퓨터에서는 문제가 안된다, 그러나 생산 환경 안의 서버들 관리 가능성은 명확하게 제한되어 있다.

 

리눅스 초기화 프로세스의 더 많은 기능을 가져오는 시도에서, 2006년에 케노니컬에서 릴리즈된 우분투6.10은 Upstart를 채택했다. Upstart는 시작으로부터 역행하는 적합성으로 디자인 되었다. 그것은 데몬들을 startup 스크립트들의 어떠한 수정없이 실행할수있었다. 이 때문에, 많은 리눅스 배포판들은 Upstart를 향해 움직였다, 그러나 그게 다가 아니였다. 사실은, Devuan들에 기초한 데비안은 systemd로 움직였음에도 불구 하고 개발됬다. Devuan은 SysV init을 사용한다, 그러나 많은 다른 선택들이 제안됬다.

 

2010년, Lennart Poettering 레드햇 엔지니어들과 Key Sievers 는 systemd 개발을 시작했었다. Fedora 15 봄에 따르면 systemd가 릴리즈되어있다, 첫번째 systemd가 제공된 배포판이었다. 3년후의 코스가 지난 후에, 배포판들의 과반수가 2가지의 주요한 이유로 systemd로 전환 되었다, 업데이트된 시스템 고유의 이점으로 인한 시스템 초기화, 그리고 또한 뒤에 남기기를 원하지 않았던 것.

 

그러나, 만약 systemd가 모든 이 배포판, 엔터프라이즈 그리고 애호가​들에 의해 고려되어졌더라면, 왜 매우 논쟁이 있었을까? 거의 만장일치로 더 나은 것으로 합의 된 것에 대해 왜 그렇게 많은 저항이 있었을까?

 

systemd는 많은 것을 제안한다, SysV init 과 Upstart보다 많은 향상, 그러나 그것은 또한 개발자들이 더 단단한 시스템의 완성과 더 적은 일을 위한 이점을 얻을수있는​ 다른 컴포넌트들을 제공한다. 그럼 무엇이 잘못 된걸까? 개발자들은 많은 다른 서비스(journald, udevd, consoled, logind, networkd 와 같은)와 systemd에 의존하는 이 소프트웨어 모두를 쓴다. 저 소프트웨어는 systemd를 구동중이지 않은 시스템에서 더 적은 호환성을 가진다. 게다가, 지속적으로 성장하는 systemd 프로젝트에 의해 제공되어진 많은 서비스들로서 , systemd는 그것 자신의 더 많이 의존하게 될것이다. 결과 적으로, systemd는 그것 자신의 플랫폼이 되고 있고 그것의 편재는 systemd가 아닌 시스템과 호환 가능하고 이동성이 뛰어난 소프트웨어의 개발에 의도적으로 방해하는것이다. 나는 systemd에 대해 왜 몇몇 사람들이 저항하는지 쉽게 볼수있다.

 

그러나, systemd는 정말 나쁜것일까? 물론 아니다. 그것은 오픈소스이며 사람들은 그것을 사용할지 안할지 선택을 가진다. 당신은 그것이 제공하는 수많은 이익을 고려 하지 않는 한​​ 전체 유저들과 개발자들은 더 다양하게 설정된 시스템 배경으로 부터 이익을 취할것이다,  스위치 만드는 것을 가진 주요한 배포판들의 systemd는 실패가 아니다.

 

말한 바와 같이, systemd에 많은 저항이 있었다, 그러나 우리는 많은 대안들을 가지고 있다. 당신은 여전히 sysvinit, Upstart 또는 OpenRC, sinit, runit, shepherd, s6(당신의 배포판을 지원하는 그곳들에게서 제공된)을 사용 할 수 있다. 여전히 많은 배포판은 특정 systemd가 없는 배포판에서 열심히 작업한다. 전에 말한 바와 같이, 거기에는 Devuan도 있고, 그러나 또한 Gentoo, Slackware, Dragora 그리고 PCLinuxOS 그리고 많은 FreeBSD, OpenBSD, DragonflyBSD 같은​ 유닉스 운영체제 시스템도 있다. 아랫 줄은 여전히 선택 할수있다, 그것은 오픈소스의 큰 부분인 것이다.

 

당신의 시스템안에는 어떤 시스템으로 설정 되어있습니까? 당신은 systemd에 반대하나요? 우리가 알아 볼수있게 아래 댓글을 달아주세요.