Мысли об извращениях в сфере десктопа

Я знаю что монолитное решение быстрее. Я имел ввиду, что задачи не реального времени в мелких подгружаемых файлах были бы ЛУЧШЕ.

Наверно. В принципе, они оба пашут быстро, а компа с меньшим чем 2 гб озу у меня нет.

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

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

Направление стрелок — это для мозга «низкоуровневая» информация, она распознаётся очень быстро. А опознание контуров цифр — более высокоуровневая.

Поэтому до сих пор в автомобилях цифровые показатели не вытеснили стрелочные.

почему софт стал тяжелее

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

2. А некоммерческим программистам массово интереснее пилить новые фичи, чем делать что-либо другое. Поэтому производительностью будут заниматься в последнюю очередь.

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

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

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

На асме крупные проекты, даже системные, не писались со времени появления си (а это 70-е годы), а не системные и раньше не писались. Ну, есть исключения типа KolibriOS, PTS-DOS и некоторые другие. Но их немного. Однако хорошо писать можно далеко не только на асме.

Писать хорошо на асме современных процессоров человек просто физически не способен.

Писать хорошо на асме современных процессоров человек просто физически не способен.

Ну Колибри ведь написали. Я сам эту ось не юзал, но вроде ничего, если не считать того, что под неё 1.5 приложения, но это другая история.

На асме крупные проекты, даже системные, не писались со времени появления си (а это 70-е годы), а не системные и раньше не писались. Ну, есть исключения типа KolibriOS, PTS-DOS и некоторые другие. Но их немного.

Под DOS довольно много писали на асме, а это уже 80-е, не 70-е.

Да и само ядро MS-DOS вроде на асме.

На асме крупные проекты, даже системные, не писались со времени появления си (а это 70-е годы)

Под DOS довольно много писали на асме, а это уже 80-е

Возможно, какие-то мелкие утилитки и писали. Но вряд ли что-то крупное.

> Писать хорошо на асме современных процессоров человек просто физически не способен.

Ну Колибри ведь написали.

Тут придётся уточнить сразу по всем пунктам:

1. Писали не для современного проца. Интеловская платформа IA-32 родом из 80-х. А писать саму ОС начали, дай бог памяти, в конце 90-х. (На крайняк, в первом-втором годе 00-х.)

2. Писал финский студент в качестве just for fun-а на своём ноутбуке. Она тогда MenuetOS называлась. В то время многие на fasm писали в качестве хобби, в том числе и обычную прикладуху под Windows.

3. Кто сказал, что написано хорошо? Там нет никакой архитектуры, «как написалось, так и работает». Когда я читал код, рыдал кровавыми слезами. Магические константы в коде, отсутствие внятного разделения на функции и модули.

4. Падала она от каждого чиха.

5. Потом русскоязычные ребята её форкнули и назвали Колибри. Много там отрефакторили. Добавили поддержку всякого железа. Я свежие версии не щупал, но если она сейчас не падает, это исключительно их заслуга. Итого, проекту около 20-ти лет потребовалось на всё это.

Писать хорошо на асме современных процессоров человек просто физически не способен.

Если обмазаться мощным препроцессором, то более-менее. Но никому это сейчас не нужно, разумеется.

На асме крупные проекты, даже системные, не писались со времени появления си (а это 70-е годы)

Старый софт кишит асмовскими вставками. Поэтому, по мере эволюции компов, сначала полностью на Цэ переползли, а потом вообще на высокоуровневые ЯП полезли. Тупо экономия человеко-часов разработки. Написать тот же вин10 в том же стиле, что и вин3.1 фактически неподъемная по трудозатратам работа.

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

• команда из 5 человек гарантированно выполнит задачу за пол года, любого программиста можно заменить любым другим, докинуть постоянно или временно пару человек на усиления — вообще не проблема, но результат будет вдвое тормознее, чем в варианте 2 и жрать памяти как не в себя.
• продукт будет резким как удар Чак Нориса, достаточно будет только 3-х человек, которые может быть справятся даже быстрее. Но каждый из них, сцуко, уникальный гений, заменить невозможно и есть риск получить расклад «3 месяца на запил фич, 3 года на избавление от сегфолтов,дедлоков и утечек памяти».

предпочтёт первый вариант.

Второй вариант будет «резким как понос» только на короткой дистанции. Зарядить гениев на 3-5ти летний марафон не получится. А низкоуровневая писанина чревата именно долгоиграющими забегами.

1. Писали не для современного проца. Интеловская платформа IA-32 родом из 80-х.

Так большинство платформ родом оттуда или даже раньше.

А писать саму ОС начали, дай бог памяти, в конце 90-х. (На крайняк, в первом-втором годе 00-х.) [skip] Потом русскоязычные ребята её форкнули и назвали Колибри. Много там отрефакторили. Добавили поддержку всякого железа. Я свежие версии не щупал, но если она сейчас не падает, это исключительно их заслуга.

Но продолжали делать всё это на ассемблере.

Итого, проекту около 20-ти лет потребовалось на всё это.

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

На асме крупные проекты, даже системные, не писались со времени появления си (а это 70-е годы)

Старый софт кишит асмовскими вставками.

С этим не спорю, особенно если речь об ОС.

Написать тот же вин10 в том же стиле, что и вин3.1

Я когда-то читал, что win когда-то вообще на паскале была написана и только позже переписана на си.

Как бывший руководитель пусть маленького, но проекта, я отлично понимаю людей, которые [skip] жрать памяти как не в себя [skip] предпочтёт

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

Но даже там, где он работает — это в большинстве случаев зло.

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

Я когда-то читал, что win когда-то вообще на паскале была написана и только позже переписана на си.

Это было во времена Win1.0, когда винда была надстройкой над ДОС. Но возможность подключения паскалевских библиотек в винапи была еще в winxp (по-идее и сейчас осталась).

если логику делают на высокоуровневом ЯП, а тяжеловесные вычисления на нативе.

Имхо, в таком случае проще всё делать на си: и тяжеловесное, и легковесное, чем громоздить кучу интерфейсов для взаимодействия модулей, написанных на разных языках. Если, конечно, речь идёт об едином программном комплексе, разрабатываемом и поддерживаемом силами одной организации.

Я сейчас говорю исключительно о десктопах-серверах. С встроенными системами дела не имел вообще.

Я сейчас говорю исключительно о десктопах-серверах.

Система реального времени может устанавливаться и на них. Можно, конечно, прописать в ТУ, что для нормальной работы рекомендуется супер-пупер 12-ядерный проц, новейшая нвидия, 128 гигов памяти и ssd-raid0. Но если предполагается эксплуатация компа внутри мобильного комплекса, где и места немного, и с питанием не всё идеально, и нормальное охлаждение обеспечить проблематично, а требования к отказоустойчивости наоборот повышенные (как обычно и бывает в подобных комплексах), то такие ТУ не пройдут.

Помню, около года назад вытащил из пыли старый комп (4 пень, 2001 года) и запустил Adobe Illustrator 10 — меня поразило, что он запустился мгновенно. С сэсэдэ сейчас так не запускается. И новый документ возник за микросекунду, а не как сейчас. При том что основная часть функционала (90%) была уже тогда. Так что, пожалуй, соглашусь с автором топика.

Пруф мгновенного запуска на пне будет?

эксплуатация компа внутри мобильного комплекса, где и места немного, и с питанием не всё идеально, и нормальное охлаждение обеспечить проблематично,

Такое бывает, но я вынужден напомнить, что обсуждение озаглавлено «Мысли об извращениях в сфере десктопа».

Желательно бы пруфец в виде ютуб-видео.

Я когда-то читал, что win когда-то вообще на паскале была написана и только позже переписана на си.

Верно, только начиная с 3 версии винда сишная.

Падала она от каждого чиха

С падениями не сталкивался ни разу. В 9 версии у меня всё работало, просто часть нужной функциональности отсутстсовала. А вот более новая версия N у меня запускается только в виртуалке, живьём виснет.

Я когда-то читал, что win когда-то вообще на паскале была написана и только позже переписана на си.

Верно, только начиная с 3 версии винда сишная.

Да, конечно. Там от паскаля только модификатор PASCAL в декларациях API остался, который позже заменили на STDCALL.

Падала она от каждого чиха

С падениями не сталкивался ни разу.

Ну, это лучше адресовать devzero.

В 9 версии у меня всё работало,

А что за 9 версия? Потому что в википедии написано, что актуальной является версия 0.7.7.0 (13 декабря 2009 года).

просто часть нужной функциональности отсутстсовала.

А какое там вообще есть ПО и какого (из нужного 90%) нет? И насколько её реально использовать как ось общего назначения, ну хотя бы только для интернета/почты/музыки/м. б. фильмов с небольшим разрешением/создания и просмотра текстовых/доковских/пдфовских документов? В общем, то, что нужно 90% пользователей, если не считать игрушек? И как с эмуляцией других осей (хотя бы DOS, к примеру)?

А вот более новая версия N у меня запускается только в виртуалке, живьём виснет.

На том же железе или на новом?

Тупо лень. Это нужно доставать комп и подключать.

Имхо, в таком случае проще всё делать на си: и тяжеловесное, и легковесное, чем громоздить кучу интерфейсов для взаимодействия модулей, написанных на разных языках.

Категорически неправильное мнение. Нативные части пишуться в небольших количествах. Интерфейсы давно уже все придуманы и отлажены. А вот выделить сишную команду из 20 челов для ваяния проекта в течение 2-3 лет (~$1млн. в год в условиях эксСНГ) - это дорого для большинства. Дешевле 2-3 высокоуровневых кодеров взять на это же время.

Ок, пускай не мгновенно, а «просто так показалось», потому что неожиданно быстро. Но вот отклик программы (самое же первое — создание документа) действительно было моментальным, в отличие от.

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

ага, функционала только не хватает в отличии от. Собсно в этом и отличие :)

«В отличие от» чего?

А какое там вообще есть ПО и какого (из нужного 90%) нет?

Что там есть. Читалка всяких fb. Довольно много игр наподобие змейки или сообщающихся сосудов. Музыкальный проигрыватель (правда, без возможности выбора звуковой карты, воспроизводит только через интегрированную). В 9-ке браузер только текстовый, плюс моя сетевая карта не поддерживается. Функционал для настройки системы под себя есть, но при перезагрузке ничего не сохраняется. Насчёт эмуляции не знаю, есть какие-то поползновения в сторону posix и Win API, но, я так понял, на уровне просто желания, делать это некому.

На том же железе или на новом?

На том же, на котором нормально работала 9.

около года назад вытащил из пыли старый комп (4 пень, 2001 года) и запустил Adobe Illustrator 10

Пень4 и люстра - одного года выпуска. Если запускать СС2017 на свежем железе - тоже не будет тормозов.

Про функционал я написал — 90% нынешнего функционала уже было в 2001-м.

То что происходит в сфере разработки десктопов это просто отвратительно. Почему то никому не приходит в голову сделать автомобиль весом в 100 тонн пожирающий 500 литров бензина на 100 км и называть это прогрессом.

Явное передергивание параметров. В 19м веке авто делали из досок и колес от телеги, а теперь чо удумали - всякие там титановые диски и напичкано электронникой «Ни в одной другой сфере разработчики не могут позволить себе так извращаться» (с)

Если чо, компы с каждым годом электричества потребляют все меньше и меньше. И материалов тоже. Кто таскал системник от 286х, помнит, сколько это чудище весило и жрало электричества.

Про функционал я написал — 90% нынешнего функционала уже было в 2001-м.

Искренне сомневаюсь. Точнее нужно сказать «90% функционала, которым умею пользоваться» - так будет вернее. Та люстра была на основе постскрипта. Современные на основе PDF. Разница весьма существенна (альфаканал и всякое такое).

Там от паскаля только модификатор PASCAL в декларациях API остался, который позже заменили на STDCALL

Насколько я помню, в __pascal и __stdcall разный порядок передачи параметров, прямой и обратный соответственно.

С падениями не сталкивался ни разу. В 9 версии у меня всё работало, просто часть нужной функциональности отсутстсовала.

Если просто включить/выключить - в Win9x все работало. Продолжительная работа в течении дня (напр.в Кореле) обязательно прерывалась BSODом. Это было в норме вещей и никто не заморачивался - почаще сохраняли результат работы.

Продолжительная работа в течении дня (напр.в Кореле) обязательно прерывалась BSODом. Это было в норме вещей и никто не заморачивался

Мягко говоря гонево.
Мне приходилось целыми днями на 95 винде мучать сканер с соответствующим софтом и прочими OCR. И ничего не улетало в BSoD.

Справедливости ради - блок питания IBM PC AT 100 ватт (https://pikabu.ru/tag/IBM 286/hot). Процессор 16-битный, видеокарта EGA/VGA, мощность смешная, никаких вентиляторов на плате.

Мягко говоря гонево.

Отнюдь. Вылетало за милую душу. И это не только мой персональный опыт. BSOD не на ЛОРе придумали.

Возможно, сильно влияло железо на устойчивость работы - сейчас уже сложно судить.

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

Почти все виды прозрачностей появились в 2000-м. И «просто прозрачность» с режимами, и прозрачность по отдельности для множественных обводок и заливок на одном объекте, и прозрачность по маске, которой может являться любой растровый или векторный объект (в том числе с прозрачностью и любыми другими эффектами).

В последствии появились ещё две прозрачности: прозрачность в градиентах и прозрачность отдельных узлов меша. Но и в старой версии этого можно было добиться тремя кликами благодаря вышеперечисленному.

мощность смешная, никаких вентиляторов на плате.

Не забываем про дисплей - этот телевизор тоже тянул не меньше системника. 3-4 компа в комнате и уже не нужен обогреватель зимой :)

Имхо, в таком случае проще всё делать на си: и тяжеловесное, и легковесное, чем громоздить кучу интерфейсов для взаимодействия модулей, написанных на разных языках.

Категорически неправильное мнение. Нативные части пишуться в небольших количествах. Интерфейсы давно уже все придуманы и отлажены.

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

А вот выделить сишную команду из 20 челов для ваяния проекта в течение 2-3 лет (~$1млн. в год в условиях эксСНГ) - это дорого для большинства. Дешевле 2-3 высокоуровневых кодеров взять на это же время.

Опять же, зачастую так и есть. Но не всегда.

• Например, если программа представляет из себя единый блоб, а не много более мелких взаимодействующих между собой программ, то писать и отлаживать её проще и безопаснее на одном языке.
• Кроме того, на фирме может работать не так много народу. Например, есть 5 си-программистов, которые справляются с работой, но не знают и знать не хотят питон. Значит, придётся взять ещё несколько питонистов, что необоснованно, учитывая, что и в прежнем составе команда справлялась, а общее качество из-за этого только снизилось. Но, допустим, питонисты выполнили свою работу и делать им больше нечего. Тут 2 варианта: они сидят, ничего не делая, просто на всякий случай и получают з/п. 2-й вариант: их сокращают, а через 2 года надо что-то поменять в юзер-интерфейсе, но питона никто не знает. Значит, снова надо набирать новых питонистов, которые несколько месяцев будут разбираться в существующем коде, а разобравшись, скажут: новые фичи, которые вам нужны, старая версия питона не поддерживает, а старые фичи не работают на новой версии, поэтому интерфейс надо переписать с нуля на последней версии питона. В такой ситуации действительно проще полагаться на основную команду сишников.
• Наконец, в системе реального времени (т. е. там, где требуется гарантированный отклик в течение заданного промежутка времени) питон или какой-то другой интерпретатор может оказаться слабым звеном. К примеру, ядро программного комплекса, обслуживающего АЭС, написано на си, а пользовательский интерфейс на связке Apache+Python+MySQL+непонятно, что ещё. Ядро выявило проблему и послало сигнал пользовательскому интерфейсу, а интерфейс как раз в этот момент подвис, и системный инженер срочно убивает и перезапускает процессы, а в это время котёл с тяжёлой водой перегревается и происходит большой бабах.

Т. е. разные ситуации могут быть.

А какое там вообще есть ПО и какого (из нужного 90%) нет?

Что там есть.

Спасибо за инфу. Как я понял, система только на «посмотреть», ну и может ещё поиграться в настольные игры.

Насколько я помню, в __pascal и __stdcall разный порядок передачи параметров, прямой и обратный соответственно.

По-моему, там для функций с фиксированным числом аргументов — то же, что и __pascal (передача аргументов слева направо, стек очищает вызываемая функция, что в ряде случаев позволяет сэкономить какие-то копейки), но только регистр букв учитывается, в отличие от соглашения pascal, а для функций с переменным числом аргументов — __cdecl (аргументы передаются справа налево, стек очищает вызывающая функция). Но на 100% утверждать не буду.

Почти все виды прозрачностей появились в 2000-м

Не все виды, а на основе PostScript 3, где они по сути являются масками.