ARPL와 앞으로의 TCRP의 향방에 대해 POCOPICO님과의 문답내용을 공유 합니다.

ARPL 은 기존 TTG 로더를 사용하는 TCRP의 한계를 극복하고 재설계가 되었다고 하는군요.

TCRP도 이 TTG 로더의 한계를 극복하려는 재설계가 과연 필요한가? 결국 ARPL과 똑같아 지는것이 아닌가?

하는 POCOPICO님의 고민이 엿보였습니다.

결국 ARPL에게 모든것을 내어주고 TCRP의 개발은 중단하시는것이 아닌가 싶었지만,

제가 다시 질문한 답변에서 TCRP의 개발은 계속된다고 얘기하셨네요.

ARPL하고 결국 같은 설계를 따라가더라도 재설계를 하긴 하실것 같아 보이는데, 

어떻게 바뀌어 가게 될지는 모르겠습니다.

나중에 더 문의해보고 알게되는 내용이 생긴다면 또 공유 드리겠습니다.

 

---------------------------------------------------------------------------------------

 

(Pocopico)

일반적으로 ARPL은 모든 수준에서 더 나은 로더이다.

이전의 모든 TTG 로더 제한을 극복하기 위해 처음부터 재설계되었습니다.

나는 또한 가능하면 모두에게 ARPL로 전환할 것을 제안한다.

TTG 로더는 극복하기 매우 어려운 매우 엄격한 제한이 있다.

나도 다시 설계하려고 하지만 결국 요점이 뭐야, 마지막에 정확히 ARPL처럼 보인다면?

 

(화정큐삼)

나도 TTG 로더에 한계가 보인다는것을 조금 눈치채고 있었다.

내가 경험한것은 새로운리비전의 DSM이 나올때마다 정적인 환경설정의 재구성은 노력이 많이 필요하게 된다.

 

나는 ARPL의 동작원리를 거의 모르지만 로더의 소스는 C언어 기반이 였던것 같은데 맞는가?

상대적으로 리눅스 쉘 스크립트로 개발된 TCRP는 내가 접근하기에 용이했다.

당신의 TCRP가 완성되기 까지 여러사람의 도움으로 여기까지 왔다.

ARPL은 fabio 혼자만 코딩이 가능한것 처럼 보인다.

 

rp-ext이 addon으로 바뀐것도 어떤 재구성이 있었는가?

새로운 addon이 필요하게 된다면 fabio가 커널컴파일을 통해 addon을 직접 만들어줄수 있는가?

rp-ext 부분은 pocopico 당신의 또다른 업적이고 아직도 당신의 도움이 필요한곳이 아닐까?

 

(Pocopico)

Fabios 작업은 Jumkeys 및 Pocopico 및 기타 연구 및 작업을 기반으로 합니다. TTG 로더를 고치려고 하는 대신 한 걸음 뒤로 물러나서 전체 로더를 다시 디자인한 것뿐입니다.

전체 ARPL 로더는 bash 스크립트, github 작업, 도커 컴파일 등이 혼합되어 있습니다. 조직은 약간 복잡하지만 모두 열려 있고 다운로드 및 기여가 가능합니다.

 

누구나 redpill-load를 사용하는 것처럼 원하는 대로 모델을 복제, 수정 및 추가할 수 있습니다.

 

** 커널 패치, dtbpatch, 커널 모듈의 모든 소스, eudev 등을 위한 일부 C 코드가 포함되어 있기 때문에 Github에서 C 언어로 표시합니다.

 

@Peter Suh 오해하지 마세요. TCRP는 계속 개발되지만 TTG 로더 제한으로 인해 해결 방법이 필요한 특정 제한 사항이 항상 있습니다.

 

https://xpenology.com/forum/topic/62871-tinycore-redpill-loader-tcrp-development-release-09/page/2/#comment-338410