А мы тут этот момент упустили. Даже на Комп.Хрониках было сравнение пня60 и 486, где пень победил. Но это как раз первые выпуски пней.

Так что да, под 486 в нашем контексте нужно понимать 486 с ЕДО памятью на 72 пина и контроллерами PCI. Это и будет вторая половина 90х.

и далее по списку пень1го поколения - это материнка под сокет7++ с sdram+udma 33/66, pci/agp кому уж как повезло, но именно что не самые первые поколения, которым еще и мультикарты нужны.

На 486dx66 прекрасно слушали mp3 под FreeBSD, но да, было уныло. Под виндой было вообще плохо - P133 было дороговато, но у мажоров на них всё более-менее работало, но не летало. Да, был период, когда всё тормозило у всех, кроме некоторых счастливчиков - была выжималка денег.

на P133 не было SDRAM, там были те же 72-pin EDO DRAM. Они мало чем отличались от тогдашних 486 (кроме скорости). Было вполне нормой дома 486DX2/66 или DX4/100 (или аналогичное от AMD), а на работе P133. Правда бывало и что на работе стояла техника хуже чем дома, а у некоторых экспулатировались всякие EC1841 c болгарской кодировкой МИГ

На 486dx66 прекрасно слушали mp3 под FreeBSD, но да, было уныло.

Повезло с платой. У меня было какое-то OPTi VLB без кэша, типичные 128кбит не взлетало ни в какой позе. после вколхозжевания туда 5x86-133 уже можно было.

на P133 не было SDRAM, там были те же 72-pin EDO DRAM.

На поздних платах появились. Так же как и EDO на 486 появились в конце цикла.

походу каст не сработал.

Я догадывался, что такое может быть, поэтому и спросил. Спасибо за инфу. Теперь будем знать, что если с первого раза забыл кого-то кастануть, то исправлять это упущение уже бесполезно.

А можно наоборот использовать это, как фичу. Здесь когда-то давно кто-то тему поднимал, как упоминая кого-то, выделить для красоты его имя тегом [user], но чтоб он при этом никаких уведомлений не получал. Теперь способ найден. :-)

486-е в 2000м это не те же 486, которые в 89м, оно развивалось параллельно с пнями.

Кстати да, этот момент я упустил.

Сейчас хотел возразить по другому пункту, касающемуся 2k года, но решил проверить, и обалдел: их аж до 2007 выпускали!

Правда, 8086 ещё круче. Их аналоги выпускали по меньшей мере до 10-х годов, а может и до сих пор выпускают. Не Интел, конечно.

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

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

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

Контракты с расширенной поддержкой - лет 25-40. Обычно государственные, военные, или от очень крупных корпораций. Просто не во всех отраслях так всё быстро меняется.

Контракты с расширенной поддержкой - лет 25-40. Обычно государственные, военные, или от очень крупных корпораций.

Но это действительно достоверная инфа или предположения, основанные на том, что у нас такие системы всё ещё есть?

Я не могу предъявить доказательства, но я работал у такого клиента intel'а, у которого как раз заканчивался контракт на расширенную поддержку на странное (80186), из-за этого переходили на ARM, то есть делали новый контроллер под старое железо и древние шины родом еще с 60-х. И на другую линейку этого странного контракты еще не заканчивались. Тут как бы нет требования производить и держать линии, на сколько я понимаю задача обеспечить N штук в месяц на замену сломавшемуся/сгоревшему. Вот как ты думаешь, как старые mainfram'ы IBM экспулатируют? Там же ремонты тоже нужны, а они на кучу всего завязаны. Да, что-то удается заменить на новые аналоги, но на всё, перепроектировать legacy никто не будет, так как платят не за это.

Кстати недавно проходил мимо меня контроллер ПКД выпуска 2009 года на i8086, но он выглядит уже современно и запаян в плату. Но нахрена на этой плате 86-й проц - я хз, там хватили бы Cortex-m0 какого-нибудь.

Просто так везде где промышленность и обширное legacy.

А в чём проблема?

Любопытно, попробовал ещё раз - и все завелось без всяких плясок с бубном. Видимо, я сначала попробовал создать проект с ненастроенным Kit'ом, и ничего не собралось. Потом я кое-как его настроил, но создал для пробы проект консольного приложения. Консольное приложение создалось и скомпилировалось, но при подпытке подключить туда заголовочные файлы для GUI компилятор стал ругаться на то, что они не найдены. Сейчас я решил попробовать создать новый проект оконного приложения, и все без проблем работает, давая мне спокойно изучать технологию. Скорее всего, я просто не пробовал создать проект оконного приложения после того, как настроил Kit, вот и считал, что ниасилил.

Но вообще хорошо бы разобраться, где в QT Creator прописаны настройки, которые на это влияют.

Я не могу предъявить доказательства,

Да доказательств я и не просил.

но я работал у такого клиента intel'а, у которого как раз заканчивался контракт на расширенную поддержку на странное (80186), из-за этого переходили на ARM, то есть делали новый контроллер под старое железо и древние шины родом еще с 60-х. [skip] задача обеспечить N штук в месяц на замену сломавшемуся/сгоревшему.

Понял, спасибо за инфу.

Вот как ты думаешь, как старые mainfram'ы IBM экспулатируют? Там же ремонты тоже нужны, а они на кучу всего завязаны. Да, что-то удается заменить на новые аналоги, но на всё, перепроектировать legacy никто не будет, так как платят не за это.

Возможно. С поддержкой мэйнфреймов дела не имел. Но вот с поддержкой персональных промышленных ПК дела иметь приходилось. Там всё было проще. На случай гарантийного возврата (гарантия была, по-моему, 5 лет) держали на всякий случай запасные комплектующие, заранее купленные. Статистика-то примерная была, какой процент может за это время выйти из строя. А потом — новое железо с новым ПО за ваши деньги. Но, конечно, с большими ЭВМ, я думаю, всё сложнее.

Кстати недавно проходил мимо меня контроллер ПКД выпуска 2009 года на i8086, но он выглядит уже современно и запаян в плату. Но нахрена на этой плате 86-й проц

Я думаю, если это наше производство и нацелено в том числе и на вояк (даже необязательно только на них), то и комплектующие по возможности должны быть нашими. Если производство 8086-совместимых процов давно налажено, и их хватает, то почему бы и нет? Простой и разумный принцип: работает — не трогай.

Просто так везде где промышленность и обширное legacy.

Наверно. Просто я думал, что это больше постсоветская специфика. Хотя логика подсказывает, что легаси везде одинаковое. :-)

Скорее всего, я просто не пробовал создать проект оконного приложения после того, как настроил Kit

Скорее всего.

Но вообще хорошо бы разобраться, где в QT Creator прописаны настройки

Очевидно в файле *.pro. См., например, http://blog.mgsxx.com/?p=2070 или http://doc.crossplatform.ru/qt/4.6.x/qmake-project-files.html.

Не, этот не наш, контроллер немецкий. Ради 5 лет смысла с контрактами нет заморачиваться. Когда надо 20-30-40 лет поддерживать - вот тогда надо. Сейчас такое возможно происходит реже, но раньше если ты продаешь некую систему со стоимрстью несколько сотен миллионов $$$ ты должен наложить на себя обязательства по поддержке на сколько-нибудь длительный срок. Вот продаешь ты на какой завод систему пожаротушения/оповещения, а через 5 лет скажешь всё, идите в пень, я всё сделал? Вряд ли они захотят такое купить. Это ж не комп у секретутки поменять, это сертификации, проверки, ответственность, бабло, человеческие жизни наконец.

Вот посмотри, даже бытовой холодильник служит лет 10. Промышленный - лет 30. И стоит там система, которая ими управляет, которая куплена вместе с 1000 холодильниками. Вот клиенту пофигу, холодильник там сдох или контроллер. Сломалось - прибежали/отремонтировали/поменяли. Китайцы перестали выпускать? Возвращайте деньги/платите штраф за день просрочки. Поэтому везде заключены договора и всё работает. Так как получать деньги все любят, а платить никто не хочет.

Ради 5 лет смысла с контрактами нет заморачиваться.

Там 5 лет была гарантия на комп и на нашу плату. Но это не значит, что через 5 лет фирма собиралась исчезнуть. Просто могли появиться новые компы, да и наши платы тоже менялись. Но ПО продолжало работать. И, разумеется, всё было сертифицировано как надо, со всеми ФАПСИшными и военными приёмками, сертификатами iso9000 и т. д.

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

Но если система такая дорогая и в ней невозможно заменить комп на более новый, тогда конечно. Наше изделие было выполнено на обычном промышленном ПК, соединённым с основным изделием через нашу плату коаксиалом, поэтому какой там внутри комп — совершенно неважно. Лишь бы помещался в отведённый блок и нормально работал.

Ну дык товарищам тоже пришлось мигрировать на ARM и гонять x86 софтину в эмуляторе. Ну и вообще оно и не было ПК-совместимо, и 8086 это не первый проц у них. Хорошо когда есть такие длинные проекты - можно спокойно кушать и не бояться за будущее.

Кстати недавно проходил мимо меня контроллер ПКД выпуска 2009 года на i8086, но он выглядит уже современно и запаян в плату. Но нахрена на этой плате 86-й проц

Я думаю, если это наше производство и нацелено в том числе и на вояк (даже необязательно только на них), то и комплектующие по возможности должны быть нашими. Если производство 8086-совместимых процов давно налажено, и их хватает, то почему бы и нет? Простой и разумный принцип: работает — не трогай.

Просто так везде где промышленность и обширное legacy.

Наверно. Просто я думал, что это больше постсоветская специфика. Хотя логика подсказывает, что легаси везде одинаковое. :-)

Относительно недавно читал, как военные приходили на один московский завод типа Ангстрема, и требовали произвести для них процы образца 80-х годов, в какой-то особо секретной технике до сих пор стоящие. Были сурово обломаны, ибо и аппаратуру ту сдали на метал в 90-х, и документацию всю выкинули...

Поддержка legacy - не только наше явление, в США оно даже сильно больше из-за более длинной истории использования компьютеров (в общем смысле). Если у нас legacy тянется с 70х-80х то у них - с 50х-60х.

военные приходили на один московский завод типа Ангстрема, и требовали произвести для них процы образца 80-х годов, в какой-то особо секретной технике до сих пор стоящие.

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

Плюс требования к энергопотреблению и охлаждению, которые во встроенной технике тоже могут быть жёстче. Ну и программная совместимость. К примеру, известно, что процы 8086/80186 адресовали до 1 метра. Но модель сегмент:смещение теоретически позволяла адресовать 1 Мб + 64 Кб - 16 б. В этих процессорах при обращении к адресам за пределами 1 Мб, они как бы заворачивались в кольцевой буфер, и реальное обращение происходило к старшим адресам, что использовалось некоторыми программами для каких-то своих трюков. А начиная с 286 проца это закончилось, и при обращении по адресу 1 Мб + сколько-то байт адресовалась именно эта область, а не старшие адреса.

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

Были сурово обломаны, ибо и аппаратуру ту сдали на метал в 90-х, и документацию всю выкинули...

Я точно знаю, что как минимум в начале 10-х годов на Украине такие процессоры ещё производились. Думаю, производились они в то время и где-то у нас. И скорее всего до сих пор где-то производятся. Ведь Зеленоград — не единственное место, где делают отечественную электронику.

в США оно даже сильно больше из-за более длинной истории использования компьютеров (в общем смысле). Если у нас legacy тянется с 70х-80х то у них - с 50х-60х.

Ну, в СССР компы тоже начали производить в 50-е. Просто переход на более новые модели повсеместно, включая военных, произошёл раньше, чем в США, я думаю. Хотя вряд ли и в США кто-то до сих пор использует процы 50-х годов выпуска.

военные приходили на один московский завод типа Ангстрема, и требовали произвести для них процы образца 80-х годов

некрофилы какие-то. впрочем, в отличие от лживых новостей в СМИ на самом деле у них там всё на разработках 80-х и держится.

в отличие от лживых новостей в СМИ на самом деле у них там всё на разработках 80-х и держится.

Далеко не всё. Инфа 100%.

Немного истории

youtube://AT&T archives, vacuum tubes 1940, там это, мобилки в такси :-) или полицейской машине.

Ну если бы там только в процах дело было. У нас в 50-х компов было на всю страну несколько, у них начался бум, так как все технологии были в войну опробованы и оттестированы минимально и новая эпоха стартанула. То есть то, что у нас было еденичным, у них было уже более-менее массовым. Это значит появилась инфраструктура, соответственно новое нужно было делать совместимым со старым, и это они хорошо научились делать. Компы помимо универсальных были еще частью приборов, станков, технологических линий, и их срок экспулатации был достаточно значительный, а сервис - длительным (и очень выгодным). Где нужно было, компы обновлялись, но в банках, заводах, кораблях и пр. был просто сервис. Да, одна и та же платформа могла быть заапгрейжена 3 поколениями процессоров, которые могли быть вообще разных архитектур, но совместимость всегда соблюдали, по крайней мере на десятилетие. Промышленные компы часто не апгрейдили вообще - когда у нас в 90-х активно закупали станки Siemens на них стояли управляющие компьютеры на RTX11 (PDP11/4x и 9x) и многие из них (я думаю) работают до сих пор. Это конечно не те PDP на которых гоняли UNIX'ы, но всё же старьё еще то. Кстати, пример проца-долгожителя.

когда у нас в 90-х активно закупали станки Siemens на них стояли управляющие компьютеры на RTX11 (PDP11/4x и 9x) и многие из них (я думаю) работают до сих пор. Это конечно не те PDP на которых гоняли UNIX'ы, но всё же старьё еще то. Кстати, пример проца-долгожителя.

Ну, учитывая, что новые поколения pdp11 разрабатывались до начала 90-х, не таким уж и старьём в то время это было. :-)

Кстати, раз уж вспомнили о DEC, есть прекрасная статья о ней и об Alpha: https://fcenter.ru/online/hardarticles/processors/12737-Alpha_istoriya_v_fakt.... Как раз иллюстрирует поднятую в верхнем посту тему, как передовая технология, обогнавшая остальных почти на 10 лет, вытесняется худшими технологиями и умирает исключительно из-за жадности манагеров и тяге к проприетарщине. Тут и про железо, и аналогии с софтом легко проводятся, и про вред закрытости.

PDP11 делают до сих пор для обслуживания тех самых. 11/44 как раз родом из 70-х, и мне пришлось под него даже немного писать.

А почему не El Crapitan? Какая же в нем громкая говно клава всетаки. Помимо того что он ломается при использовании type-c переходника и является убогой системой неюзабельной.

Вы мне лучше подскажите, каким браузером и софтом пользоваться на 64-битах с 1.6 гб рам и чтоб это все не зависало намертво из-за своппинга через 10 минут аптайма.

каким браузером и софтом пользоваться на 64-битах с 1.6 гб рам

Только самыми лёгкими. Среда xfce или что-то ещё легче, браузер opera или поискать что-то лёгкое из свободного, обязательно с отключённым javascript и другими расширениями, плагины желательно не ставить. Можно выбрать 32 битную ось (там, правда, некоторые вычисления могут замедлиться, зато попадания в кэш увеличатся). Не запускать программы с утечками памяти. Ну и следить, чтоб одновременно не было открыто много окон/вкладок. В общем, можно жить, но, конечно, не комфортно.

и чтоб это все не зависало намертво из-за своппинга через 10 минут аптайма.

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

Среда xfce

Дядя, вернись назад в свои нулевые. Я не знаю, откуда тут упорно форсят миф о легковесности. Скочяйте kde5 и узрите, что этот монстр давно уже соревнуется с ним по потреблению памяти, а с полным переходом на gtk3 и до мате с гномом дорастет (600-800 мб), вангую. Все, что использует говнотык3 не может быть легковесным по-определению.

браузер opera

12.18 уже совсем никак с вебом, а запускать лор с текстовыми страничками можно и в чем-то получше.

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

Дельный совет, но как этого достичь и не отказаться от современного веба.

Это так не работает. Оверкоммит не зависит от наличия свопа, и вешается как раз быстрее БЕЗ свопа.

Среда xfce

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

Сомневаюсь. Но действительно давно не использовал kde, так что посмотрю при случае.

Все, что использует говнотык3 не может быть легковесным по-определению.

Я думаю, что он по любому легче, чем Qt. Но дело даже не в этом. Если бы та же kde использовала только Qt и больше ничего, она была бы сверхлёгкой.

браузер opera

12.18 уже совсем никак с вебом, а запускать лор с текстовыми страничками можно и в чем-то получше.

С текстовыми — можно и получше. А из графических я пока ничего не глючного легче не нашёл. Опера по любому легче файрфокса с хромом. А из других свободных браузеров, что я видел, всё либо так же тормозит и жрёт память, либо периодически падает, либо (luakit) вроде бы и память особо не жрёт, и не падает, но всё время обращается к диску, из-за чего тормозит ещё сильнее даже при небольшом числе открытых страничек. Если назовёшь свободный не глючный графический браузер, который немного жрёт и нормально отображает хотя бы большинство сайтов, буду благодарен.

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

Дельный совет, но как этого достичь и не отказаться от современного веба.

Вот это хороший вопрос. Боюсь, что никак. Или открывать не более одной странички одновременно, максимум пару.

Это так не работает. Оверкоммит не зависит от наличия свопа, и вешается как раз быстрее БЕЗ свопа.

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

А во-вторых, без свопа он как раз прибивает жирные процессы oom killer'ом.

Вспомнилось ещё одно наблюдение.

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

Помнится, меня как студента этот новый подход напрягал уже тогда. Тогда все ждали как манны небесной Microsoft Longhorn, который в итоге так и не состоялся. Неприлично требовательной к ресурсам Windows Vista ещё не было, но уже были тяжеловесные среды разработки Visual Studio и C++ Builder. И то, у меня не осталось воспоминаний, что они тормозят - просто Visual Studio занимала много места (полтора гига - ужас-ужас), а Builder долго грузился. Тогда ещё мы не начали пожинать плоды нового тлетворного учения. Тогда .NET только-только появился, если в случае Java было очевидное пользовательского преимущество в виде кроссплатформенности, а упрощение работы программиста шло как бонус, то в случае .NET мы имели упрощённую технологию без пользовательских преимуществ. При этом C# действительно очень хорошо продуман и удобен, поэтому хотя в студенческие годы я был противником таких технологий, все мои серьёзные продукты написаны на нём.

12.18 это некрота, которую кроют благим матом при заходе на половину сайтов, а хочется чего-то актуального и поддерживаемого. Ладно, буду дальше сидеть на 32 битах. Тут даже жиролис нормально работает.

12.18 это некрота, которую кроют благим матом при заходе на половину сайтов,

Ну вот у меня есть древний ноут, ось на котором много лет не обновлялась за ненадобностью, а сам ноут благополучно лежал на шкафу. Недавно понадобился в качестве временной замены нормальному. Там Opera 12.16, Firefox 20.0 и Chromium 25.0. Файрфокс с Хромом вообще практически ничего не могут открыть, а Опера и ютюб открывает, и многие другие сайты.

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

А так у меня Opera 50.0, весит меньше, чем файрфокс с хромом, но взлетит ли на древнем железе — не знаю. На самом железе может и взлетит, но ей, наверно, и библиотеки какие-то новые понадобятся, а значит новая ось со всеми вытекающими.

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

Не знаю. В своё время читал разные западные книги, и везде (включая книги 60-х годов, например «Этюды для программистов») рекомендовали писать понятно. Причём не только не противопоставляли понятный код эффективному, но, наоборот, подчёркивали, что обычно как раз понятный код и более эффективен, а если в коде ничего не понять, то скорее всего там и нагородили соответственно какого-то эпического фейла. А разные трюки типа модификации кода во время выполнения и пр., что делает алгоритм трудным для понимания, если и дают какой-то прирост производительности или экономию памяти, то ничтожные.

Была даже книжка по компьютерной графике под DOS. Там автор реализовал рисование отрезка на видео-карте несколькими способами: сначала на си с использованием функции BIOS, рисующей точку, с помощью самого тупого алгоритма, затем тем же способом, но с использованием лучшего алгоритма, затем отказался от вызова функции bios, обращаясь непосредственно к видеопамяти и, наконец, всё это на ассемблере. А затем представил сводную таблицу с результатами бенчмарков всех этих реализаций на его компе. Наибольший прирост производительности дал нормальный алгоритм рисования линии в сравнении с дубовым (т. е. с тем, который сразу придёт в голову любому, кто не захочет думать больше 5 минут). Затем обращение к видеопамяти напрямую дало заметный прирост в сравнении с вызовом api bios для рисования каждой точки, но прирост этот был уже значительно меньшим, чем дал нормальный алгоритм. Наконец, ассемблер в сравнении с си дал совсем копеечный прирост производительности, то ли процентов 10, то ли даже меньше.

но уже были тяжеловесные среды разработки Visual Studio и C++ Builder.

Вы наверно не работали тогда с NetBeans IDE. Потому что в сравнении с ней и C Builder, и MS VS показались бы вам пушинками. :-)

Ладно, буду дальше сидеть на 32 битах. Тут даже жиролис нормально работает.

Я бы всё-таки поставил какой-нибудь современный лёгкий 32 битный дистр с самым лёгким DE (не обязательно xfce, можно и openbox или даже WindowMaker) и лёгким браузером с отключённым по дефолту js.

Наибольший прирост производительности дал нормальный алгоритм рисования линии в сравнении с дубовым (т. е. с тем, который сразу придёт в голову любому, кто не захочет думать больше 5 минут). Затем обращение к видеопамяти напрямую дало заметный прирост в сравнении с вызовом api bios для рисования каждой точки, но прирост этот был уже значительно меньшим, чем дал нормальный алгоритм. Наконец, ассемблер в сравнении с си дал совсем копеечный прирост производительности, то ли процентов 10, то ли даже меньше.

Кстати, тогда встаёт вопрос, а почему KolibriOS такая шустрая? Получается, что сам факт того, что она написана на ассемблере, не является определяющим фактором её необычно высокой производительности, раз там 10%. Может, там как раз дело в каких-то специфических именно алгоритмических решениях, типа того, что каждый поток выполнения имеет неявное окно, которое может быть видимым или невидимым, поэтому графика, вшитая так глубоко в ядро, вообще летает.

А что за тупой алгоритм vs нормальный алгоритм? Вычислить координаты всех точек и каждую нарисовать вызовом функции BIOS - что там ещё может быть? Или имеется в виду предварительно посчитать какие-нибудь приращения?

Вы наверно не работали тогда с NetBeans IDE

Не работал. Visual Studio, SQL Management Studio, MorphX, C++ Builder, Eclipse, IDEA, Code Blocks, и вот намедни ещё QT Creator освоил. Вроде всё.

Кстати, тогда встаёт вопрос, а почему KolibriOS такая шустрая?

Не работал с этой ОС, но вот что написано среди прочего в педивикии:

• Основной дистрибутив имеет размер 1,44 Мб (помещается на одной 3,5″ дискете).
• Для запуска достаточно 8 мегабайт оперативной памяти и процессора Pentium I.

Вообще-то потреблять 8 метров памяти — это не так уж и мало. Были многозадачные системы, потреблявшие и меньше. Ну и на дискетке не одна колибриос помещается. Т. е. тут, думаю, как раз нормальный подход не жрать ресурсы. А сам по себе ассемблер вряд ли сильно на что-то влияет. Скорее стимулирует писать всё самим, не используя готовых библиотек, что, с одной стороны, делает работу намного более трудоёмкой, но зато позволяет не тащить за собой тонны жирного софта и не зависеть от разработчиков этого софта, которые могут сделать его ещё жирнее к следующему релизу.

Ну и отчасти, наверно, упрощает задачу то, что они не привязываются ни к каким стандартам:

она использует собственные стандарты и не основана на POSIX.

Что можно рассматривать и как плюс, и как жирный минус.

Но вот касательно графики настораживает следующее:

GUI на основе VESA.

Это устаревшая технология. Уже много лет существует фреймбуфер, позволяющий обращаться к видеопамяти не через 64-килобайтные банки, как было в веса, а напрямую ко всей памяти сразу, что намного эффективнее. Плюс могут быть разные графические ускорители. Поэтому подозреваю, что графика высокого разрешения там не такая уж и шустрая.

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

Честно, не знаю, как там. Скорее всего оконная система максимально проста и примитивна, что-то вроде графической консоли Linux с минимумом дополнительных фич.

А что за тупой алгоритм vs нормальный алгоритм?

Ну, тупой — это расчёт координат каждой точки с использованием плавающей точки и последующим округлением до ближайшего целого. А нормальный сразу работает с целыми. Там, в общем-то, тоже ничего сложного нет. См. Алгоритм Брезенхэма.

Вычислить координаты всех точек и каждую нарисовать вызовом функции BIOS - что там ещё может быть? Или имеется в виду предварительно посчитать какие-нибудь приращения?

Вот как раз алгоритм, использующий прямой доступ к видеопамяти, сразу считает приращение в байтах (или в битах на EGA-картах), вместо того, чтоб сначала рассчитывать (x,y) для каждой точки, а затем переводить их в адрес. Этим достигается дополнительный выигрыш (сколько — уже не помню, по-моему раза в 1.5, может в 2).

Вы наверно не работали тогда с NetBeans IDE

Не работал.

Это IDE, изначально разработанная на яве и предназначенная в первую очередь для явы, хотя поддерживает и др. языки. Одной из целей её создания было продемонстрировать возможности явы. И она великолепно их демонстрировала: вполне вменяемый пользовательский интерфейс, не хуже, чем у других, но страшные утечки памяти и как следствие — тормоза на любой машине, сколько бы памяти там ни стояло. NetBeans до сих пор существует. Как там в настоящее время обстоят дела, точно не знаю, но по доходившим до меня слухам — по-прежнему не торт.

так поставь на 5гб xp

некрофилы какие-то. впрочем, в отличие от лживых новостей в СМИ на самом деле у них там всё на разработках 80-х и держится.

Хакер объяснил преимущество древних компьютеров на ядерных объектах / Geektimes https://geektimes.com/post/276586/

да это барахло не «очень сложно взломать». просто оно нахрен никому не сдалось :) как раз со взломом на таких системах всё проще: отсутствие аппаратной защиты памяти, линейная адресация и статическое размещение системы, вот это всё.

А я недавно с FreeDOS игрался. Думаю, и в FORTRAN 77 тоже будет несложно въехать. Пора устраиваться работать на какой-нибудь ядерный объект.

Я думаю там тоже не дураки сидят)