Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Супер.
Хотелось бы мне эту статью, да лет так пять назад.
Может, и учителя своего бы догнал — он и его друг дошли до этапа «есть процессы, память и консоль с просто нереальной скоростью вывода».
Хотелось бы мне эту статью, да лет так пять назад.
Может, и учителя своего бы догнал — он и его друг дошли до этапа «есть процессы, память и консоль с просто нереальной скоростью вывода».
Я думал одним из первых советов будет — «Определите точно цель написания». Чтобы сразу разобраться — зачем все эта возня началась — чтобы получить опыт в программировании или изучить архитектуру существующих ОС, или еще что-то. Потому как если проект изначально учебный — в абзацах о практическом применении изначально нету смысла.
Разумно, но неинтересно. Автор потому и подчёркивает, что именно потеря интереса приводит к отказу от продолжения работы. То есть свою ОС начинаешь писать, когда просто интересно покопаться, а случится ли практическое применение в будущем, заранее неизвестно. Торвальдс ведь тоже с этого начинал. Помните?
Я делаю (бесплатную) операционную систему (это всего лишь хобби, и она
не будет большой и профессиональной как gnu)
конечно писал. Это было самой большой задачей в жизни, когда начинал программировать. Плюсы, асм. Та чего, был прогресс даже.
Дык автор он и есть, просто аккаунт новый :)
l4os.ru/ — это по-моему нечто иное, чем то, что Попов делал.
Заголовок сразу напомнил о BolgenOS
Всё верно сказано, правда, когда я перешел с Assembler'а под 8080 (ZX-Spectrum) на ассемблер для x86 под DOS я понял, что интереснее и удачнее будет писать вирусы, потому и их писал, все на 100% успешные, один даже в DrWeb List попал :)))
Что значит успешные?
Так-то успешные я и на delphi писал, в том плане что они делали свое дело (дергали мышку ;) на одной-двух целевых машинах.
Только по-настоящему успешный на мой взгляд это от 1000 машин. Но туда так просто не пойти.
Так-то успешные я и на delphi писал, в том плане что они делали свое дело (дергали мышку ;) на одной-двух целевых машинах.
Только по-настоящему успешный на мой взгляд это от 1000 машин. Но туда так просто не пойти.
Ну как, если ты пишешь вирус для собственного развлечения, то успех — это если (а) ты убедился, что вирус может размножаться сам, и (б) он не размножился на много машин (а то стыдно). Тонкий баланс…
Успешные вирусы — это значит они размножались, корректно заражали com и exe, полиморфировали, работали и жили на машинах без лишнего шума и вреда.
Ни о чем.
Ох… Проверено: Shaman007
>>>О себе: Линуксойд, добрый и внимательный модератор Linux.Org.Ru.
Попов навсегда изменил на Ваш разум :(
Попов навсегда изменил на Ваш разум :(
Кто такой Попов?
Денис Попов, мальчик, написавший «Российскую операционную систему BolgenOS», при установке которой на окне не была затерта надпись «Ubuntu».
Ну, про «Антивирус Попова», «Браузер Попова» и т.д я вообще молчу))
lurkmore.ru/BolgenOS
Ну, про «Антивирус Попова», «Браузер Попова» и т.д я вообще молчу))
lurkmore.ru/BolgenOS
>>О себе: Андройд головного мозга
Сейчас, имхо, одному человеку написать с нуля полезную на практике ОС невозможно. Разве что для очень специфичной embedded-техники. И то, первым делом слоило бы рассмотреть возможность использовать готовое ядро какой-нибудь из *nix-систем. А уже поверх встроить что-нибудь интересное, например, поддержку real-time процессов или «хитрый» менеджер памяти.
После процессов и памяти, будет еще головной болью драйверная модель, если заранее не спроектирована
Нашел в вашем профиле сайт Хамелеона.
Вопрос: чем руководствовались, когда решили делать свою микроядерную ОС? Можно же пилить hurd или minix3, как раз чтобы с нуля вручную всё не реализовывать. Или задача — сделать коммерческий аналог? Цели?
Вопрос: чем руководствовались, когда решили делать свою микроядерную ОС? Можно же пилить hurd или minix3, как раз чтобы с нуля вручную всё не реализовывать. Или задача — сделать коммерческий аналог? Цели?
Трудный вопрос, если честно. Написать ОС — мечта юношеских лет. Конечно, хотелось бы достигнуть коммерческого успеха, но если не выйдет, значит такая судьба, значит что-то сделал не так.
Может быть меня сейчас побьют, но в Hurd я разочаровался, после того как тестировал его около 10 лет назад на ноутбуке. В нормальной системе, большую часть времени процессор находится в режиме низкого энергопотребления (HLT) и лишь прерывания выводят его из состояния «сна». Hurd же всё время что-то делал, благодаря чему вентилятор охлаждения процессора всё разгонялся и разгонялся. Даже мальчишка может понять, что такого быть не должно.
Писать ОС брался несколько раз и все попытки заканчивались остыванием интереса, благодаря тому, что не было соответствующих знаний в этой области. Потом случайно наткнулся на L4 Fiasco и заинтересовался этим микроядром. Наконец, когда увидел L4Ka::Pistachio, понял, что это идеал. За годы работы с Pistachio ни разу не разочаровался в нём.
Что касается minix3 — я уважаю Таненбаума, он отличный архитектор и прекрасный учитель, но я поклоняюсь L4 и верю, что это микроядро вскоре будет оценено по достоинству.
Может быть меня сейчас побьют, но в Hurd я разочаровался, после того как тестировал его около 10 лет назад на ноутбуке. В нормальной системе, большую часть времени процессор находится в режиме низкого энергопотребления (HLT) и лишь прерывания выводят его из состояния «сна». Hurd же всё время что-то делал, благодаря чему вентилятор охлаждения процессора всё разгонялся и разгонялся. Даже мальчишка может понять, что такого быть не должно.
Писать ОС брался несколько раз и все попытки заканчивались остыванием интереса, благодаря тому, что не было соответствующих знаний в этой области. Потом случайно наткнулся на L4 Fiasco и заинтересовался этим микроядром. Наконец, когда увидел L4Ka::Pistachio, понял, что это идеал. За годы работы с Pistachio ни разу не разочаровался в нём.
Что касается minix3 — я уважаю Таненбаума, он отличный архитектор и прекрасный учитель, но я поклоняюсь L4 и верю, что это микроядро вскоре будет оценено по достоинству.
На мой взгляд, Pistachio лучше Fiasco благодаря cпецификации l4-x2: os.ibds.kit.edu/l4ka/l4-x2-r7.pdf
Самокритичные такие названия.
Особенно Pistachio для русского уха :)
Особенно Pistachio для русского уха :)
что то я не совсем понимаю… L4 разработал покойный Jochen Liedtke в университете карлсруэ, таки свое ядро вы не написали
Своё ядро я написал как дипломную работу. Вы не поверите, Pistachio оказалось лучше.
Кстати, я попытался перевести community.livejournal.com/l4os/743.html
Оригинал здесь: i30www.ira.uka.de/aboutus/inmemoriam/liedtke/
Кстати, я попытался перевести community.livejournal.com/l4os/743.html
Оригинал здесь: i30www.ira.uka.de/aboutus/inmemoriam/liedtke/
Скажите, а что вы подразумеваете под «годы работы с Pistachio»?
Могу дать ссылку на интервью с alman если хабрасообщество не будет против. Он дает ответ на этот и многие другие вопросы.
А если я хочу сразу заняться созданием графического окружения для x-сервера? На что посоветуете обратить внимание?
Зарезервируйте несколько системных вызовов для протокола обмена с графической системой.
Далее, осуществляете обмен графической системой по этим протоколам. Здесь очень большое поле для творчества.
Некоторые идеи по этому поводу можно найти здесь: almandrykin.ya.ru/replies.xml?item_no=1053
Далее, осуществляете обмен графической системой по этим протоколам. Здесь очень большое поле для творчества.
Некоторые идеи по этому поводу можно найти здесь: almandrykin.ya.ru/replies.xml?item_no=1053
Пишите экзоядро и будет вам счастье
Спасибо. А какие последние достижения в области ОС (пардон за глупую формулировку :) Интересно, что может быть нового для пользователя. Например, помню кто-то делал (и вроде до сих пор делает) операционку которой почти не нужна загрузка/выгрузка — все открытые процессы хранятся уже на диске. Есть ли в этом смысл, увидим ли мы такое? Что еще может быть отлично от существующих (десктопных/серверных) осей, в частности от линукса? Либо же это всё актуально больше для узкоспециализированных устройств?
О. На самом деле, там широченный простор для фантазий. Очень много хороших задумок так и не реализовано до сих пор. Ну и вообще, основная тема: распределённость. Современные ОС сетевые (читай: клиент-серверные), и кучу всего поверх их API ОЧЕНЬ неудобно делать. Просто у большинство людей терпения не хватает продумать именно новую систему. Это действительно долго, нудно, тяжело.
Спасибо. И ниже имхо вами толково замечено.
alman, я понимаю что вопросы мои детские, но раз уж вы заинтересовываете молодняк, то было бы интересно услышать какая *сегодня* может быть мотивация при написании новой ОС. Судя по вашему молчанию выходит что только из-за «попробовать повторить с нуля». Как-то не очень творчески.
alman, я понимаю что вопросы мои детские, но раз уж вы заинтересовываете молодняк, то было бы интересно услышать какая *сегодня* может быть мотивация при написании новой ОС. Судя по вашему молчанию выходит что только из-за «попробовать повторить с нуля». Как-то не очень творчески.
Мотивация простая — незнание. Я не шучу. Человек, обладающий достаточными знаниями, никогда не возьмётся за написание операционной системы, поскольку:
— в этом нет смысла, рынок ОС давно поделен;
— это не под силу одному человеку.
Но заметьте, я никого не призывал писать операционную систему, а просто дал советы тем, кто решил это сделать.
Простите, уже за полночь. Я благодарен Вам и всем отписавшимся в этой теме за проявленное внимание к этой статье. К сожалению, завтра буду вдали от интернета, поэтому никому не отвечу. Честно говоря, меня приятно удивила реакция сообщества. Ещё раз всем спасибо.
— в этом нет смысла, рынок ОС давно поделен;
— это не под силу одному человеку.
Но заметьте, я никого не призывал писать операционную систему, а просто дал советы тем, кто решил это сделать.
Простите, уже за полночь. Я благодарен Вам и всем отписавшимся в этой теме за проявленное внимание к этой статье. К сожалению, завтра буду вдали от интернета, поэтому никому не отвечу. Честно говоря, меня приятно удивила реакция сообщества. Ещё раз всем спасибо.
Это две не правды. 1. Рынок ОС постоянно меняется. Постоянно появляются новые платформы. Например, даже у нас пишутся собственные ядра для суперкомпьютеров, Linux перепиливают очень-очень-очень существенно. Поэтому нельзя сказать, что тут всё поделено. Поэтому, как минимум, навык писания ОС может быть полезен в работе. 2. Сложность написания ОС преувеличивается. Скажем, система управления сайтами моего знакомого гораздо сложнее, чем ядро, например, Plan9: она и по объёму больше, и написана на Ruby, то есть на более высоком уровне абстракций. А мой знакомый написал почти в одиночку всё. Самое сложное в разработке ОС — это зацепить народ, чтобы он потянулся и создал критическую массу драйверов.
Спасибо, но очень не хватает примеров.
Хотите написать операционную систему?
Лучший совет: Не пишите.
Лучший совет: Не пишите.
Для желающих (если таковые вдруг найдутся) написать свою ОС лучше всего для начала разобраться в кишочках какой-нибудь не очень сложной операционки для встроенных систем с открытыми исходниками. Хороший кандидат — FreeRTOS. Хотя бы документацию к ней перевести на русский язык. Тогда время не будет потрачено совсем впустую, когда школяр поймет всю сложность стоящей перед ним задачи.
Не согласен с автором.
Зачем файловая система, если нужно хранилище данных? Файловая система — это только частный случай такого хранилища.
Текстовый интерфейс? А кто сказал, что компьютер, на котором будет работать эта ОС, вообще сможет выводить текст? Какое оборудование будет использовано? Вполне возможно, что граф.оболочка будет более проста в реализации.
Совместимость? Т.е. создание 100001 устаревшего костыля, дабы иметь возможность запускать устаревшие приложения? Может быть лучше создать свои средства RAD, дабы писать софт было легко?
Даже такая штука как планировщик, и то не обязательна в привычном нам понимании, порой в инете можно встретить разговоры о его ненужности с полным обоснованием.
Зачем файловая система, если нужно хранилище данных? Файловая система — это только частный случай такого хранилища.
Текстовый интерфейс? А кто сказал, что компьютер, на котором будет работать эта ОС, вообще сможет выводить текст? Какое оборудование будет использовано? Вполне возможно, что граф.оболочка будет более проста в реализации.
Совместимость? Т.е. создание 100001 устаревшего костыля, дабы иметь возможность запускать устаревшие приложения? Может быть лучше создать свои средства RAD, дабы писать софт было легко?
Даже такая штука как планировщик, и то не обязательна в привычном нам понимании, порой в инете можно встретить разговоры о его ненужности с полным обоснованием.
Если человек задаёт такие вопросы, то эта статья не для него. Статья для молодых программистов, решивших написать ОС.
Кстати, компьютер может выводить текст и в сокет, и в последовательное устройство, и в JTAG интерфейс. В идеальном случае можно вообще не затруднять себя написанием вывода текста на графическое устройство, а просто передать его на другую систему.
Очень интересная идея с хранилищем данных. С удовольствием послушаю Ваше видение интерфейса взаимодействия с таким хранилищем.
Совместимость — это бич. Крупная компания может позволить себе инвестировать в средства R&D. Кустарь одиночка — нет.
Планировщик. А знаете, в этом вопросе я с Вами полностью согласен и даже могу представить систему без планировщика. И такую систему вполне реально построить на основе синхронных IPC. Фишка в том, что в любой современной системе процессор большую часть времени проводит в режиме низкого энергопотребления. Если каждую подсистему представить в виде черного ящика, который получает запрос, обрабатывает его, передаёт дальше, получает ответ, отрабатывает, отвечает на запрос, то планировщик не нужен. Одна лишь беда при таком подходе — придётся верифицировать пользовательские приложения, иначе любой бесконечный цикл переведёт систему в «режим бессмысленного энергопотребления».
Кстати, компьютер может выводить текст и в сокет, и в последовательное устройство, и в JTAG интерфейс. В идеальном случае можно вообще не затруднять себя написанием вывода текста на графическое устройство, а просто передать его на другую систему.
Очень интересная идея с хранилищем данных. С удовольствием послушаю Ваше видение интерфейса взаимодействия с таким хранилищем.
Совместимость — это бич. Крупная компания может позволить себе инвестировать в средства R&D. Кустарь одиночка — нет.
Планировщик. А знаете, в этом вопросе я с Вами полностью согласен и даже могу представить систему без планировщика. И такую систему вполне реально построить на основе синхронных IPC. Фишка в том, что в любой современной системе процессор большую часть времени проводит в режиме низкого энергопотребления. Если каждую подсистему представить в виде черного ящика, который получает запрос, обрабатывает его, передаёт дальше, получает ответ, отрабатывает, отвечает на запрос, то планировщик не нужен. Одна лишь беда при таком подходе — придётся верифицировать пользовательские приложения, иначе любой бесконечный цикл переведёт систему в «режим бессмысленного энергопотребления».
А вдруг я молод, не опытен, но пишу ос для какого-то специфичного применения, которое сразу отметает все ваши советы? :]
Выводить текст в сокет? Т.е. мне еще сетевой интерфейс реализовывать? или rs232 распаивать? А потом текстовые буфферы, свой readline, шеллы в конце концов? Или проще реализовать GUI на сегментном дисплее и 2 кнопках? :]
Хранилище данных — в общем случае это просто кусок памяти (RAM/ROM/SSD — не так важно, да и границы между ними все обещают стереть) и указатель на него. Это может быть как просто дамп некоторой структуры, которую надо будет загружать самостоятельно, так и SQL-based хранилище, а то и вообще что-то другое. Например, есть такая штука как OLE Compound Storage (файлики винофиса и кучи виндовых приложений), которые позволяют насрать кусок данных в середину файла, при этом не переписывая файл целиком. Цена, которой это реализовано — файловая система внутри файловой системы. Скажете дикость, а решение есть и отлично себя зарекомендовало.
RAD делать с нуля не обязательно, есть замечательные средства разработки, которые можно будет дополнить своим апи/vm или какими там интерфейсами будет нужно пользоваться. Можно даже сделать трансляцию сорсов/бинарей под свою платформу (тут вспоминается java и ее вездесущесть)
Вот, про планировщик вы сами согласны :]
Верификация приложений ничего не даст, тут нужно что-то вроде watchdog для подвисающих подсистем, а решением ситуации в случае эмбеддеда может быть иногда и простой ребут по питанию.
В общем я бы советовал почитать wiki.osdev.org/ и www.osdever.net/ — там все гораздо полезнее, нежели оригинальные советы.
Выводить текст в сокет? Т.е. мне еще сетевой интерфейс реализовывать? или rs232 распаивать? А потом текстовые буфферы, свой readline, шеллы в конце концов? Или проще реализовать GUI на сегментном дисплее и 2 кнопках? :]
Хранилище данных — в общем случае это просто кусок памяти (RAM/ROM/SSD — не так важно, да и границы между ними все обещают стереть) и указатель на него. Это может быть как просто дамп некоторой структуры, которую надо будет загружать самостоятельно, так и SQL-based хранилище, а то и вообще что-то другое. Например, есть такая штука как OLE Compound Storage (файлики винофиса и кучи виндовых приложений), которые позволяют насрать кусок данных в середину файла, при этом не переписывая файл целиком. Цена, которой это реализовано — файловая система внутри файловой системы. Скажете дикость, а решение есть и отлично себя зарекомендовало.
RAD делать с нуля не обязательно, есть замечательные средства разработки, которые можно будет дополнить своим апи/vm или какими там интерфейсами будет нужно пользоваться. Можно даже сделать трансляцию сорсов/бинарей под свою платформу (тут вспоминается java и ее вездесущесть)
Вот, про планировщик вы сами согласны :]
Верификация приложений ничего не даст, тут нужно что-то вроде watchdog для подвисающих подсистем, а решением ситуации в случае эмбеддеда может быть иногда и простой ребут по питанию.
В общем я бы советовал почитать wiki.osdev.org/ и www.osdever.net/ — там все гораздо полезнее, нежели оригинальные советы.
>>Вполне возможно, что граф.оболочка будет более проста в реализации.
покажите пожалуйста мне устройство вывода, способное выводить графику, но не текст? текст в общем случае тоже графика
покажите пожалуйста мне устройство вывода, способное выводить графику, но не текст? текст в общем случае тоже графика
Про сегментные дисплеи забыли? Графика есть, свободы нет. Есть и различные экранчики с низким разрешением, где банально не поместится шрифт (или его будет неудобно читать), зато можно нарисовать 2-3 квадратика и выделять из цветом/яркостью. А до них были еще лампочки с подписями и большие кнопки с подсветкой, но это уже крайности :]
Не вижу особого смысла вывода текста в графическом режиме. Разве лишь только для того, чтобы поместить больше информации на экране.
Давайте раз и навсегда покончим с этим вопросом. Если Вы пишите свою ОС, то написав графическую систему, у вас не хватит желания писать файловую систему. И не будет времени её спроектировать.
Далее, графическая оболочка будет более проста в реализации при условии, что Вы не разрабатываете протокол взаимодействия с этой графической системой, а пишите по готовой спецификации.
Отсюда следует, что примитивный вывод текстовой информации в графическом режиме — не нужен. В этом плане хорошим примером может служить протокол X11R6, который, по сути, позволяет исполнять графические программы на устройстве, где нет видеокарты.
Пожалуй, мне нечего добавить по этому поводу. Если я Вас не убедил — увы.
Давайте раз и навсегда покончим с этим вопросом. Если Вы пишите свою ОС, то написав графическую систему, у вас не хватит желания писать файловую систему. И не будет времени её спроектировать.
Далее, графическая оболочка будет более проста в реализации при условии, что Вы не разрабатываете протокол взаимодействия с этой графической системой, а пишите по готовой спецификации.
Отсюда следует, что примитивный вывод текстовой информации в графическом режиме — не нужен. В этом плане хорошим примером может служить протокол X11R6, который, по сути, позволяет исполнять графические программы на устройстве, где нет видеокарты.
Пожалуй, мне нечего добавить по этому поводу. Если я Вас не убедил — увы.
Вообще, реализация самой графической среды достаточно проста, а вот интерфейс взаимодействия — вот на нем я и залип в свое время. До сих пор иногда пытаюсь придумать что-то красивое, но не выходит, а скатываться до уровня x11/rdp нет никакого желания. И кстате, хоть видяшка оным и не нужна, но они достаточно сильно привязаны к устройству отображения. В последний раз я родил расширяемую систему виджетов, которая была похожа на шаблоны, но как по мне — получилось говно и я забил. Особенно сложно было учитывать особенности ввода/отображения на разных устройствах (например, на TV-экране надо учитывать интерлейсную развертку), что заставляло постоянно пересматривать решения. Хз что делать, но наверное я к этому еще вернусь, это все равно нужно сделать.
А вот файловую систему мне проектировать было совершенно не обязательно, ибо все нужные данные лежали в RAM, а винта/флешки в привычном понимации вообще небыло.
А вот файловую систему мне проектировать было совершенно не обязательно, ибо все нужные данные лежали в RAM, а винта/флешки в привычном понимации вообще небыло.
Тема L4 не раскрыта
Я писал свою ось. Начал в 11 классе, закончил на дипломе (она им и была).
Мое мнение: собственная ось – это программа ради программы. Не стоит надеяться на то, что можно написать что-то, что будет иметь успех (тем более коммерческий) – это очень сложно, очень долго и есть линукс, причем линукс есть для всего: и для пк и для эмбедед, а если его нет, то его можно собрать. бесплатно.
А вообще пишите оси, это весело! И не задумывайтесь о проблемах, которые описаны в этой статье. Это не касается вашей оси: она только ваша и пофигу как там память выделяется!
Мое мнение: собственная ось – это программа ради программы. Не стоит надеяться на то, что можно написать что-то, что будет иметь успех (тем более коммерческий) – это очень сложно, очень долго и есть линукс, причем линукс есть для всего: и для пк и для эмбедед, а если его нет, то его можно собрать. бесплатно.
А вообще пишите оси, это весело! И не задумывайтесь о проблемах, которые описаны в этой статье. Это не касается вашей оси: она только ваша и пофигу как там память выделяется!
О последнем абзаце. Если реализовывать существующий API, то это никому не будет интересно. Зачем нужна ещё одна реалция POSIX, если их уже множество, среди которых есть Linux? Поэтому, если уж и писать новую ОС, то нужно продумывать именно новую систему: файлы, задачи, память, GUI — хоть что-то из этого нужно проектировать заново. А если API или GUI будут действительно новыми, то приложения придётся переписывать.
Поэтому, тут путь эволюции ОС должен быть паразитическим: сделать какую-нибудь coNewOS подобную coLinux, чтобы можно было запускать новое программное окружение в существующей OS. А там, вполне возможно, программисты потянутся, если действительно окружение будет удобным. Тогда можно уже им предлагать и native-ядро. В принципе, людям интересно писать и новые текстовые редакторы, и новые браузеры, просто смысла нет, если нет альтернативной платформы.
Поэтому, тут путь эволюции ОС должен быть паразитическим: сделать какую-нибудь coNewOS подобную coLinux, чтобы можно было запускать новое программное окружение в существующей OS. А там, вполне возможно, программисты потянутся, если действительно окружение будет удобным. Тогда можно уже им предлагать и native-ядро. В принципе, людям интересно писать и новые текстовые редакторы, и новые браузеры, просто смысла нет, если нет альтернативной платформы.
Я немного не согласен с Вами.
POSIX API может быть и не самый лучший интерфейс, к тому же в старых стандартах ещё и имеет проблемы с многопоточнотью. В этом плане мне видится интересным путь использования интерфейсов, нечто вроде COM технологии.
Однако, давайте будем реалистами. Система, под которую придётся заново писать весь софт — нежизнеспособна. Разработчики и компании, имеющие значительные ресурсы и большую пользовательскую базу, могут себе позволить экспериментировать. Можно постепенно добавлять функциональность, не ломая совместимость со стандартами или ломая очень осторожно. Вспомните, сколько шума произвели расширения общепринятых Unix стандартов компанией Microsoft, когда остальным разработчиками приходилось под них подстраиваться. О том, что может себе позволить великан, пигмею даже мечтать вредно.
Попробую пояснить: представьте реакцию сообщества, если кто-то неизвестный из ниоткуда заявит, что написал «принципиально новую ОС», ни с чем не совместимую, под которую нет программного обеспечения. Может с десяток соратников и соберёт, но даже 10 человек погоды не сделают. Вероятность успеха ничтожна.
Разумеется, всё вышесказанное — IMHO.
POSIX API может быть и не самый лучший интерфейс, к тому же в старых стандартах ещё и имеет проблемы с многопоточнотью. В этом плане мне видится интересным путь использования интерфейсов, нечто вроде COM технологии.
Однако, давайте будем реалистами. Система, под которую придётся заново писать весь софт — нежизнеспособна. Разработчики и компании, имеющие значительные ресурсы и большую пользовательскую базу, могут себе позволить экспериментировать. Можно постепенно добавлять функциональность, не ломая совместимость со стандартами или ломая очень осторожно. Вспомните, сколько шума произвели расширения общепринятых Unix стандартов компанией Microsoft, когда остальным разработчиками приходилось под них подстраиваться. О том, что может себе позволить великан, пигмею даже мечтать вредно.
Попробую пояснить: представьте реакцию сообщества, если кто-то неизвестный из ниоткуда заявит, что написал «принципиально новую ОС», ни с чем не совместимую, под которую нет программного обеспечения. Может с десяток соратников и соберёт, но даже 10 человек погоды не сделают. Вероятность успеха ничтожна.
Разумеется, всё вышесказанное — IMHO.
Я, например, пишу на Go, не потому что это язык, который придумала Google, а потому что это просто хороший для многих дел язык. Ruby, например. Тоже новый язык, тоже требовал переписываний, однако, многим он пришёлся по вкусу. То есть, люди готовы переписывать, если платформа даёт им удобства некоторые.
А если они пишут нечто новое, то тогда уж тем более могут выбрать новый инструмент.
Поэтому я и говорю, что если сейчас развивать OS, то её надо развивать именно как платформу, которая, возможно, будет работать и под Linux/Windows. Ну и, естественно, давать людям некие фишечки.
А если они пишут нечто новое, то тогда уж тем более могут выбрать новый инструмент.
Поэтому я и говорю, что если сейчас развивать OS, то её надо развивать именно как платформу, которая, возможно, будет работать и под Linux/Windows. Ну и, естественно, давать людям некие фишечки.
а мне вспомнился KDE — весь софт свой :]
Вопрос к автору: А вы сами писали ОС?
Или наоборот, ченджлоги показывают ошибки в проектировании и вызывают еще больший интерес к реализации, вида «ну все, теперь то я таких глупых ошибок не сделаю». Я действительно хотел и хочу написать ОС, может быть таки дойдут руки.
Спасибо. Никогда не думал о чеджлогах в таком ключе. А оно ж действительно — готовый роадмап :)
Так. Реципиент не обязан всё делать в гордом одиночестве. Хотя, на деле, есть очень неплохие embedded-решения сделанные именно одним человеком, потому что, когда OS делается в гордом одиночестве, она стройнее и логичнее получается, если, конечно, автор адекватен. Такие поделки часто используются в роботах. И за них часто дают научно-инженерные премии в европе.
Но… Если человек хочет чего-то стремительно растущего, то понятно, что он должен привлечь девелоперов… Тут, в принципе, ресурс есть: студенты, которым надо писать бакалаврские, магистранты, просто интересующиеся. Нужно только предложить нечто действительно захватывающее. И самое сложное, это именно сконструировать в своей голове образ этого чего-то захватывающего, а не объём кода и changelog'ов.
Но… Если человек хочет чего-то стремительно растущего, то понятно, что он должен привлечь девелоперов… Тут, в принципе, ресурс есть: студенты, которым надо писать бакалаврские, магистранты, просто интересующиеся. Нужно только предложить нечто действительно захватывающее. И самое сложное, это именно сконструировать в своей голове образ этого чего-то захватывающего, а не объём кода и changelog'ов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Несколько советов молодым программистам, решившим написать свою операционную систему