Problems with Systemd and Why I like BSD Init by Randy Westlund

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

출처 : https://bsdmag.org/randy_w_3/

제목 : Problems with Systemd and Why I like BSD Init by Randy Westlund

날짜 : 2017년 1월 6일

옮긴이 : cybertramp 2017.06.03

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

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

systemd의 병렬 시작은 나를 귀찮게 한다. 만약 A라는 서비스가 서비스 B에 의존 한다면, 그것들은 전통적으로는 순차적으로 시작 될 것이다; A는 단지 B가 시작을 하고 난 후 시작할 것이다. Systemd는 그것들을 동시에 시작 할 것이다, 그러나 A 버퍼의 모든 메시지는 B가 준비될때까지 B에게 보내는 것을 시도할 것이다. 그러면 A는 B가 반응이 느리다고 생각하고, 시스템은 더 빠르게 시작 될 것이다. 당신은 'After' 지시를 사용하는 특정한 것을 위해 disable 할수있다, 그러나 그것은 전체 시스템에 적용되지않을 것이고, 아무튼, 기능을 무력화하는 것은 첫 번째 장소에 존재해야만 하는지에 대한 대답이 아니다.

 

서비스가 순서대로 시작되어야하는지에 대한 문제에서, 내 의견은, 시스템관리자가 예상 가능해야 하며 정확하게 동 시간에 동작 되어야한다고 생각한다. systemd를 사용하면, 순서가 결정적이지 않아서 당신이 다음 번 부팅 시 무슨 일이 발생할지 알수가 없다. 나는 서버와 임베디드 장치들과 일한다. 따라서 나는 부팅시간에 대해 아무 상관이 없다. 여하튼 서버는 부트로더가 실행되기전에, BIOS에서 POST 하는 동안 몇 분을 사용한다. 그러므로 OS부팅을 빠르게 만들어도 큰 변화는 일어나지 않는다. 임베디드 장치들은 당신이 부팅시간을 아주 적게 최소한으로 손질 해두었기 때문에 이미 빨리 시작될 것이다. 내가 신경쓰는 것은 부팅 할때 마다 내가 원하는 정확히 똑같은 순서로 똑같이 일어나는 가 이다.

 

systemd가 모듈러 인지 아닌지에 대해 아무도 동의 할수 없는 것처럼 보인다. 이 문제에 대해 나는 모듈성의 다른 정의라고 생각한다. Systemd는 몇몇 사람들이 제안하는 것처럼 PID 1번에 모든 것을 넣지는 않는다. 그것은 서로 통신하기 위한 모듈에 사용된다. 그런 의미에서 그것은 모듈러이다. 그러나 이 모듈들은 매우 밀접하게 통합되어 있다. 당신은 모듈 몇몇을 쉽게 제거 하거나 대체 할수없다. 이 의미는, 모듈이 매우 단단히 짜여있는 하나라는 것이다. 이것은 간단한 인터페이스와 stdin과 stdout을 통한 데이터 전달이 전혀 아니며, 모듈성은 UNIX 파이프들을 가능하게 한다. 이것은 나에게 매우 중요한 의미다.

 

내가 systemd 방식을 좋아하지 않는 것은 모든 것을 흡수하는 것이다. 그것이 단지 init 시스템이 아니라서가 아니라, 그것이 부엌의 싱크 관리 시스템을 포함하는 후드 아래 모든 것이 되기 때문이다. 나는 그것이 모듈식이라고 느껴지지 않는다. 왜 systemd는 ntpd가 이미 존재하는데 NTP를 구현 해야만 했을까? 내 생각에는 systemd는 모두 다르게 재발명 하려고 하는 것 같고 systemd-timesyncd라고 생각한다.

 

ntpd의 경우, 더 작은 무언가를 대체하는 괴물이라 말할지도 모르는데, 사실 그게 옳다. 거기엔 그것을 재 구현 하는 다른사람들이 있다. OpenNTPD를 창조한 OpenBSD는 매우 가볍고, 오로지 클라이언트이며, HTTPS 사이트가 NTP 서버에서 가져온 시간이 합리적인지 확인할 수 있다. ntpd를 깨끗이 해버리거나 재구현 하는 것은 좋은 것이다, 그러나 OpenBSD는 init의 부분에 필요하다고 느끼지는 않는다.

 

리눅스는 매우 조각화 되어 있고 systemd는 다시 함께 조금씩 가져온다. 그것은 좋은 것이다. 하지만 우리가 이 길을 가다보면, 이것은 더 이상 'GNU/Linux' 라고 말 할수 없을 때가 오게 될 것이다. 그것은 'GNU/systemd-linuxd'가 될것이다.

 

그러나 리눅스가 매우 특별하게 만들어진 부분은 말 그대로 모든 구성요소를 libc로 바꾸는 것이다! 모든 리눅스 프로그램이 필요로 하는 것은 커널이며, libstdc처럼 보여지는 무언가이다. 그것은 ulibc와 함께 임베디드화된 리눅스 장치를 빌드하는데 공통적인 부분이자 또한 뭔가 작은 것이다. BSD는 단지 너무 통합되어 있어서 libc를 대체 할 수 없다.

 

지금 매우 오래 되지않은 BSD의 몇몇 GNOME 개발자들과 함께 한 인터뷰는 정말 좋았다. 그들은 BSD 의 적합성에 대해 더 많은 주의를 기울일 예정이라고 말했다, 그러나 왜 그들이 systemd에 의존해야만 하는지에 대해 또한 이야기 했다. 그것은 API가 없으며 시간 존을 설정하거나, 와이파이 네트워크를 바꾸거나 리눅스에서 많은 공통적인 데스크탑 작업 수행하기위한 표준 방법이 없다. GNOME의 코드는 #ifdefs 로 가득차이있기 때문에 각각의 배포판 또는 OS에서 다른 코드사용이 가능하나 유지 할 수는 없다. Systemd는 깨끗한​ API들을 제공하고 크로스플랫폼 매너가 있다. 그것은 데스크톱 환경을 위한 큰 승리다.

 

OpenBSD는 systemBSD에서 작동한다, 그것은 systemd의 틈을 메우는 것이다. 그것은 GNOME이 필요한 API들을 제공한다, 그러나 systemd의 나머지를 구현 하지 않는다. 나는 API들을 가지고 있는 것을 정말 좋은 것이라 생각하며, 나는 그것이 산업 표준화 쪽으로 가는 것 처럼 보인다.

 

Systemd는 여전히 불안정 하게 느껴진다. 나는 실제로 다른 소프트웨어보다 더 많은 문제를 가지고 있기 때문인지 단지 사람들이 더 빠르게 결함을 홍보하기 위함 때문인지 나는 확실히 모르겠다, 그러나 이것은 만약 매우 심각해지지 않는다면​ 정말 재미있게 될​ 몇몇 문제를 가졌다. 나는 실제 버그 보고서 링크가 포함 된것을 가지고 있다:

 

- 시스템 셧다운이 되지 않는 것

- Systemd-journald 가 CPU를 100% 사용하는 것

- Lennart 가 말하는 일반 저널 손상은 문제가 되지 않는다. 비 트래잭션 바이너리 로그가 매우 끔직한 아이디어 인것 처럼 분명히 보여진다.

- Systemd는 커널 명령줄에 매개 변수의 이름을 지정하지 않고 시스템을 hanging 않는다. systemd 개발자들은 이 상황을 잘 조절 하지 못했으며, 엉켜버렸다.

- POLA를 위반 한 fstab의 무언가 때문에 시스템 부팅할때의 수 많은 보고서가 있다.

하부구조의 치명적인 부분 때문에, 이 큰 문제 처럼 규칙적인 버그들을 가진다. 그것은 기계를 부팅 할 수 없게 만들고 사람들의 나날을 망친다. 이 것과 비교하면 OpenZFS 같은  프로젝트는 매우 잘 관리 되어져있다. 나의 지식으로는, 아무도 ZFS 버그의 결과로서 어떠한 데이터를 잃은 적이 없었다. 그러므로 하부구조 프로젝트들은 대부분의 소프트웨어보다 심한 버그가 발생할수있기에 높은 기준으로 유지되어져야한다. 

 

나는 systemd 개발자들이 NIH 신드롬으로 부터 고통받고있는 것같다. 나는 OpenRC로 고려된 어떠한 제안도 찾을수 없었다; 그들은 개인적인 Gentoo의 문제를 가진것 처럼 보인다. init 시스템들로 설명하 많은 문제들이 이미 OpenRC와 BSD init에 의해 이미 풀렸다. 지금 그들은 가능한 모든 리눅스 데몬을 단지 그들이 할수있기 때문에​ systemd 모듈로 재 구현 하고 있다. 

 

나는 최근에 리더와 말했다. 그가 말하길, "나는 systemd를 매 순간 봐, 내가 보기엔 너무 급한 느낌이 든다고 생각 해" 라고 말했다. 내가 생각하기엔 그가 말한것이 매우 사실인것 같다. Systemd는 커뮤니티에 의해 강요되었으며, 모든 것이 매우 빠르게 발생했다. 거기에는 정치 공작이 많았고 성숙하기 전의 모든 배포판 관리자들을 무장시켰다. 

데비안은 적어도 몇 년동안은 systemd를 채택하지 말았어야 했다. 데비안은 느리게, 안정적이게, 그리고 안정적인 배포판으로 제안 되어져왔다. 그들의 systemd로의 빠른 움직임은 많은 느낌을 다치게 했고 그들의 팀 Devuan의 절반을 떠나게 했다. 그것은 일어나지 말았어야 했다. 만약 당신의 팀이 이슈에 대해 사납게 다룬다면, 떠나는 것이 현상 유지를 위한 올바른 대응책이 될수도 있다. 데비안은 안정적을 위한 그들의 평판의 많은 부분을 이것 때문에 잃었다.

정직하게, 나는 systemd가 점차적으로 보다 더 강요되어 적용된다면, 그것은 더 많은 인기가 생길거라고 생각한다. 사람들은 Fedora와 Arch가 몇 년 동안 그것을 사용하는 것을 보았을 것이다. 그러다가 모든 사람들이 이점을보고 안정된 것으로 판명되면 그것을 채택하기를 원할 것이다. 하지만 그건 그렇고, 대부분의 커뮤니티는 문제가 없다고 하는데 그 것은 좋은게 아니다.

 

나는 유닉스하게​ sysVinit이 대체되는 것을 환영했었을 것이다. systemd 같은 것이 좋았겠지만, 그러나 systemd는 우리가 필요로 했던 것이 되기위한 구현 과 디자인 둘다 많은 결함을 가지고 있다.

 

나는 추측한다. 리눅스를 사용하는 호의적인 독재 모델이 가진 모든 문제들은 우울한 구름뒤에 숨어있는 희망(실버라이닝)이라 추측한다. 나는 사람들이 단지 기술적우월만큼이나 커뮤니티의 다름을 위해 BSD들에서 도주한다고 생각한다.

 

나는 불안해하는 유닉스안의 믿음의 부족을 systemd에서 찾았다. 그래서 BSD 커뮤니티에 가입했다. 우리는 과자들을 가지고 있다.(?)

Bio: 나는 엔지니어 이며 캠브릿지 근처에 사는 오픈소스대변자 이다. 나는 프리랜서 일을 많이 하고 대부분 집에서 보낸다.

나의 내 관심분야는 전자제품, 회로기판 디자인, 마이크로컨트롤러, 로보틱스, 리눅스, BSD, System 관리, 웹디자인, RF 통신을 포함한다.

나는 남극대륙에 두번 살았고 NASA에서 위성통신 일을 했었다.

나는 아마츄어 통신 자격이 있고, 콜사인은 KK4DOP이다.

내 여가 시간에는, 나는 하이킹, 사진촬영, 다른사람이 버린 컴퓨터들로 BSD 서버들을 돌리는 것을 즐긴다.

이 기사에 대해 어떻게 생각하는지 댓글로 알려주세요.