Прочитал книжку Вирта про Оберон и разработку ОС. Прифигел. Ядро многозадачной ОС с графическим интерфейсом уместилось в 135 килобайт. Написано на ASM и Обероне. Работает начиная от 386 процессора. Мысленно сравнил с гигабайтами современных ОС и гигагерцовыми процессорами, гигабайтами оперативки.
Что делают все современные разработчики процессоров, ОС, и прочего? 8 ядер, 16 гигабайт и все тормозит... Куда катится этот мир...
135 килобайт
Всего 33 сообщ.
|
Показаны 1 - 20
135 килобайт
Re[texu]:
пилят народное бабло очевидно.. к стате у современой материнки ппраметров на мегабайт что б её запустить и определить чё навтыкано..
Re[to myself]:
Возьмем, к примеру, Corel первых выпусков. Он занимал порядка 15 трёхдюймовок = 21 мегабайт, после распаковки - мегабайт 30. За 20 лет функциональность его расширилась не особо сильно. Но запустить новый Corel на 486 компьютере не выйдет. Рост прироста его новой функциональности, будучи реализованной путем бесконечного наследования объектов и раздувания кода и потребной оперативной памяти в условиях практически полного отсутствия аппаратных ограничений, явно непропорционален росту программного кода.
Corel взят просто как пример, всё относится ко всем популярным программам. Вся из функциональность была реализована в первых выпусках, дальше началось приделывание свистелок.
Рост возможностей железа сыграл с программистами злую шутку. Вместо оптимизации кода ждём нового процессора, который легко перемелет наш унылый франкенштейнокод. Думать не надо. Теорию алгоритмов изучать не надо, архитектуру процессора и систему его команд тоже.
Используем готовые компоненты и библиотеки, также неоптимальные и с кучей ошибок. (Вспомним недавнюю уязвимость в SSL). В то же время есть системы, релизованных правильно, стартующих за единицы секунд, умещающихся в 3-5 мегабайт, qnx например.
В продукции для массового потребителя уже давно наблюдается странная ситуация: вычислительные мощности, объёмы памяти растут, а компьютеры работают все медленнее и медленнее. По-идее, грамотно спроектированное и реализованное на безопасном языке (громадный булыжник в огород С/С++) ядро консъюмерской операционной системы может использоваться десятилетиями, расширяясь новыми функциями. Парадигма рабочего визуального пространства в виде прямоугольных областей на экране будет ещё очень долго единственной.
Правильно спроектированная модель такой системы позволит легко и просто наращивать как её возможности, так и использовать новые физические устройства.
(Чё-то понесло сегодня...)
Corel взят просто как пример, всё относится ко всем популярным программам. Вся из функциональность была реализована в первых выпусках, дальше началось приделывание свистелок.
Рост возможностей железа сыграл с программистами злую шутку. Вместо оптимизации кода ждём нового процессора, который легко перемелет наш унылый франкенштейнокод. Думать не надо. Теорию алгоритмов изучать не надо, архитектуру процессора и систему его команд тоже.
Используем готовые компоненты и библиотеки, также неоптимальные и с кучей ошибок. (Вспомним недавнюю уязвимость в SSL). В то же время есть системы, релизованных правильно, стартующих за единицы секунд, умещающихся в 3-5 мегабайт, qnx например.
В продукции для массового потребителя уже давно наблюдается странная ситуация: вычислительные мощности, объёмы памяти растут, а компьютеры работают все медленнее и медленнее. По-идее, грамотно спроектированное и реализованное на безопасном языке (громадный булыжник в огород С/С++) ядро консъюмерской операционной системы может использоваться десятилетиями, расширяясь новыми функциями. Парадигма рабочего визуального пространства в виде прямоугольных областей на экране будет ещё очень долго единственной.
Правильно спроектированная модель такой системы позволит легко и просто наращивать как её возможности, так и использовать новые физические устройства.
(Чё-то понесло сегодня...)
Re[texu]:
Зато в многогигабайтных операционках уйма библиотек и API, без которых программистам пришлось бы всё писать вручную и с нуля, а так взял готовый системный модуль и понеслась.
Справедливости ради надо заметить, что бОльшую долю объема занимает не код ядра, а GUI и встроенные приложения и драйвера.
Справедливости ради надо заметить, что бОльшую долю объема занимает не код ядра, а GUI и встроенные приложения и драйвера.
Re[texu]:
Взаимовыгодное сотрудничество для разработчиков ПО и железа - Рост возможностей железа позволяет писать ПО с меньшими усилиями по оптимизации снижая затраты на создание ПО. Рост требований ПО к железу заставляет пользователей покупать новые компьютеры... Если бы современное ПО могло бы нормально работать на 486 процессоре, то люди меняли бы компьютеры гораздо реже - по мере того как они ломаются, а сейчас обычно меняют каждые 2-3года т.к. новое ПО требует больших возможностей железа.
Re[texu]:
Если не брать категорию "яростное шко-ло-ло", народ сидит на одних и тех же программах в одних и тех же релизах лет по 5-8. Работает - и хорошо, нечего от добра добра искать...
Re[texu]:
у стандартных библиотек есть одно интересное свойство
легкая генерация нового кода без кардинального переписывания под каждый новый проект
даже два
легче багофиксить
код ре-юз, йопта
легкая генерация нового кода без кардинального переписывания под каждый новый проект
даже два
легче багофиксить
код ре-юз, йопта
Re[Benny]:
от: Benny
у стандартных библиотек есть одно интересное свойство
легкая генерация нового кода без кардинального переписывания под каждый новый проект
даже два
легче багофиксить
код ре-юз, йопта
Если бы код писался нормально, а то сто тыщщ мульёнов ошибок и сервис-паки каждую неделю. В итоге багофиксинья получается такая багофикса вместо программы, что жуть. Сплошные JMP <новая заплатка>/RET <на старое место>.
Re[texu]:
с одной стороны - самоподпитывающийся процесс кодирования ради кодирования
с другой - все таки много чего нового появилось с тех пор. От мобилок и планшетов до торговли, вирусов и прочего.
громоздкость появляется в процессе прибавления каких нибудь 10% функционала. Как в стекле. За улучшения ттх на 10% нужно заплатить 100% добавки к изначальной цене.
еще аспект - для написания нормального кода нужны нормальные программисты, а не кетайцы с индусамме. А для получения нормальных программистов нужно их обучить, и не с пустого места. Что делает код очень дорогим. При существующих необходимых объемах принципиально нового кода без кетайцев не обойтись.
Что приводит нас опять к самоподпитывающемуся процессу кодирования ради кодирования
с другой - все таки много чего нового появилось с тех пор. От мобилок и планшетов до торговли, вирусов и прочего.
громоздкость появляется в процессе прибавления каких нибудь 10% функционала. Как в стекле. За улучшения ттх на 10% нужно заплатить 100% добавки к изначальной цене.
еще аспект - для написания нормального кода нужны нормальные программисты, а не кетайцы с индусамме. А для получения нормальных программистов нужно их обучить, и не с пустого места. Что делает код очень дорогим. При существующих необходимых объемах принципиально нового кода без кетайцев не обойтись.
Что приводит нас опять к самоподпитывающемуся процессу кодирования ради кодирования
Re[texu]:
от:texu
Прочитал книжку Вирта про Оберон и разработку ОС. Прифигел. Ядро многозадачной ОС с графическим интерфейсом уместилось в 135 килобайт. Написано на ASM и Обероне. Работает начиная от 386 процессора. Мысленно сравнил с гигабайтами современных ОС и гигагерцовыми процессорами, гигабайтами оперативки.
Что делают все современные разработчики процессоров, ОС, и прочего? 8 ядер, 16 гигабайт и все тормозит... Куда катится этот мир...Подробнее
А вот про это что думаете? http://files.mail.ru/4E94C889D35B4BE4AAF78C172BB461EE
Re[texu]:
от:texu
Прочитал книжку Вирта про Оберон и разработку ОС. Прифигел. Ядро многозадачной ОС с графическим интерфейсом уместилось в 135 килобайт. Написано на ASM и Обероне. Работает начиная от 386 процессора. Мысленно сравнил с гигабайтами современных ОС и гигагерцовыми процессорами, гигабайтами оперативки.
Что делают все современные разработчики процессоров, ОС, и прочего? 8 ядер, 16 гигабайт и все тормозит... Куда катится этот мир...Подробнее
Ни а чем :D
С таким же успехом я могу заявить, что я написал на асм и с++ многозадачную ОС с графическим интерфейсом, которая занимает 13,5 кБайт и работает вообще на 8-ми битных процессорах при микроамперном потреблении.
Ну и не забудем причитание:
Куда катится ваш оберон???
Re[stemflame]:
от:stemflame
Ни а чем :D
С таким же успехом я могу заявить, что я написал на асм и с++ многозадачную ОС с графическим интерфейсом, которая занимает 13,5 кБайт и работает вообще на 8-ми битных процессорах при микроамперном потреблении.
Ну и не забудем причитание:
Куда катится ваш оберон???Подробнее
Увы, в этом дебильном мире правильные решения пробиваются с трудом. Тот же Си, созданный как высокоуровневый ассемблер для машин серии PDP, до сих пор несет в себе черты давно умершей архитектуры. Американские вояки не зря ведь при разработке языка для своих милитаристских систем отбирали проекты, основанные на Паскале. Си и близко не был допущен к критическим приложениям. Результат - практически безопасный язык Ада. Используется до сих пор в ответственных приложениях. В тех же европах использоввание си-подобных языков для медицины, военных приложений, атомной энергетики и промышленности запрещено.
По сравнению с 1000-страничными томами учебников по С/с++ 30 страниц описания Оберона - просто шедевр. Так что катится он в нужном направлении. ПО для томографов пишут на Модуле и Обероне. А потому что опасно.
Так и вы же говорите, что "...я могу сказать, что написал...".
А Вирт написал, еще в далёком 86 году. И работает до сих пор.
Хе-хе.
Re[texu]:
от:texu
Увы, в этом дебильном мире правильные решения пробиваются с трудом. Тот же Си, созданный как высокоуровневый ассемблер для машин серии PDP, до сих пор несет в себе черты давно умершей архитектуры. Американские вояки не зря ведь при разработке языка для своих милитаристских систем отбирали проекты, основанные на Паскале. Си и близко не был допущен к критическим приложениям. Результат - практически безопасный язык Ада. Используется до сих пор в ответственных приложениях. В тех же европах использоввание си-подобных языков для медицины, военных приложений, атомной энергетики и промышленности запрещено.
По сравнению с 1000-страничными томами учебников по С/с++ 30 страниц описания Оберона - просто шедевр. Так что катится он в нужном направлении. ПО для томографов пишут на Модуле и Обероне. А потому что опасно.
Так и вы же говорите, что "...я могу сказать, что написал...".
А Вирт написал, еще в далёком 86 году. И работает до сих пор.
Хе-хе.Подробнее
Хм... Машины семейства PDP, вообще-то, использовались в АСУ ТП РВ. Жесткого, прошу заметить, реального времени. Для управления опасными техпроцессами. И заменить их там трудно по сей день. И бортовая авионика многих по сей день летающих самолетов на этом же семействе сделана. А вот про вражьих вояк - можно пруф, о каких системах речь? Если об экспертных, вроде пролога, то понятно - такое на сях писать десятилетиями.
З.Ы. Гибкости и удобства PDP-11 сегодняшним процам очень не хватает.
Re[texu]:
от: texu
По сравнению с 1000-страничными томами учебников по С/с++ 30 страниц описания Оберона - просто шедевр. Так что катится он в нужном направлении.
Оберон такой маленький, потому что из него выкинули все "опасные" возможности. Которые начинаются в учебниках Си как раз с 31-й страницы :)
Re[texu]:
от:texu
отбирали проекты, основанные на Паскале. Си и близко не был допущен к критическим приложениям. Результат - практически безопасный язык Ада.
....
В тех же европах использоввание си-подобных языков для медицины, военных приложений, атомной энергетики и промышленности запрещено.
....
ПО для томографов пишут на Модуле и Обероне. А потому что опасно.Подробнее
По Вашей логике, так чемпионом по надежности и безопасности должен получится Java? :roll2:
Re[Nicholaes]:
от:Nicholaes
Хм... Машины семейства PDP, вообще-то, использовались в АСУ ТП РВ. Жесткого, прошу заметить, реального времени. Для управления опасными техпроцессами. И заменить их там трудно по сей день. И бортовая авионика многих по сей день летающих самолетов на этом же семействе сделана.Подробнее
Интересно было бы почитать про данные системы. Можете ли вы привести названия, ссылки? Вобщем, больше конкретики.
Re[stemflame]:
PDP-8 в США выпускалась чуть ли не до середины 2000 гг.
На СМ1420 мы в свое время делали системы виброиспытаний аж на 64 канала. Трясли, читали данные с акселерометров, сохраняли на жесткий диск ажно 2Х2.5 мегабайта.
Архитектура PDP чудесна, система команд - просто сказка. Кроме шуток.
На СМ1420 мы в свое время делали системы виброиспытаний аж на 64 канала. Трясли, читали данные с акселерометров, сохраняли на жесткий диск ажно 2Х2.5 мегабайта.
Архитектура PDP чудесна, система команд - просто сказка. Кроме шуток.
Re[stemflame]:
от: stemflame
Оберон такой маленький, потому что из него выкинули все "опасные" возможности. Которые начинаются в учебниках Си как раз с 31-й страницы :)
А нужны они, опасные возможности? Чего они дают? Возможность поднять ЧСВ?
Создать конструкцию, которая миллион раз сработает, а на миллион первый гавкнется по неизвестной причине, утянув с собой в пучины окияна очередой лайнер?
Re[Shovg]:
от: Shovg
По Вашей логике, так чемпионом по надежности и безопасности должен получится Java? :roll2:
Ага, после допиливания еще в течение лет 20.
Re[texu]:
от:texu
PDP-8 в США выпускалась чуть ли не до середины 2000 гг.
На СМ1420 мы в свое время делали системы виброиспытаний аж на 64 канала. Трясли, читали данные с акселерометров, сохраняли на жесткий диск ажно 2Х2.5 мегабайта.
Архитектура PDP чудесна, система команд - просто сказка. Кроме шуток.Подробнее
[quot] Последняя модель PDP-8 была произведена в 1979 и называлась «CMOS-8s», потому что использовала микропроцессоры КМОП (англ. CMOS). Они имели неконкурентоспособную цену, и проект провалился.[/quot]
Надо почитать, но я так подозреваю, что "волшебной" была архитектура пдп-11. Но ее почему то практически никто не реализовывал в микропроцессорах.
PS: а на х86 производят системы чпу для управления 64-мя следящими приводами ;)
(Пишут на Си, естественно)
