Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 51
Всё верно. К слову, в те же годы: компьютер на Intel-386SX, 2 Мб памяти, Word 6.0. Как раз я сделал программу для работы с сетевой картой на самом низком уровне на ассемблере. Сижу, смотрю пакеты в сети. Запускаю Word - и пошло-поехало - лезет в сеть, хотя чего ему там делать. Еще и Интернета у нас не было. Вот для того и нужны были мегабайты программ. Видимо. Чтобы замаскировать модули, которые "что-то делают". Потом был драйвер мыши на 19 мегабайт, как сказал знакомый, он должен еще и речь распознавать. Примерно столько же занимает драйвер поворота экрана в мониторе. Один бит отслеживает (экран в горизонтальном положении или в вертикальном). Но если учесть, что можно делать снимок экрана и отправлять, то нужны уже большие объемы, да еще завуалировать нужно.
Не хорошо это, сделали из искусства бизнес.
В те годы, когда был актуален 386sx, 2мб памяти и интернет - что то сверхбогатое. Тогда даже вирусы не рассчитывали на наличие сети.
Там даже TCP/IP не так просто установить было. До Win 95 OSR2 сеть по умолчанию предполагалась сугубо локальной с NetBEUI или IPX. Скорее всего какой-нибудь каскадный эффект от операционки. Типа, Word запросил список принтеров и венда начала в сетевое окружение стучать. Или что-то типа того. А человек теорию заговора на ровном месте создал. :)
Тогда постеров не было. Но стек TCP IP и UDP - куда устанавливать. Делается ручками - главное , сам пакет принимать и передавать, по заголовкам пакетов мак адреса источника, приемника и т.д. и вперёд. Считанные байты программы. Не помню уже, что было в пакетах, но явно не принтеры. А вообще, все пакеты в сети просматривались. Про Wireshark ещё и не слыхали.
Я не понял смысл сказанного тогда.
Чтобы замаскировать модули, которые "что-то делают".
Вот это намекает, что в Word 6.0 была встроена какая-то шпионская активность. Куда он мог отсылать что-то, если учесть, что во времена Win 3.11 и Word 6.0 подавляющее большинство компьютеров с сетевой картой были замкнуты на локальную сеть компании и никакого доступа в интернет не имели?
Я бы предположил наличие вируса в пиратском word.
Пошёл сканировать диски, включая сетевые? Вполне возможно. Кстати, не обязательно даже заражённый exe, вирус могли подцепить позднее:
Most of the old macro viruses work under and were written for the WinWord 6.0 macro language which is known as WordBasic.
Не утверждаю про шпионскую активность, но пакеты Word точно отсылал по сети, Вот куда, надо его создателей спросить. Возможно, у кого-то уже был интернет в то время, Если уж совсем лезть в теории заговора, то он мог считывать информацию из сети и отправлять ее посредством ПЭМИ, в то время под подозрением были даже дроссели на ферритовых стержнях на материнской плате, а ЭЛТ-мониторы - те точно "фонили".
Сеть была локальная, по коаксиальному кабелю с терминаторами на концах сегментов (одноранговая, кажется, называлась, еще "кольцо" бывало). Сетевая плата - на шине ISA, код инициализации у меня и сейчас где-то есть, и прием-передача пакетов. Настраивал адрес FF:FF:FF:FF, чтобы принимать все пакеты. Когда кто-то работал на компьютерах, то в проскакивающих пакетах просматривались имена пользователей и паролей в открытом виде (нехорошо),
Я имею ввиду, что вы даже не установили, что пакеты именно word.exe отсылал, а не операционная система в ответ на какие-то действия ворда.
Вот для того и нужны были мегабайты программ. Видимо. Чтобы замаскировать модули, которые "что-то делают"
Но если учесть, что можно делать снимок экрана и отправлять,
Не утверждаю про шпионскую активность,
Ну да, :)
Я запускал Word 6.0 на Win 3.11 For Workgroups на i80386 SX 40MHz, и 2мб SIM памяти. Это жалкое жуткое зрелище, он запускался пол часа, ему мало 2мб. Хотя он конечно запустился во славу файлу подкачки, но это было настолько дико долго, и пользоваться им было нельзя. В целом у меня стояло 2 планки по 1мб, справедливости ради если добавить ещё две, то Word бы работал вполне прилично.
Хотя вообще сеть была, и она вполне была функциональна, в Win3.11 все что надо было, и уж не говоря о Windows NT3.51 в нем из коробки уже был стек TCP/IP.
Word 6.0 релиз 1993 года, а например Netscape Navigator в 1994, в тогда же появилась и ICQ на UDP правда.
Все функции, сразу
Где ж вы в наше время такое видели? Все продукты начинаются со стадии "палки и желуди", а функции там появляются спустя годы. "Ранний доступ" для геймдева вообще база.
Потому что разработчикам платят не за компактность программы. Потому что как правило всем пофиг на размер. Ну, есть colibri os, на дискету помещается. Кому она нужна?
Тут просто разные интересы, кому что. Если что-то в космос запускать, то нужна.
На ДВК-3 был компилятор Fortran, на дискету помещался. Кому он нужен... Но совсем недавно на hh была вакансия - программисты Fortran и Cobol, зарплата - $12000 в месяц.
Для космоса важен не размер а надежность. Архитектура, тестирование, линтеры и прочая методология.
программисты Fortran и Cobol, зарплата - $12000 в месяц.
Совсем недавно карликам в цирке хорошо платили ;). Иногда бывают очень специфические требования.
Ну, фортран, допустим. Он что, дает какой то особо компактный код по сравнению с плюсами?
Не буду спорить.
Размер программы несколько связан с надежностью, Она должна быть ясная и понятная.
Почему Фортран нравится тому работодателю - это его надо спросить, Подозреваю, что расчеты, сделанные на Фортране кому-то представляются надежными. (Как-то была шумиха, что у Питона результаты различаются в зависимости, скажем, от операционной системы, из-за разного представления чисел с плавающей запятой в системах и архитектурах процессоров. Сотни научных работ были скомпрометированы.). Были сообщения, что Фортран до сих пор применяется, и дискеты тоже, но нанимают группы программистов, чтобы всё-таки перевести на современную базу, возможно, для этого и нанимают.
Ну, фортран, допустим. Он что, дает какой то особо компактный код по сравнению с плюсами?
Он вроде как дает возможность работать с числами, с которыми плюсы не могут и делать это с заданной точностью. Нормальные люди этой разницы не увидят, но, в каких-то областях по-другому никак.
Нет. Просто на фортране написано миллионы строк легаси, оно протестировано 100500 раз и работает. А форматы чисел - они стандартые же. Или есть особенные уличные, в которые только фортран может?
про библиотеки и наследие - это банально. Встречал как-то статьи с примерами, где для конкретных задач С++ вообще нельзя было использовать, то ли накопление ошибки, то ли негарантированная точность и предсказуемость результата при заданных форматах чисел.
С фортраном исторически сложилось, потому что его активно использовали в системах распределённых вычисления - то бишь кластеры суперкомпьютеров гоняют чаще всего именно его. Тот же OpenMP изначально на фортране написан.
Cobol занял нишу транзакционных систем, в частности в банкинге. И многие системы на коболе работают по принципу "работает - не трожь". Поэтому обновлять эти сисемы на что-то посовременнее мало кто хотел, но при этом популярность языка стала уступать и найти инженера на Cobol становится год от года проблемнее, отсюда и растущие ценники зп для этого языка.
Фортран не ради компактности берут, а с длинной историей вычислений, для которых он хорошо подходит, куча софта в научной среде использует. Кобол, кстати, тоже имеет десятичную арифметику, которой из коробки в популярных языках нет.
У Colibri OS всё плохо с безопасностью, так что в космос её запустят разве что в качестве груза на той дискете.
А кто запрещает юзать колибри, msdos, linux без de?
Обрисую крайнюю степень этого явления. Веб приложение, вместо того чтобы использовать в имеющемся у пользователя броузере, поставляют с electron-ом (копией броузера с доп-функциями), потом заворачивают это все в snap/flatpack (копию операционной системы), и все это работает через несколько слоев виртуализации. Не говоря уже про грмоздкие вэб-фрейворки который ре-рендерят и делают diff-инг DOM дерева на каждый чих.
Ну и другая крайность - несколько дней подпиливать системный браузер и подбирать версии окружения, чтобы оно заработало без snap. Или раздать всем абсолютно одинаковые компы с абсолютно одинаковой ОС, а то зоопарк кругом.
Не говоря уже про грмоздкие вэб-фрейворки который ре-рендерят и делают diff-инг DOM дерева на каждый чих.
Никто не хочет платить за компактные фреймворки. А громоздкие - бесплатно достаются.
Ну это как всегда зависит от задачи. Например примерно 90% проблем уже моно решить через АПИ обычного броузера. Остальные 10% решаются с использованием микро-сервера запущенного на localhost (микро относительно electron). Если сервер написан на ноде или питоне, то проблема системных библиотек не актуальна. Бесплатные фреймворки без ререндеров и диффов тоже имеются.
Особенно важно, чтобы каждый - включая менеджеров - некоторое время был пользователем системы.
Золотые слова.
Желающим "компактного и быстрого" ПО я всегда предлагаю расчехлить любой ассемблер, да писать прямо на нём. Можно ли написать Windows приложение с интерфейсом прямо на асме? Вполне. И будет ну очень быстро работать, и компактным тоже будет. Вопрос только в том, сколько времени придётся на всё это положить.
Что б вы понимали — я представитель "старой школы", учил программирование в конце восьмидесятых в Политехе, начав с Фортрана, затем был Паскаль. Это два прекрасных учебных языка. Си я выучил самостоятельно по K&R, написав на нём программу управления рентгеновским дифрактометром для дипломной работы (походу мне пришлось ещё и PDP-11 макро ассемблер изучить, чтобы воспользоваться всеми преимуществами ОС RT11FB). На ДВК-4 памяти было вроде 56 килобайт, ещё был жёсткий диск на 5 мегабайт, РАМ диск мегабайтный и верх крутизны - адаптер КЦГД. И всё работало и достаточно быстро. Мне также удалось "потрогать" в физтехе и Модулу-2 и Оберон. Но в конце девяностых я писал уже на Дельфи 4 и был просто счастлив, это казалось верхом совершенства. То есть я вижу весь этот прогресс за тридцать лет. Сейчас мне приходится писать на LabVIEW (тут у меня 25 лет опыта), это графическая среда разработки, о которой я тридцать лет назад не мог даже и мечтать, равно как и о других, та же Студия — фантастический проект, я помню как я редактировал код на ДВК, как компилировал, как разбивал программу на слои-оверлеи, чтобы сделать подгрузку с диска того, что не лезло в куцую память. Цена же всех современных возможностей — огромное количество машинного кода. Та же LabVIEW выгоняет довольно "рыхлый" машинный код, но это плата за удобство.
Что касается современной разработки — тут нужен разумный, я бы сказал рационально-прагматический подход. Из негативного — я вижу довольно много разработчиков, даже банально не понимающих как работает компьютер, процессор, память (как физическая, так и виртуальная), кэш, вот это вот всё. Вот у них как раз и будет монструозные навороты из Электронов и иже с ними. К счастью, мне не надо лезть в Веб, я разрабатываю десктопные приложения для промышленных рентгеновских систем. Детектор подгоняет мне картинки по 32 мегабайта 15 кадров в секунду. То есть каждую секунду мне прилетает объём эквивалентный в прошлом сотне(!) дисков ДВК, который мне нужно обрабатывать в реальном времени, и я это успешно делаю, иногда заглядывая в листинги Ассемблера, интенсивно используя SIMD вплоть до AVX-512. И мой опыт тридцатилетней давности с ДВК мне в этом очень помогает для оптимизации "узких мест" и "бутылочных горлышек". Но у меня как-то не возникает желания бесконечно оптимизировать интерфейсную часть, я стараюсь писать ПО так, чтобы это было удобно для пользователя, и если интерфейс запускает сколько-то там потоков для рендеринга вкупе с сотнями мегабайт памяти, ну так и что с того, у меня их нынче гигабайты? Это даёт мне время для глубокой оптимизации и дотошного профайлинга именно алгоритмической части. Это технический прогресс — мы идём по пути усложнения и со своей стороны боремся как можем с этим усложнением как раз теми самыми фреймворками. У некоторых возникают "перекосы", да, но это скорее вызвано слишком "поверхностным" пониманием сути вещей и архитектуры программно-аппаратной части, неумением пользоваться отладчиком и общим нежеланием учиться, чтобы получить результат "здесь и сейчас", ну и менеджмент до кучи подгоняет, не давая разработчикам времени просто сесть, разобраться и подумать, заставляя по итогу "забивать гвозди микроскопом". А каждый хороший разработчик должен быть хотя бы немножко "хакером" (в хорошем смысле слова) и иметь представление как работают железки и программы (а они нынче фантастические в сравнении с теми, что я помню) и расходовать ресурсы максимально экономно и вместе с тем эффективно.
Сейчас вот Раст изучаю — там для аскетов куча возможностей — берите тот же Ratatui, и ваяйте себе в удовольствие консольные интерфейсы, и всё летает, реально.
В любом подходе можно найти плюсы и минусы, важно поддерживать баланс, как мне кажется. Производительность железа растёт, можно и удобства для разработчиков добавить, и фишек для пользователей, лишь бы с умом это делалось. Но грустно наблюдать, когда одно и то же приложение годами практически не меняется, а требует от устройства всё больше и больше, а таких примеров сейчас хватает.
Всё же ситуация, когда, допустим, веб страницу со статейками и видосиками используют в качестве бенчмарка, для меня выглядит как преступление.
Инженеры делают 1 2 3, а программисты на оборот 3 2 1.
Это хороший пример, но тут надо понимать, что простота тут несколько "иллюзорная" в том смысле, что первый и второй рапторы такие не потому что инженерам захотелось обвешать систему финтифлюшками как новогоднюю ёлку, а потому, что развитие технологий на тот момент просто не позволяло упростить устройство до такой степени, в силу отсутствия материалов, технологий, средств управления этой штукой, и т.д. Обычно в такой технике как раз избегают ненужного переусложнения и анализируют возможные точки отказа. Мы тут видим именно развитие технологии, технического прогресса. Современное ПО в принципе так и надо разрабатывать - там где раньше была куча ползунков и опций, теперь всё можно упростить, потому что часть работы пользователя берёт на себя именно программа, и по итогу пользователь (ну или программист, если хотите) может получить больше от внешне простой системы, чем раньше от сложной. Но это упрощение - тоже результат развития технологий (если оно идёт в правильном направлении), под капотом там - мама не горюй, примерно как современный гибрид отличается от древнего карбюраторного авто полувековой давности. В идеале все три изделия надо бы развинтить на запчасти и ещё не факт, что в новом их количество будет сильно меньше, просто они там миниатюрнее (впрочем я совершенно не специалист конкретно в этой области).
Это переработка в сторону глубокий оптимизации. Никакой миниатюризации как в процессорах.
А программисты в основном оптимизацией не занимается. Только нагромождение новых функций при помощи новых фреймворков.
Но. И те и другие делают именно то чего от них ожидают, за что платят.
Тут согласен, хотя те же оптимизации - тоже результат прогресса в системах симуляции и математического расчёта того, что стало возможно только теперь. Ну а в ПО оптимизацией мало кто занимается ещё и с точки зрения развившейся многоядерности - врубили параллельные циклы и погнали, и там, где можно обойтись парой-тройкой хорошо оптимизированных потоков тупо запускают двадцать штук и профит.
первый и второй рапторы такие не потому что инженерам захотелось обвешать систему финтифлюшками как новогоднюю ёлку
Именно потому. Просто вы не правильно на них смотрите. Raptor v1 - отладочная сборка, v2 debug friendly оптимизированная, v3 - максимально оптимизированная.
У инженеров есть стоимость разработки и стоимость производства. Есть смысл вложиться еще в разработку чтобы удешевить производство. А у программистов стоимость производства (т.е. создание любой следующей копии после первой) нулевая или околонулевая. Вот и нет причин оптимизировать ее.
Если бы в ракетостроении всегда можно было откупиться деньгами (как докупить памяти в комп), то так бы и делали. Но законы физики суровы -- лишняя масса двигателя и он не взлетит. Или не долетит. Нельзя просто докупить еще пару движков в ракету. Поползет всё. Сначала общая масса движков, потом масса и объем топлива для них, и производительность насосов, и толщина стенок бака и их вес, и масса корпуса и поперечное сечение и сопротивление воздуха. Которые могут просто "съесть" эффект от "докупания".
Еще добавлю. У инженеров есть стоимость ошибки и она порой очень высока. У программистов стоимость ошибки - НОЛЬ! Из-за этого программисты совсем потеряли берега.
никаких графических элементов, изображений или иконок.
Забавно. А потом видимо ждём, чтобы пользователь с одного раза все правильно ввёл без подсказок, автозаполнений, без отображения состояния, валидации форм и прочего - если мы отдаём всю сложность пользователю, то логично почему система оказывается минималистичной. Сколько такой подход потом тех.поддержке нервов сжигает и как всё это будет конкурировать с некомпактным ПО, естественно, остаётся за рамками статьи.
Можно написать редактор в 8000 байт, но что тот редактор будет уметь кроме отображения глифов в терминал и сохранения на диск? Наверняка undo/redo даже не вместится. Подсветку синтаксиса или проверку орфографии наверное и упоминать не стоит.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Призыв к компактному программному обеспечению