Comments 32
Было бы очень интересно если бы ОС составила конкуренцию Google Fuchsia. Только как я понимаю Google от Posix решила отказаться тк новый идеи на старом фундаменте не построишь, а тут без Posix все придется писать с нуля, а на это ресурсов нет
Уже было на опеннете
да пофиг какая операционка, она должна четко и качественно выполнять задачи для которых предназначена.
С софтом тоже самое.
Для кого/чего эта ОС?
Для просто удовольствия "мы сделали еще одну оюОС"? Да, круто, серьезно. Ребята запилили свою ОС. Практическая польза? Около нуля.
Для просто удовольствия «я написал ещё один комментарий»? Да, круто, серьезно. Парень запилил свой комментарий. Практическая польза? Около нуля.
да потому, что ОС это не penis canina. И если создаеются, то с какой-то целью и направлением. Это языки программирования можно от нехрен делать клепать пачками. А тут ОС.
Исследовать академический вопрос целесообразности существования borrowck и lifetimes при реализации абстракций ядра. Сойдёт?
А минусуют вас за пренебрежительное обесценивание чужой работы.
я чужую работу, оценил, и даже написал об этом. Я просто задал вопросы. У сообщества не нашлось полноценных ответов и меня слили.
Вы оценили чужую работу. Но ваша оценка (а, точнее, форма, в которой эта оценка была выражена) окружающими воспринимается как обесценивание (и в целом, является примером токсичного комментария). Если вам кажется иначе — поздравляю, у вас самоиммунитет.
https://doc.redox-os.org/book/ch01-03-our-goals.html
https://doc.redox-os.org/book/ch01-05-why-redox.html
У сообщества не нашлось ответов? Ответы есть у авторов. Их можно найти на их сайте пройдя по первым же ссылкам документации.
Исследовать академический вопрос целесообразности существования borrowck и lifetimes при реализации абстракций ядра. Сойдёт?И наверное, это исчерпывающее объяснение =)
Линукс тоже начинался как хобби…
На самом деле у таких проектов действительно (по крайней мере) в начале нет конечной точки. Но то, что ты получаешь при работе над проектом — опыт, знания, коллег — это бесценно и может помочь в будущей карьере, даже если сам изначально проект не взлетит
ну слили карму в ноль, после этого коммента в минус уйду похоже. А сарказма с моей стороны не было. Для чего ОС? Работа ради работы и саморазвития? Так бы и написали. Да и похоже комментить не смогу теперь. Кто минусил, напишите, почему обиделись.
читается так что вы думаете что очень даже понимаете и задаёте риторические вопросы, которыми распекают нелепых идиотов
но обратная связь показывает кто здесь кто
А вообще, система кармы по-идиотски реализована, хотя администрация в режиме «я тут главный, мое мнение — истина в последней инстанции» не пытается менять политику. Да и само местное понятие кармы в корне противоречит значению этого слова =) Карму невозможно «поставить» — она сама формируется самим человеком =) А тут — так, маркетинговое слово, скорее показывающее погоду на Марсе =) За сим откланиваюсь)
Для тех, кто не читает ветку, слово "круто" без сарказма написано. А минусаторы так и не написали причину, я бы адекватно принял, если бы было обоснование
Авторы попытались привнести следующие улучшения:
1) они построили микроядерную архитектуру
2) интересная концепция все есть url
3) они уделили особое внимание стабильности, безопасности (rust позиционирует себя как более безопасный язык чем си)
4) подсистема драйверов работает в пользовательском пространстве внутри песочницы (еще жирный плюс к безопасности)
В принципе довольно обоснованно попробовать все эти вещи. Другое дело развитие, совместимость и популярность. Надеюсь, у ребят получатся задумки. Но во всяком случае в академическом плане очень интересно.
Практически с нуля переписана система управления памятью ядра. Речи идет об rmm, kernel memory manager. Разработчикам удалось избавиться от утечек памяти, создававшие проблемы при использовании старого менеджера памяти. Также повышена и стабильность поддержки многоядерных систем.
Иронично)))
Если все же попробовать отбросить иронию и прокомментировать серьезно, то утечки памяти не с точки зрения Rust не являются нарушением доступа к памяти. Доступ к неинициализированной памяти, use after free, double free, несинхронизированный доступ — да. Утечки и дедлоки — нет.
Утечки как бы тоже являются… у каждого обьекта строго определен owner и когда он выходит из области видимости то обьект автоматически освобождает ресурсы. Соответственно при написании тривиального кода утечка не может возникнуть. Скорее всего утечки были связаны с какими нибудь механизмами использующими unsafe либо как вариант с отсутствием или неправильной реализацией трейта Drop
Вообще-то, std::mem:forget — это safe функция
Но даже если забыть про неё, утечка без проблем делается в циклических структурах данных. Rc<Cell<Self>> и вот она.
Box::leak тоже сейф функция. Понятно что никто не мешает сделать утечку памяти если очень хочется… Но в таком случае это довольно явно происходит и такое сложно сделать непреднамеренно. Вот пример про циклические структуры согласен это больше похоже на случай где можно непреднамеренно допустить утечку памяти. Но вцелом должна быть очень веская причина использовать именно такие структуры и как правило это признак плохого проектирования (из моего опыта)
Как я понял (исходя из https://gitlab.redox-os.org/redox-os/redox/-/issues/855), там не было "старого менеджера", память выделенная в прерывании просто не освобождалась. Т.к. ядро пилит (опять же, как я понял из репозитория) один человек, вполне нормально для хобби проекта.
Операционная система Redox 0.6, написанная на Rust: что нового в выпуске?