다음부터는 AI 요약도 같이 가져와보겠습니다. 특이하게 사람이 한 주장별로? 요약을 해주는 것 같네요.
- danhau: 다른 사람들이 주장하는 대로 협력 스케줄링이 실패하기로 예상되는지 의문을 제기하며, 이미 앱들이 협력하고 있다는 점에 대해 걱정합니다. 거부 서비스 공격이 이러한 시스템을 쉽게 중단시킬 수 있다는 것을 우려합니다.
- aseipp: danhau와 동의하여 협력 스케줄링이 간단한 오류를 시스템에 치명적으로 만들 수 있어서 임의의 프로그램 실행에 문제가 될 수 있다고 말합니다.
- gnulinux: 모든 것이 아니라는 것을 제안하며, 협력 앱을 허용하면서도 무한 루프로 인해 시스템이 중단되는 것을 방지하는 방법이 있을 수 있다고 말합니다. 예를 들어 타임아웃이나 루프 감지 등이 있을 수 있다고 합니다.
- DSMan195276: 협력 프로그램은 선점되지 않을 것이라고 가정하기 때문에, 실제로는 모든 것이 아니라고 주장합니다. 심지어 선점의 수준이 낮아져도 프로그램을 작성하는 방식이 변경되어야 한다고 말합니다.
- getpokedagain: 모든 운영 체제가 예측할 수 없는 다중 사용자 앱을 실행할 필요는 없으며, 임베디드 장치나 게임 콘솔과 같은 제한된 시스템에서는 협력 모델이 작동할 수 있다고 말합니다.
- Symmetry: 현대 CPU는 여러 스레드를 가지고 있으므로, OS가 일부 스레드의 과도한 사용을 확인하면서 돌아올 수 있다면 Fomos의 모델은 완전히 중단되지 않고 작동할 수 있다고 말합니다.
- cmrdporcupine: 특수한 사용 사례는 직접 작업을 빈 코어에 할당하는 모델을 사용할 수 있는 이점이 있지만, 동시성 처리의 복잡성은 타임슬라이싱을 구현하는 것보다 크게 단순화되지 않을 수 있다는 점을 언급합니다.
- JoeAltmaier: 하나의 스레드에서 while(true) 루프가 다른 스레드에 영향을 미치지 않을 수도 있지만, 배터리/온도 상승은 여전히 관리가 필요한 리소스 문제임을 보여줍니다.
- keyle: 이 프로젝트와 미니멀리스트적인 접근에 열광하며, DOOM을 실행하는 전통적인 요구 사항을 충족하는 파일 시스템과 같은 더 많은 개발을 기대합니다.
- mepian: Smalltalk 메소드는 독립적인 함수가 아닌 객체 간에 호출된다는 것을 명확히하며, 일부 초기 Lisp OS도 객체 시스템 이전에 함수를 사용했다고 설명합니다.
문제는 저도 저 링크를 보고 같이 요약하고 있었다는거 ㅠ
무려 3가지의 요약버전을 보시면서 비교하시면 되겠습니다 ㅎ
- Non-Unix OS 를 만들어보고 싶었음
- Exo-Kernel은 흥미롭지만 대부분 이론에 불과해서, 이 패턴을 이해하는데 도움이 됨
- 기능들
- 그래픽 출력, 동적 할당, 모든 앱이 비동기 루프에서 실행
- Virtio 마우스/키보드(드라이버들도 비동기 태스크)
- 협업 스케줄링(앱들이 최대한 제어를 넘김)
- 부팅후에는 컨텍스트 스위치 없음
- Virgl™ 을 거의 지원
- 독특한 점
- 앱의 시그니처
pub extern "C" fn _start(ctx: &mut Context) -> i32 - 앱들은 표준 라이브러리가 필요 없고, 모든 OS 기능들은 Context 를 통해 앱에 전달
- Fomos에서 앱은 그냥 한개의 function 임. 이게 가장 큰 부분. Unix/Windows OS의 실행파일은 함수에 비해서 매우 복잡함.
- 앱의 시그니처
댓글에 HN 스레드 있으면 neo가 자동으로 요약해주면 좋겠네요 ㅋㅋ neo 없이 못 살아