다음부터는 AI 요약도 같이 가져와보겠습니다. 특이하게 사람이 한 주장별로? 요약을 해주는 것 같네요.

• danhau: 다른 사람들이 주장하는 대로 협력 스케줄링이 실패하기로 예상되는지 의문을 제기하며, 이미 앱들이 협력하고 있다는 점에 대해 걱정합니다. 거부 서비스 공격이 이러한 시스템을 쉽게 중단시킬 수 있다는 것을 우려합니다.
• aseipp: danhau와 동의하여 협력 스케줄링이 간단한 오류를 시스템에 치명적으로 만들 수 있어서 임의의 프로그램 실행에 문제가 될 수 있다고 말합니다.
• gnulinux: 모든 것이 아니라는 것을 제안하며, 협력 앱을 허용하면서도 무한 루프로 인해 시스템이 중단되는 것을 방지하는 방법이 있을 수 있다고 말합니다. 예를 들어 타임아웃이나 루프 감지 등이 있을 수 있다고 합니다.
• DSMan195276: 협력 프로그램은 선점되지 않을 것이라고 가정하기 때문에, 실제로는 모든 것이 아니라고 주장합니다. 심지어 선점의 수준이 낮아져도 프로그램을 작성하는 방식이 변경되어야 한다고 말합니다.
• getpokedagain: 모든 운영 체제가 예측할 수 없는 다중 사용자 앱을 실행할 필요는 없으며, 임베디드 장치나 게임 콘솔과 같은 제한된 시스템에서는 협력 모델이 작동할 수 있다고 말합니다.
• Symmetry: 현대 CPU는 여러 스레드를 가지고 있으므로, OS가 일부 스레드의 과도한 사용을 확인하면서 돌아올 수 있다면 Fomos의 모델은 완전히 중단되지 않고 작동할 수 있다고 말합니다.
• cmrdporcupine: 특수한 사용 사례는 직접 작업을 빈 코어에 할당하는 모델을 사용할 수 있는 이점이 있지만, 동시성 처리의 복잡성은 타임슬라이싱을 구현하는 것보다 크게 단순화되지 않을 수 있다는 점을 언급합니다.
• JoeAltmaier: 하나의 스레드에서 while(true) 루프가 다른 스레드에 영향을 미치지 않을 수도 있지만, 배터리/온도 상승은 여전히 관리가 필요한 리소스 문제임을 보여줍니다.
• keyle: 이 프로젝트와 미니멀리스트적인 접근에 열광하며, DOOM을 실행하는 전통적인 요구 사항을 충족하는 파일 시스템과 같은 더 많은 개발을 기대합니다.
• mepian: Smalltalk 메소드는 독립적인 함수가 아닌 객체 간에 호출된다는 것을 명확히하며, 일부 초기 Lisp OS도 객체 시스템 이전에 함수를 사용했다고 설명합니다.