Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет alksnis ([info]alksnis)
@ 2009-02-09 10:27:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Безработных российских программистов направят создавать отечественную операционную систему
Как пишет "Независимая газета", в четверг в Кремле состоится первое заседание образованного при президенте РФ Совета по развитию информационного общества. Среди предлагаемых к обсуждению вопросов будет ситуация в IT-отрасли в связи с кризисом.

Одним из путей преодоления кризиса видится организация общественных работ для безработных IT-специалистов. В 30-е годы прошлого века в Германии безработных направляли на строительство дорог, у нас предлагается направить безработных программистов на создание отечественной операционной системы. 

Но  я очень сомневаюсь, что подобными мерами можно заинтересовать высококвалифицированных специалистов остаться в России, отвергнув заманчивые приглашения на работу в Индию, Китай или в США. Ведь общественные работы, предусматривают минимальную оплату труда, практически за одну похлебку. 

И поэтому я, оставаясь сторонником создания отечественной операционной системы, с большим скепсисом отношусь к подобным планам. Я вижу выход из сложившегося кризиса во вложении государством денег в масштабные инфраструктурные проекты, включая и специальный проект создания конкурентноспособного отечественного программного обеспечения.

Кстати, именно реализация масштабных инфраструктурных проектов в условиях кризиса считается и в Китае, и в США приоритетными путями его преодоления и поэтому они сейчас их планируют и реализуют.  Мы же, как всегда, "впереди планеты всей" -  у нас считается главным антрикризисным мероприятием раздать бюджетные деньги "своим" банкам, которые их успешно осваивают, переводя на Запад.


(Читать комментарии) - (Добавить комментарий)


[info]ob3r0n@lj
2009-02-09 05:38 (ссылка)
так. начнем с того, что самое сложное. дальше по сложности идет разработка компилятора.

студенты не операционные пишут. мне тут один студент из бауманки ратовал как он в качестве дипломной работы ос написал. оказалось он написал первичный загрузчик и часть вторичного, с возможностью вводить команды.

простите, мы это в 10м классе писали.

я знаю только одно место, где студенты пишут части операционной системы как курсовые работы. это простите студенты таненбаума, а ос - миникс.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 05:50 (ссылка)
> я знаю только одно место, где студенты пишут части операционной системы как курсовые работы
Есть еще одно место - университет в Беркли, UCB. Один из основных разработчиков, не считая "папы Кена", ОС UNIX. А minix - это было уже после UNIX и по мотивам UNIX...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 05:51 (ссылка)
Ну университет в Беркли забыл, да. Еще Массачусец.

Короче не Россия точно.


Minix была после Unix, но до Linux. Да и сейчас развивается. Minix3 к примеру.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 06:01 (ссылка)
MTI пытался что-то свое сваять, но не хватило силенок. Поэтому был в основном "на подхвате" у UCB. Еще Дублинцы пытались вякать. Тоже, в общем-то, без особого успеха. Нужен технологический прорыв в программировании, как труде.

В СССР были БЭСМ и МИР. Там тоже были операционки. И появились они раньше, чем UNIX, в 60-х годах. Но очень они были своеобразные...

Школа советского программирования, как одно их направлений кибернетики, была уничтожена в СССР по идеологическим причинам (http://v-alksnis.livejournal.com/35865.html?thread=2377753#t2377753).

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:04 (ссылка)
ну да. если то называть операционками (по сути программы ввода-вывода), то я тоже когда-то написал свою ос.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 06:08 (ссылка)
Первая и главная задача, которая была решена, особенно в БЭСМ, - это оригинальная стратегия управление ресурсами машины. Решение было комплексным - аппаратно-программным. Конвейерную предобработку команд америкосы сумели повторить в своих массовых изделиях только в конце 90-х годов прошлого века.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:09 (ссылка)
что за бред?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 06:27 (ссылка)
> что за бред?
Понятие "автомат" Вам неведомо? А машина Тьюринга?

Программами исправляется и дополнятся то, что сложно или очень дорого реализовать в "железе".

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:30 (ссылка)
ну да.

учусь на кафедре математической теории интеллектуальных систем мехмата мгу и не знаю что такое автомат и машина тьюринга ;)))

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 06:42 (ссылка)
Тогда ОБЯЗАНЫ знать, что любой автомат может быть реализован как в "софте", так и в "железе". Поэтому, технологически конвейерную предобработку команд, например в Intel, америкосы смогли осилить в процессорах только начиная с Pentium. У Motorolla несколько иная организация процессора, она ближе к DEC (асинхронным процессорам), довлеет к RISC. Для RISC конвейер вообще практически нонсенс. Если только шину, как в Alpha и Sparc, сильно параллелить и выполнять параллельно зависимые (связанные) вычисления.

А реализация ОС для БЭСМ учитывала аппаратную реализацию конвейерного ускорителя.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:45 (ссылка)
> Тогда ОБЯЗАНЫ знать, что любой автомат может быть реализован как в "софте", так и в "железе"

придам этому другую интерпретацию:
"реализовать" - построить алгоритм
Машина Тьюринга - формальное определение слову алгоритм.
Ну и понятное дело, что делать с конечными автоматами.


я так понимаю о БЭСМ идет вопрос о тех микросхемах, в которых не рассчитывали на минимальное число транзисторов.
но тогда и не надо говорить об микропроцессорах типа интела.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 07:08 (ссылка)
> но тогда и не надо говорить об микропроцессорах типа интела
Конвейерная предобработка команд предусматривает пошаговое (потактовое) исполнение команды. В БЭСМ одновременно исполнялось до восьми команд. Сложность возникает в случае исполнения команд условного перехода (предикаты), CISC-команд (операции с плавающей арифметикой, вычисление функций и т.д.) и прерываниями. Поэтому, технологически америкосы смогли это осилить на 30 лет позже СССР.

И не в Intel проблема. Архитектура Intel сама по себе у***щная. Чипы DEC, SUN, Moto, гораздо более логичны. Но "все сосут ту сисю, которую им подсунула в свое время "Большая Голубая Мама" из-за опоздания на полгода Стива Джобса. А линейка БЭСМ к этому времени уже прекратила свое существование опять-таки стараниями "Большой Голубой Мамы", поскольку была команда перейти на ЕС ЭВМ (IBM-360).

(Ответить) (Уровень выше)


[info]lcd_admin@lj
2009-02-13 05:11 (ссылка)
Если я еще не окончательно забыл чему меня учили - то конвеер появился еще в 8086.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-13 06:13 (ссылка)
Тот конвейер, который был реализован в БЭСМ - это псевдопараллельные вычисления. Аналог - hypertreading.

(Ответить) (Уровень выше)


[info]potan@lj
2009-02-09 06:00 (ссылка)
Линус то свое ядро где написал?
Компиляторы, конечно, сложнее, но тоже уже поставлены на поток.

Проблемы в разработке ОС в дизайне, а не в кодировании.

Что качается действительно сложных систем, то это САПР, системы управления производством, управление боем, управление робототизированными комплексами. Следующий уровень - СУБД и системы обработки транзакций в реальном времени.
ОС до этих задач по сложности очень далеко.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:03 (ссылка)
ну начнем с того, что

0) разработка компилятора легче чем написание ос. прописные истины блин.
а) он все таки талантливый программист
б) он написал как раз что-то очень простое. свое развитие ядро получило уже в коммьюнити
в) дизайн уже кучу раз описан переописан. тем же таненбаумом.
г) давно ли базы данных стали сложными в разработке? я понимаю там нагрузка и т.д. но это всего лишь алгоритмы
д) "ОС до этих задач по сложности очень далеко." - бугагагага

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]potan@lj
2009-02-09 06:20 (ссылка)
Я участвовал в разработки подсистемы в ядре FreeBSD и сидел в соседней комнате с разработчиками компилятора. Так что имею представление о сложности и того, и другого.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:26 (ссылка)
Оо. почему в основном знающие люди говорят обратное.

как-то странно вообще говоря. разаботчики комплятора в одной комнате, разработчики ядра фрибсд - в другой.

такой кооператив.

вообще не представляю, что за компания, занимающаяся разработкой подсистем ядра.

если быть точным у фрибсд же закрытый тип разработки, т.е. официальные патчи могут вносить только те, кто является грубо говоря freebsd team. покажите вашу фамилию в каком-нибудь списке разработчиков/мантейнеров.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 06:33 (ссылка)
> у фрибсд же закрытый тип разработки
И это правильно. "Кто в лес, кто по дрова" - это предоставим Linux-у. Ебиноначалие существенно уменьшает затраты на борьбу с "белым шумом". У Linux, кстати, для ядра тоже закрытый тип разработки. Просто в BSD решили, что ядро - это еще некий минимальный уровень утилит. С моей точки зрения решение более оправданное.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:38 (ссылка)
в линукс писать что-то для ядра может кто хочет. понятное дело, что архитектурой ядра занимаются не первые попавшиеся.
да и заплатки вначале проверяются мантейнерами. это очевидно.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 06:45 (ссылка)
Я тоже для решения своих конкретных задач писал свои модули в ядро. Иначе их было не решить. Иначе получались не задачи, а монстрообразные кракозябры. Но это не означает, что мои конкретные решения могли быть востребованы в массовом применении.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:46 (ссылка)
а я про именно это ничего и не говорил.

(Ответить) (Уровень выше)


[info]potan@lj
2009-02-09 06:35 (ссылка)
Это было в разных организациях.
В "Русском экспрессе" (хостинг-провайдер) разрабатывали систему виртуализации на базе FreeBSD. Для нее в ядре много чего пришлось менять, от файловой системы, до планировщика. В основную ветку это не передавалось.
С компиляторщиками я общался в "Институте Точной Механики". Они разрабатывали распаралеливатель к gcc. Нишу на рынке найти не смогли, но задачи решали действительно сложные. Мне их подход не очень нравился (все писать на C++ и обмениваться данными в XML), но даже переписывание всего на более подходящий для этих задач Haskell дело не сильно упрощало. Сам я там занимался моделированием аппаратуры на Haskell и разработакми тестов на ассемблере SPARC.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:40 (ссылка)
подождите. распаралеливатель к компилятору и компилятор - разные вещи. (не говоря уже о том, чем им не приглянулся MPI).

в любом случае, решение одной задачи по теме ядра и решение одной задачи по теме компиляторов вообще никак не говорит о сложности создания одного и другого. ну может быть самую малость.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 06:48 (ссылка)
> распаралеливатель к компилятору и компилятор - разные вещи
Посмотрите, как элегантно на уровне грамматик предшествования, решена эта задача Трахтенгерцем.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:50 (ссылка)
что-то я не осилил как утверждение того, что скажем MPI и gcc - разные вещи, относится к решению проблемы Трахтенгерцем

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 07:13 (ссылка)
А там реализованы совсем другие идеи и грамматики.

(Ответить) (Уровень выше)


[info]potan@lj
2009-02-09 07:23 (ссылка)
MPI - не распаралеливатель, а библиотека для ручного распаралеливания. К тому же ориентированная на слабосвязанные системы, типа кластеров. Скорее вы имеете ввиду OpenMP.
Они же ориентировались на многоядерные процессоры.
Задачи там сходные и оптимизатором в компиляторе, а это самая сложная его часть.

(Ответить) (Уровень выше)


[info]realurix@lj
2009-02-09 06:11 (ссылка)
Вы путаете задачи системного и прикладного уровня. Не зря существует в программировании всего две специализации - системный программист и прикладной программист. Это две совершенно различных идеологии, два принципиально различных мировоззрения.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:27 (ссылка)
не путаю.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]realurix@lj
2009-02-09 06:29 (ссылка)
Это не Вам.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:30 (ссылка)
сорри

(Ответить) (Уровень выше)


[info]potan@lj
2009-02-09 06:39 (ссылка)
Если пхп-программистов и настройщиков бухгалтерских пакетов за программистов не считать, то различия не очень серьезные.
А разработка компилятора от разработки пакета символьной математики вообще не сильно отличается.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 06:41 (ссылка)
> А разработка компилятора от разработки пакета символьной математики вообще не сильно отличается.

одно есть по сути часть другого.

(Ответить) (Уровень выше)


[info]sadko4u@lj
2009-02-09 10:08 (ссылка)
Я - студент, пишу ОС (хобби такое). Занятие нелёгкое. Там, где прикладники даже не задумываются, приходится считаться с имеющимися ресурсами ПК: ОЗУ, набором команд, производительностью и пр. А, ведь, для того, чтобы ОС работала, нужно много чего по-новому написать (даже ту же libc, например).
Согласен, что большинство доходит до реализации загрузчика и останавливается. Потому что дальше сложнее: синхронизация, планирование, распределение ресурса, работа с различного типа устройствами, хранение данных, загрузка и выполнение программ, реализация протоколов, интерфейсов, системных вызовов и пр. Короче, сам себе хозяин, но делать надо всё по уму. Иначе придётся писать потом всё заново.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ob3r0n@lj
2009-02-09 10:11 (ссылка)
как хобби ты можешь писать хоть реализацию искусственного интеллекта - всем наплевать. результату и достижения впечатляющие у тебя вряд ли будут, так что пиши в своей удовольствие.

а о сложностях, которые возникают я догадываюсь. во всяком случае о тех очевидны, которые ты описал.

(Ответить) (Уровень выше)


(Читать комментарии) -