Comments 338
https://habr.com/ru/articles/959332/
Интересно, как делить читателей будете?
Спасибо, что подметили. Делить нечего, читатели сами выбирают, что им читать. Судя по недавней истории с повтором одного из наших переводов другим участником платформы, публика Хабра как минимум отчасти рада видеть "разные варианты" перевода одного и того же материала. Лично я считаю, что это неправильно, и раньше мы убирали дубли, когда этот факт вскрывался. Но администрация не видит в этом нарушений, а публика отстаивает возможность почитать/сравнить и т.п. разные версии одного и того же. Так что, пожалуй, и нам стоит придерживаться этой позиции.
Ну в первом заходе не обсуждали тему «уберём джуниоров сегодня = лишимся сеньоров завтра», в таком аспекте мыслит большинство, см. например стенограмму по круглому столу безопасности операционных систем, но есть и те, кто считает, что ИИ выбьет именно сеньоров-архитекторов. Можно тут обсудить это.
Судя по участникам и их продуктам - это те еще "эксперты" в области информационных технологий
Вообще, это " обсуждение на тему в курилке", а не круглый стол экспертов. Главная проблема: экспертиза ии в области ит не раскрыта абсолютно. Много слов и аналогий, мало смыслов и совсем нет здравых идей. По поводу галюцинаций - если у вас неточная "кривая" линейка, то лучше ей не пользоваться совсем, а все мерить на глаз, но если вы называете себя экспертом, то лучше создать точный измерительный прибор.
Ну, тут перевод приятнее, чем по ссылке, надо сказать.
Я помню как сделал в 11 классе калькулятор, и мне кто‑то сказал, что жрать для калькулятора 30 мб ОЗУ это чудовищный оверхед :) При том, что в эти 30 мб помещалась туча функционала, встроенная IDE, анимация и графика, там даже цифры с анимацией вводились.
встроенная ide. в калькулятор.
Видимо калькулятор был очень умный и позволял писать скриптовые вычисления, формулы какие-нибудь, графики строить по функциям ))
Ну он инженерный, графики функций, программирование‑интегрирование, кастомизация, вот это всё
Немного скринов
Коллеги, выходит — я как-то работал над похожим проектом. Только в соответствии с одним из принципов ТРИЗ («идеальное устройство это то, которого нет, но его функции выполняются») в основу UI была положена идея «расчётов на кончиках пальцев»: любое выражение вы писали в любом поле ввода, и оно вычислялось непосредственно там. С историей, понятное дело, с переменными и справочниками. Идея, увы, оказалась слишком радикальной и юзерам не зашла прямо совсем. Как было в каком-то мультике: «А в книге написано, что львы не лазят по деревьям!». «Я же не виноват, что эти львы не читали твою книгу ТРИЗ».
В Lightwave 3D сделано почти так же и это мегаудобно. Истории там нет, но в любое численное поле можно ввести выражение вместе с единицами и получить точный результат.
Такое было ещё в QuarkXPress.3 вроде, в 90х. Оно там даже умело разные units. Типа 5 cm * 3 + 1/2”
В Autodesk Inventor (и Autocad, кажется, тоже) можно при вводе любого размера ввести его в виде формулы (да, с единицами, табличными величинами и т.д.). Очень удобно
Да, в лайтвейв что-то похожее.
Скрытый текст
Такое много где встречается в более‑менее толстых редакторах.
Тут ещё важна фишка, что в одних случаях выражение считается разово, а в других задает постоянную зависимость одной величины от другой.
В САПРах (тот же Inventor) обычно система выражений самая навороченная, так как там часто поддерживаются единицы измерения, а не только безразмерные величины.
Очень интересно, хотелось бы взглянуть. Есть ли возможность где‑то посмотреть/скачать? Или хотя бы ссылки какие‑нибудь.
В своё я тоже напихал много новаторства, даже снабдил его 3ds maxовым роликом. Но с точки зрения рациональности эта штука скорее надругательство над ТРИЗ, ибо нафарширована просто всем, что мне тогда пришло в голову :P
Некоторые фичи
Заголовок окна является полем ввода
Экранную клавиатуру можно отделить/скрыть
Числа в поле ввода можно скроллить
Раскладка ввода всегда правильная (sin(x) вместо ышт(ч))
Знак умножения можно не писать: 5log(3;2)
Автокомплит, подсветка и подчёркивание ошибок
Светлая тема с подсветкой, историей и автокомплитом Вызов по горячей клавише
Системы счисления через префиксы
Одно время работали константы $ и €, равные текущему курсу доллара и евро в рублях. Поскольку знак умножения писать не нужно, можно было просто писать 4$ или $4, и это переводилось в рубли, а обратное преобразование делалось делением, например 5000/$. На деле эти «константы» являются процедурами VB, которые каждый раз скачивают текущий курс. $ вводился через $hift+4, а € через €trl+4
Настройка скинов, звуков и прочего. Есть нативный стиль Win95 через WinAPI
Анимации можно отключить, если бесят
Одно время там работала система обратной связи. В целом, оно либо очень нравилось, либо наоборот, очень не нравилось, то есть была явная поляризация. Так что новаторство да, это та ещё рулетка :)
Так или иначе, оно постепенно расползлось по разным каталогам софта.
Встроенный Visual Basic? Или что-то своё очень похожее?
Надстройка над VBScript. Добавлен оператор Return + статические события + #define через оператор === + некоторые плюшки. Вообще там всё крутится вокруг скриптового движка.
Вычисляет оно так:
С помощью одного скрипта выражение подготавливается (замена констант, подмена тригонометрических функций для того чтобы работало переключение градусы/радианы, оператор модуля «|» и прочее)
Генерируется код объявления пользовательских констант и функций
Эти константы и функции + обработанное выражение вставляются в определенное место в другом скрипте, и этот скрипт запускается, выдавая ответ через callback
Это работает и при построении функции, и при простых расчётах. Поэтому получается довольно гибко — можно просто добавлять константы/функции через стандартный интерфейс, а можно вообще влезть в мозг и добавить собственный синтаксис.
Ну, на первом курсе нечто подобное у меня и в четыре сотни килобайт влезало, со своим велосипедом интерпретатором формул, с графиками и с собственноручно написанной библиотекой графического UI, с кнопочками, поддержкой мыши и гипертекста:
Т.е. рендеринг гипертекста тоже кастом? Круто! Есть ли возможность где‑то скачать и потыкать?
Т.е. рендеринг гипертекста тоже кастом? Круто!
Турбо-Паскаль + MS DOS же, никаких компонент для рендеринга гипертекста ещё не было тогда.
Есть ли возможность где‑то скачать и потыкать?
Это тридцать лет назад было, увы, уже и те дискеты мыши погрызли. Единственное, пояснительная записка к курсовой нашлась, со скринами.
Турбо-Паскаль + MS DOS же
Эх, где мои 16 лет на Большом каретном?!
Да, лет 30 назад кодил на Турбе... куда ж оно всё делось? А ведь какие были шикарные типы переменных "Record", а как они удобно ложились в формат .dbf... а ведь ещё и .bgi были всякие, и даже "графическое решение квадратичных уравнений" я как-то делал для препода по вышке... канула в Лету эпоха...
увы, уже и те дискеты мыши погрызли
Жаль, имхо такое сохранять надо. Я с DOS не работал, в детстве когда начинал кодить уже застал эпоху Win98 с окнами и GDI (но не GDI+).
В DOS это вообще же жесть наверное, там вручную надо было графический режим включать и писать оконный стек вообще с нуля, и только потом писать на нем софт. То есть Вы практически мини‑Windows 3.1 туда впихнули. Уважуха.
У меня на 2-ом курсе был программируемый калькулятор Электроника МК-61. Там было всего 105 байт памяти и на нём можно было выполнять сложнейшие математические и инженерные вычисления. Зачем сжирать 30 мегабайт?
Там было всего 105 байт памяти
Не скромничайте, там ещё 16+4 = 20 регистров для вещественных чисел было, и несколько килобайт подпрограмм в ПЗУ для различных операций с ними.
Сэр, видите эти обведенные зелёным квадратики на фото кристалла К745ИК13? В МК-61 таких три штуки, к слову.
А досточтимый сэр изволит знать, что это за области? Это память микрокоманд, память синхропрограмм и память программ, то есть ПЗУ, которое firmware (ну, всякие стандартные синусы-косинусы-тангенсы-котангенсы). ОЗУ пользовательской программы — жёлтое. Картриджи пользовательского ПЗУ были только у МК-52.
И не надо мне лохматить бабшушку. С МК-61 мой программизм начинался, так что не Вам мне рассказывать, сколько там памяти было.
то есть ПЗУ, которое firmware (ну, всякие стандартные синусы-косинусы-тангенсы-котангенсы)
Это прекрасно, что вы прочитали про архитектуру МК-61, но не могли бы вы жирным выделить в вашем тексте, что там противоречит моему комментарию
и несколько килобайт подпрограмм в ПЗУ для различных операций с ними
?
А то ей-богу, совсем непонятно, на что вы возражаете, собственно.
на что вы возражаете
«Память микрокоманд» != «ПЗУ».
Иными словами, ПЗУ доступно из юзерленда, и с точки зрения программиста отличается от ОЗУ только тем, что в неё запись не работает; память микрокоманд является интегральной частью микропроцессора и вообще никак не видна программисту.
Иными словами, ПЗУ доступно из юзерленда
Откуда взялось такое требование?
Ещё раз: ПЗУ отличается от ОЗУ только тем, что попытки записи в него не работают. Всё остальное абсолютно одинаково. Не знаю, зафиксировано ли это где-то формально, но в наше время это было очевидно любому — чисто по той причине, что других вариантов тупо не существовало.
Ещё раз: ПЗУ отличается от ОЗУ только тем, что попытки записи в него не работают.
Да, верно. При этом условие "отображать ЗУ в память, доступную для приложений" в этом определении, заметьте, вообще отсутствует. ПЗУ прекрасно остаётся ПЗУ, если его содержимое аппаратно не доступно для прочтения прикладному программисту. Равно как и ОЗУ остаётся ОЗУ, если оно там выполняет какие-то внутренние функции в железе, и также недоступно программисту. В ваше же время ПЗУ на кристалле микроконтроллера все равно считали ПЗУ, верно, даже если его прошили и заблокировали от чтения?
При этом условие "отображать ЗУ в память, доступную для приложений" в этом определении, заметьте, вообще отсутствует.
При этом, заметьте, возможность «отображать ЗУ в память, доступную для приложений» в 1984 году, заметьте, вообще отсутствовала. Принципиально.
Вы б ещё FPGA «ППЗУ» назвали.
При этом, заметьте, возможность «отображать ЗУ в память, доступную для приложений» в 1984 году, заметьте, вообще отсутствовала. Принципиально.
Оу, полегче. Виртуализация адресного пространства изобретена в 1950-е, в массовых коммерческих машинах появилась в 1960-е, и в 1970-е уже приобрела современный вид. Но да, не на МК-61, вынужден признать.
других вариантов тупо не существовало
Слышали ли вы такой термин, как КД-ПЗУ?
CD-ROM — это 1993 год, челодой моловек, Союза уже два года как нет. А МК-61 — ещё 1984 (а Б3-34 — ещё сильно раньше). Давайте Вы всё-таки не будете учить курицу.
Причём тут вообще годы? Существование термина "КД-ПЗУ" противоречит вашему определению ПЗУ.
Алё, гараж, у нас 1984 год. До изобретения «КД» ещё десяток лет.
У нас сейчас вообще-то 2025 год, и мы обсуждаем допустимо ли называть некоторую штуку словом "ПЗУ". Называть сейчас, тут в комментариях, а не в 1984м году.
Ну, тогда оно «ПЗУ» не называлось — уж кто‑кто, а я‑то знаю. А в Вашем 2025 году можете как угодно называть, хоть «нейросетью».
Действительно, не называлось. Найдите хоть одно слово ПЗУ на скане его родного технического описания.
Как оно называлось у изготовителя в документации — только изготовитель и знал. А в популярной литературе (которой пользовались чуть менее чем все те, у кого отец на заводе калькуляторов не работал) никогда оно так не называлось. Тут не то что процессор — калькулятор в целом вообще рассматривался как единый юнит. Что у МК-52 мало того, что энергонезависимая память есть, так ещё и картриджи ПЗУ можно подключить — это вообще космос был.
А Вам теперь, конечно, легко: вся документация в интернете, смотри — не хочу.
Как оно называлось у изготовителя в документации — только изготовитель и знал.
Хосспади, может, хватит уже? Я на этом калькуляторе написал свои первые программы в 1980-е, почему-то и я помню про ПЗУ, и официальная документация помнит, и по любой терминологии оно называется именно ПЗУ. И только у вас оно никак не называется, потому что... ну не знаю, почему. Может потому что вы дальше популярной литературы, сиречь, журнала "Наука и жизнь" с его посадкой звездолёта на Луну (или куда там они садились), просто тогда не заходили? Ну так ограниченность кругозора в каких-то вещах, это не повод спорить, что этого не было.
Тут не то что процессор — калькулятор в целом вообще рассматривался как единый юнит.
К слову, я в этом едином юните тактовый генератор ускорял, кстати, по-моему, по инструкции из "Науки и жизни", если не ошибаюсь, где-то процентов на 30 быстрее считать начинал. А кто более умелый, те и память ему увеличивали, врезая ещё один чип памяти в кольцевую шину. Чип, по-моему, брали с остатков Б3-34, там они в выводных корпусах были, пригодные для пайки, в отличии от МК-61.
Иными словами, ПЗУ доступно из юзерленда, и с точки зрения программиста отличается от ОЗУ только тем, что в неё запись не работает
Я правильно понимаю, что по вашему определению, прошивка вашего смартфона лежит не в ПЗУ? Да и BIOS компьютера, с тех пор, как ОС стали запускать программы в виртуальном адресном пространстве, тоже перестало быть ПЗУ?
Алё, гараж, мы сейчас про МК-61 говорим. Какое нафиг «виртуальное адресное пространство» [в то время и на тех мощностях]?
Ещё раз: «память микропрограмм» у МК-61 — это уровня «если в канале появилась такая‑то тетрада, то произвести такую‑то операцию над такой‑то тетрадой в кольце и запихнуть результат вот туда‑то». Никакой связи между этой памятью (вернее, именно что прошивкой, в железе) и кольцом (собственно оперативной памятью, где хранились программа, регистрв и т.п.) нет. Учите, блин, матчасть.
Я правильно понимаю, что по вашему определению, прошивка вашего смартфона лежит не в ПЗУ?
Это Вы сейчас на голубом глазу утверждаете, что «прошивка смартфона недоступна из юзерленда»? Прямо‑таки интересно — а откуда это ресурсы подгружаются?
Алё, гараж, мы сейчас про МК-61 говорим. Какое нафиг «виртуальное адресное пространство» [в то время и на тех мощностях]?
Удивительный аргумент. Вы теперь пытаетесь ещё и подвести к мысли, что определение ПЗУ зависит ещё и от платформы? Дескать, вот ПЗУ на кристалле на нынешних платформах, это ПЗУ, а вот на МК-61, где нет виртуального адресного пространства, такое точно ПЗУ, это уже не ПЗУ?
Ещё раз: «память микропрограмм» у МК-61 — это уровня «если в канале появилась такая‑то тетрада, то произвести такую‑то операцию над такой‑то тетрадой в кольце и запихнуть результат вот туда‑то»
Именно. Вы указываете идентификатор микропрограммы в ПЗУ, она выполняется, и производит действия над вашими данными. Действия не уровня АЛУ, а вполне себе сложные вычисления - там синус посчитать, или случайное число по формуле выдать. Точно так же, как работают, например, микропрограммы в BIOS - вы вызываете её, например, по прерыванию, она выполняется и производит действия над вашими данными. Да, в реальном режиме вы бы могли это прочитать, на компьютерах х86, но вам, как программисту, сие представляет лишь академический интерес, т.к. интерфейс для вызова этих микропрограмм находится совсем в ином месте, через прерывания. А если бы у вас был какой-то там Корвет, где ПЗУ находится в отдельном адресном пространстве, недоступном программисту без трюков, там у вас всё выглядело бы аж как на МК-61. Вызвали функцию, она отработала, а где там код этой функции, ХЗ.
Это Вы сейчас на голубом глазу утверждаете, что «прошивка смартфона недоступна из юзерленда»? Прямо‑таки интересно — а откуда это ресурсы подгружаются?
Вы очень легко можете меня опровергнуть: сдампите, плз, прошивку, допустим, айфона из приложения на iOS. Да ладно там айфон и приложение iOS, сдампите, например, каким угодно способом прошивку сетевого модуля из рутованного андроидофона :)
Охосспаде. Теперь мне будут рассказывать, что прошивка FPGA (ну, в современных терминах) — или, иными словами, набор связей между транзисторами — это то же самое, что и программа в памяти. У меня нет желания по сотому разу на пальцах объяснять различие между железом и софтом.
Охосспаде. Теперь мне будут рассказывать, что прошивка FPGA (ну, в современных терминах)
Это тоже запишем в анамнез: утверждал, что обычное плоское ПЗУ с микрокодом - это в современных терминах то же самое, что прошивка FPGA.
У меня нет желания по сотому разу на пальцах объяснять различие между железом и софтом.
Прекрасно. Прислушайтесь к своему внутреннему голосу, он ведь вас пытается спасти от погружения всё дальше и дальше в трясину нелепостей :)
TurboPascal 3.0 занимал < 64 Kb в виде com-файла.
IDE (без отладчика) и компилятор.
Самому уже не верится...
Одна из причин этого кошмара — бездумный переход на новые версии. Новая версия ПО может быть самым настоящим регрессом, но нежелание переходить на неё всё равно зачастую назовут неприятием прогресса и луддизмом.
Что говорить, когда прямо здесь отказ Мозиллы от поддержки Win7 оправдывали тем, что им, бедолагам, тестировать приходится слишком много.
Давно уже обновляю что‑либо только если у меня возникает потребность в каком‑то изменении в ПО и я точно знаю, что в обновлении ПО это нужное мне изменение есть + высоковероятно, что ничего другое не сломалось. В остальных случаях лучше не обновлять (если, конечно, дело не касается ИБ).
Вот, например, у софта от клавиатуры уже давненько висит вот этот вот баннер.
Угадайте что произойдёт, если я буду прогрессивным и современным, и обновлю ПО на новую, совершенную версию?
Клавиатура полностью перестаёт работать (не расширенные функции, а вообще вся целиком), ПО висит в автозагрузке, завязывает на себя все нажатия клавиш и тупо зависает. Чтобы восстановить работоспособность, нужно подключить отдельно проводную клавиатуру, загрузиться через безопасный режим, стереть в 0 новое стабильное высокотехнологичное современное совершенное ПО, вручную почистить реестр, почистить настройки в разных папках, потом перезагрузиться, потом долго‑долго искать где скачать никому ненужную нестабильную устаревшую версию ПО, установить его и настроить заново. Только для того, чтобы когда ты нажимаешь клавиши, вводились буквы. Ну, чтобы вернуться к тому, что было.
ПО для звуковой карты и видеокарты это тоже касается, но в меньшей степени.
Что говорить, когда прямо здесь отказ Мозиллы от поддержки Win7 оправдывали тем, что им, бедолагам, тестировать приходится слишком много.
Mozilla будет обновлять Firefox ESR 115 как минимум до марта 2026.
А CSS-свойства она тоже будет обновлять до марта 2026? Несерьёзный разговор, извините. Лендинги и фронты пишутся под номер текущей версии минус «2-3, максимум 5».
Лендинги и фронты пишутся под номер текущей версии минус «2-3, максимум 5».
7% юзеров в интернете сидят на хроме 112 более чем двухлетней давности. Да и, если честно, я вообще такого не встречал, чтобы кто-то из вебмастеров завязывался на свежие свойства CSS. Наоборот, все стараются их поменьше использовать, т.к. сиюминутная экономия на синтаксисе потом вырождается в мучительные фиксы от заказчиков: "А почему наш сайт отображается некорректно у Васи на его девятом айфоне"?
А фронтовые фреймворки вообще всеядные, они и на браузерах десятилетней давности корректно работать будут, по идее
Ну а я видел, как разрабы некоторых некрупных компаний просто проверяют: «Кэнайюз зелёный? Тогда катим в бой!». А уж так морочиться с совместимостью, чтобы адаптировать под двухлетний браузер, это тем более делают не только лишь все. Поэтому, половина Интернета у ESR'щиков работает довольно условно. Как вот у меня сейчас, после РКН и без ВПН.
«Сиюминутная экономия на синтаксисе» — если бы CSS развивался по принципу добавления синтаксического сахара, то оно бы было верно. Но там такие изменения бывают… Добавили, скажем, тригонометрию в CSS, и стало можно выкинуть JS, а он и нужен-то был только для тригонометрии. Получился pure CSS (что всегда хорошо). Из реальной жизни случай.
«А фронтовые фреймворки» — это как раз к вопросу о, цитирую, «глобальном упадке качества ПО». «Двести метров джаваскрипта грузят текста триста байт», как поётся в песне. В большинстве случаев это стрельба из пушки по воробьям.
Вообще, этот разговор о деталях уводит нас в сторону от темы. Суть в том, что не было никакой настоящей необходимости разрабам браузеров выкидывать семёрку. Если бы юзеры взбунтовались, браузеры бы и сегодня выпускались под неё. И не ESR-огрызки, а полноценные версии. Но юзеры, сами знаете, по таким поводам не бунтуют. Вот и имеем глобальный упадок качества ПО.
Суть в том, что не было никакой настоящей необходимости разрабам браузеров выкидывать семёрку.
Какую-то денюжку они все равно сэкономили - снесли тестовую инфраструктуру под семёрку, пайпланы, сборки, девопсов. Не уверен, что сильно заметную в масштабах общего бюджета, но премию какой-то менеджер за это себе выцыганил.
Если бы юзеры взбунтовались, браузеры бы и сегодня выпускались под неё.
Ну а с чего бы они взбунтовались? У них в тот момент, когда браузеры перестали поддерживать семёрку, вообще ничего не поменялось. Подозреваю, и сейчас мало кто что заметил, подавляющее большинство сайтов в последних версиях браузеров, доступных для семёрки, нормально работают до сих пор.
Может, задаться вопросом, как так вообще получилось, что программу, которая не использует новые фичи 11-й, недостаточно протестировать под семёрку? Где обратная совместимость виндов? И кто в этом виноват, если её больше нет? Мозилла, наверно.
У них в тот момент, когда браузеры перестали поддерживать семёрку, вообще ничего не поменялось.
Это из той же серии, что ESR, который спасает до 2026-ого. Когда перестаёт обновляться браузер, это нельзя не заметить.
Оффтопик не про браузер, но в целом про версии
На моем опыте отказ от поддержки старых версий ОС чаще не про то, что физически завести продукт на них вообще невозможно, а про то, что юзер может попробовать, но если оно не заведется, то техподдержка просто скинет список поддерживаемых ОС, а не будет долго и упорно разбираться, что пошло не так и какие костыли можно вставить
В корпоративном ПО это решается заносом увесистой пачки денег, если почему-то осталась очень древняя операционка, под которую ну очень нужно, чтобы конкретная программа работала - тогда поставщик оставляет у себя стенды для тестирования и честно гарантирует, что на той версии работает (в том числе оплатой труда тех, кто иногда вставляет костыли)
А той же Mozilla за проверку того, что браузер работает на ОС, которая официальных обновлений больше не получает, никто не заплатит (надо помнить, что там еще есть всякие линуксы, маки, телефоны и подо все это нужно тесты гонять).
что программу, которая не использует новые фичи 11-й, недостаточно протестировать под семёрку?
Тут, как мне кажется, стоит помнить, что программа только пока не использует новые фичи
Ровно в тот момент, когда хоть что-то из новое будет использовано, внезапно и неожиданно придется переделать тестовый стенд (или потом узнать от пользователей, что оно не работает, если функция не кладет браузер совсем), а плановое прекращение поддержки на то и плановое, что не является внезапным и позволяет заранее подготовить все
Где обратная совместимость виндов? И кто в этом виноват, если её больше нет?
Так она есть, и всегда была, но есть же и развитие. А бесчисленное количество аппаратных и программных конфигураций у пользователей всегда предполагало наличие инфраструктуры для тестирования на разных видах окружений, хотя бы среди официально поддерживаемых. А сокращение поддержки какой-то старой ОС, это сразу минус процедуры тестирования, минус процедуры развёртывания, минус обновления и минус обслуживание какой-то части запросов пользователей.
И кто в этом виноват, если её больше нет? Мозилла, наверно.
Ну, в какой-то мере, да, Мозилла. Потому что, например, раньше они там завязывались на какую-то версию С++ рантайма, которую тянули с собой, а начиная с Вин10 там появилась новая универсальная версия в составе системы, и они решили теперь завязаться на неё. Майкрософт не отбирала у них старый метод компоновки, но она предложила им новый, и, он оказался несколько проще, и мозилловцы его выбрали.
Когда перестаёт обновляться браузер, это нельзя не заметить.
Так а каким образом же вы это заметите? Он у вас не станет хуже работать в течении нескольких лет после того, как перестанет обновляться. Наоборот, перестанет задалбывать назойливыми окошками с предложением обновиться.
Когда перестаёт обновляться браузер, это нельзя не заметить.
Но пользователю это проблем особых не доставляет. Я, например, этот коммент вообще из под ХР пишу.
Это из той же серии, что ESR, который спасает до 2026-ого. Когда перестаёт обновляться браузер, это нельзя не заметить.
Пользователи Firefox должны быть привычны к багам, его даже в актуальных версиях никто не тестирует.
В крайнем случае перейдут на Supremium, но немалая часть веба работает даже в ESR 78 - специально проверил несколько лендингов с айтишными мероприятиями.
Ну так никто не захочет отказаться от своих новых, модных и удобных инструментов, которые могут увеличивать скорость написания кода, но сам код работает медленнее. Мы лучше дата-центры на орбиты выводить будем.
Что говорить, когда прямо здесь отказ Мозиллы от поддержки Win7 оправдывали тем, что им, бедолагам, тестировать приходится слишком много.
Но это действительно так, чем больше поддерживаемых систем, тем больше работы разработчикам. А, поскольку мы получаем результат бесплатно, как-то неправильно требовать от них работать больше.
Как же меня трясёт от десктопного приложения яндекс музыки, которой чаще чем раз в неделю выводит не скрываемое сообщение с требованием обновиться/перезапуститься.
Десктопная Яндекс-музыка? Однако. AIMP + файлы, вот мой выбор. Яндекс-музыка в браузере была одно время хороша. В частности, тем, что там сразу можно было читать тексты. Потом всё у них поиспортилось, и за текстами и прочей социальщиной (объяснениями интернетных анонимусов, что хотел сказать автор песни — для изучающих иностранные языки это, скорее, полезно, чем смешно) я хожу на genius.com. Тоже в браузере.
Хотелось сначала всё расписать комментарием, но потом передумалось. Давно уже всё в полной, простите, заднице, и тенденция сохраняется. Лишь изредка, запуская игру или софт, можно насладиться тем, что оно хотя бы не вылетает каждые пять минут и просто делает что должно. И ещё хуже, что часто совсем небольшой сторонний коллектив исправляет то, что не смогла сделать огромная, с относительно бесконечными ресурсами, корпорация. Имидж - ничто, деньги - всё
Слегка со стороны, но вот, например, сравнить современный Silent Hill f от могучих Konami (пусть и не в качестве разработчиков), с кучей людей участвовавших в её создании: тормозит, жрёт много, иногда вылетает, с разрешением экрана проблемы; и игру Tormented Souls 2 от небольшой чилийской команды - страшнее, сюжет крутой, не тормозит, графика не страдает.
Вроде и у тех, и у других вездессущий и вездесрущий UE5, но именитая контора с ним не справилась, похоже, а команда поменьше, преданная своему делу - вполне.
(Мнение субъективное)
Ну тут классический пример того, когда «эффективный менеджмент» пытается обмануть железный треугольник быстро-качественно-дёшево. И получается что крупная фирма, при больших деньгах, нанимает кучу аутсорсеров, не имея при этом качественных процессов разработки, нормальной команды архитекторов и выстроенной иерархии. Видел пару раз ситуации, когда бизнес овнеры думали что 10 мидлов по цене двух архитекторов дадут лучше выхлоп. Да, в геймдеве есть много рутинных задач, но без хороших процессов разработки на выходе будет абы что.
А в чем, собственно, проблема? Пользователи предпочитают программу, которая течет, но зато имеет эмодзи с эякулирующими баклажанами, программе, которая не течет. Рынок слишком маленький для оптимизированного софта.
Ну и пользователей, которые не обновляются, труднее заставить заплатить разработчику ПО.
Пользователя чаще всего не спрашивают. Яркий пример ЯндексюТакси которое переросло а я Яндекс.GO. Я поматерился и снес, благо (пока еще) есть альтернатива - приложение Убер. Когда изгадят и его буду плакать кровавыми слезами и пользоваться, в плане такси они по факту монополисты.
Так потому что они смотрят на результаты, когда в других случаях спрашивали: пользователи хотят анимированные эмодзи. Зачем спрашивать ещё раз, чтобы узнать то же самое?
Я сильно подозреваю, что вы сами не очень-то дружественны к решениям для меньшинства, когда сами по какой-то опреденной фиче имеете требования, как у большинства.
Пользователей уже давно никто не спрашивает. Стало нормой, когда ранее почти идеальное приложение постоянно ухудшается.
Массовое нежелание понимать как на самом деле работают инструменты + погоня за модными инструментами + привычка решать проблемы производительности апгрейдом железа.
Вышел новый фреймворк! В нем новые фишки! Сайт тормозит - не беда, добавим 64 гигабайта памяти!
А кому не нравится - "из нулевых пишет" (с) )
Мне кажется, что проблема имеет более фундаментальную причину, биологическую. У людей как у вида эволюционный отбор работал так, что долгосрочные результаты находятся в "слепом пятне" разума, а краткосрочные — наивысший приоритет.
Если посмотреть шире, то вся цивилизация приходит в точку глобальных кризисов. Куда ни ткни это будет сожержать в себе системные проблемы и те или иные вариации технического долга. Особенно ярко эти проблемы видны в областях природопользования и экологии. Человечество медленной ломает всё.
Биологическую: как потомки стайных приматов - человеки очень любят верить авторитетам и принимать их идеи как единственно верные.
Про перспективу загаживания городов конским навозом и исчерпание запасов угля писал еще Жюль Верн.
Как вы знаете - этого не произошло.
Про перспективу исчезновения кислорода и загаживания атмосферы дымами заводов писали многие в середине 20 века.
Как вы знаете - этого не произошло.
Про перспективу исчезновения озонового слоя Земли и гибели всего живого от УФ-излучения кричали в 80-х.
Как вы знаете - этого не произошло. (зато нехило перекроили рынок хладагентов и аэрантов)
Про перспективу глобального потепления начали активно кричать где-то в 12-13 годах, может чуть раньше.
Потом скорректировали - не потепления, а изменения (то есть хоть так, хоть этак - всё сойдет).
И уже нехило перекроили мировые рынки на предмет квот, углеродных следов, пошлин и прочих интересных краткосрочных вещей.
Как вы догадываетесь, наверное...
И да, напомню анекдот про крокодилов:
-- гражданин, почему вы руками размахиваете?!
-- крокодилов отгоняю, товарищ начальник!
-- тут же нет крокодилов?!
-- вот потому и нет!
(а пошлины за углеродные следы и плата за выбросы - есть)
Именно. Бизнес живет квартальными отчетами. Инвестор хочет видеть рост здесь и сейчас. Никто не будет вкладывать деньги в "долгосрочную архитектурную устойчивость", если это не принесет прибыли в следующем квартале. Проблема не в биологии, а в системе экономических стимулов
Никто не будет вкладывать деньги в "долгосрочную архитектурную устойчивость", если это не принесет прибыли в следующем квартале
В общем случае - охотно будет, если это рассчитать и обосновать. Бизнес очень часто инвестирует в проекты, которые приносят прибыль не в следующем квартале, а через год, два, три. Но это должно быть измеримо, в случае оптимизаций ИТ-инфраструктуры, например, "мы тратим такие-то усилия ежемесячно на поддержку, а внедрение новых фич стоит сейчас столько-то денег и времени, а после внесения оптимизаций мы будем тратить вот на столько меньше, а внедрение новых фич будет стоить на столько меньше денег и времени. А в саму оптимизацию нужно будет инвестировать вот столько-то".
Традиционный бизнес - да. Но в IT есть выраженная тенденция к приоритизации TTM (Time to market) над качеством. И, в принципе, на то есть веские причины. Особенно если говорить о формате стартапов. Потому что пока ты будешь целый год пилить свое хорошо продуманное и оптимизированное приложение, какой-нибудь Вася наймет 10 индусов по цене гамбургера в Макдональдсе и они ему за месяц сварганят на коленке приложение из палок и известной субстанции. Оно будет дофига весить, глючить, медленно работать и т.д., но выйдет на рынок раньше и получит конкурентное преимущество. И есть немало примеров, когда люди используют менее качественные приложения просто потому что уже привыкли к ним. Поэтому сейчас выгоднее максимально быстро выпустить продукт, срубить денег, если он выстрелит, а с проблемами разбираться уже потом.
В коропорации менеджер не получит повышение за то, что предотвратит катастрофу через 10 лет.
Но получит за новую фичу в этом квартале.
Потому приоритеты очевидны
Факт. Например ситуация с антибиотиками, точно так же все в курсе, но никто ничего не делает.
Это игра с нулевой суммой, так же как каждый кодер думает "затащу ка я себе lodash для этого форматирования строки, чё там этот размер бандла, зато сейчас быстрее". Так и каждый пациент думает "ну и что, что антибиотики нельзя постоянно пить, может мне сейчас станет лучше".
У людей как у вида эволюционный отбор работал
Вообще вы правы, но в текущем случае все проще. Если ты растешь медленнее конкурента - ты уже вылетел с рынка, просто еще не знаешь про это. Поэтому... коротко говоря, лучше не будет.
«Почему ты всё ещё работаешь под Windows 7?» — говорили они. «Почему ты не проапгрейдишься до Windows 11?» — говорили они.
(А я отвечал, что меня и 98-е вполне себе устраивали, но под них больше не выпускают современные браузеры.)
Разработчики российского софта выступили против маркировки надёжности ПО в реестре Минцифры (https://habr.com/ru/news/925248)
Выше надёжность софта - больше работы программистам - больше востребованность - больше зарплаты. 😁 Ну и рынок ещё десяток миллионов джунов пристроит к делу.
Но больше и ответственность?
ответственность
Мир устроен так, что специфические требования удовлетворяются только за отдельные деньги. Хотите, чтобы разработка софта была ещё дороже?
Сейчас ответственность можно было бы заменить страхованием от ошибок софта, но, как я понимаю, услуга совершенно не востребована. Не настолько эта безошибочная работа важна, чтобы за неё хотели платить условные 99% потребителей. Небольшое количество багов всех устраивает, это некоторая точка баланса "цена - качество".
Почему вы делаете скриншоты текста вместо его копирования?
30 лет назад были те же проблемы в софте. Просто софта было меньше.
30 лет назад доставка новой версии софта была затруднительной. Начиная от скорости сети, кончая физическими носителями для некоторых клиентов. И только в последнее время сервисы доставки обновлений стали универсальными.
А ошибки, были более смешными, что-то вида SQL-injection, buffer overflow или логин с паролем в публичных комментах.
Вспомнилось, как лет 15 назад открыл у одной коммерческой программы свойства файла, а там можно было посмотреть найденные строки в exe-шнике. Я начал их смотреть и нашёл зашитые в программу логин и пароль. Видимо, для админа. Так неожиданно одна программа сделалась бесплатной.
Это важный момент. Если раньше получая софт, например, комп. игру в нее просто начинали играть, то сейчас издатели игр спокойно выпускают неработающую игру, а потом делаю патч первого дня на 100+ гб.
Первый патч первого дня для S.T.A.L.K.E.R. 2, вышедший в ноябре 2024 года, весил около 139 ГБ на Xbox.
Безумная гонка для скорости доставки софта приводит к таким последствиям.
Ну и что такого? Принимал софт в 1995 году, американский. Три кассеты цифровые mini-DV. Две системные, одна кассета патчей - полная. 30% патчей.
Это нормально, это не безумная гонка.
Чет я походу в какой то параллельной вселенной жил. У меня почему то достаточно большой процент игр в доинтернетовские времена, либо не запускались, либо крашились и приходилось либо ждать какие нибудь патчи в дисках с журналами, либо покупать более новые версии игр через некоторое время, либо просто на них забить. И это все эти проблемы были постоянно, начиная со спректрума до появления стим.
Ооо... да. Помню как в blood bowl который мне очень нравился не работала опция сохранения в версии с диска. Приходилось держать компьютер включенным, столько сколько можно (для школьника тех лет это было не так уж и просто).
Патч потом я нашёл на диске Игромании, спустя года аж. Так я blood bowl и не прошёл.
Первый патч первого дня для S.T.A.L.K.E.R. 2, вышедший в ноябре 2024 года, весил около 139 ГБ на Xbox.
Программисты не могли за день накодить 139ГБ, это всё дизайнеры напатчили.
Если раньше получая софт, например, комп. игру в нее просто начинали играть
Или не начинали. Я помню, насколько багованный был первый Сталкер и сколько к нему было патчей.
Да что там Сталкер? Есть классная старая игрушка Pure, которая даже на современном железе загружает заезд минут 5. Что она делает всё это время, я не представляю.
Видимо, то же, что и делала GTA Online.
а потом делаю патч первого дня на 100+ гб.
Ну давайте честно, нет там изменений на 100ГБ, тут виновата уже упаковка ассетов в архивы, там реально может 1 байт поменяться.
А типо оригинальный сталкер не допинывали после релиза до приемлемого состояния патчами?) Или этодругое и говнораньшебылолучше?
Я когда ховерю поверх вкладок Хрома и вижу всплывающие цифры, что страница занимает 410, 580, 661 Мб, то вспоминаю, что игры, в которые я играл, иногда весили меньше. В конце нулевых это был еще хороший объем флешки.
Это числа, а не цифры.
Вижу пиксели, формирующие текст из цифр, складывающихся в числа, означающие количество занятой памяти, то вспоминаю.
Когда человек вместо признания собственной ошибки устраивает кривляния, то это признак задержи "фазового перехода" из условного состояния "подросток" к условному состоянию "взрослый".
Было бы ошибкой, если бы число π цифрой обозвали, а число 410 состоит из, внезапно, цифр "4", "1" и "0".
Это когда замечание об ошибке уместно.
Когда человек вместо признания собственной ошибки
Так ошибки-то не было. В выражении "вижу всплывающие цифры, что страница занимает 410, 580, 661 Мб" всё корректно.
Вот если человек начинает утверждать, что видит числа - тогда да, это серьёзный повод встревожиться.
4- видите? Что подсказывает самоанализ? )))
Подсказывает, что если в "4" вы видите - т.е. визуально воспринимаете - число, то это серьёзный повод встревожиться. В этом случае рекомендую консультацию с квалифицированным специалистом, кто понимает, что такое число.
Тревожьтесь на здоровье, 4- и число, и цифра. Аналитик вы наш.
Давайте запутаю ещё больше: Вы видите 12 и С. Что Вы видите? )))
Вы видите 12 и С. Что Вы видите?
Атом углерода, конечно же!
Привет, ИИ )) Я русскую С напечатал )))
Привет, ИИ ))
Сам такой! А у меня по химии пятёрка была!
Хреновая пятёрка. Символ углерода- латинская C, а не кириллистическая.
4- и число, и цифра
И несколько подсвеченных пикселей на экране, и чернильная клякса на бумаге... И вообще всё есть всё: люди, кони, числа, цифры - какая разница, да? :)
Ничего страшного, не все умеют в абстрактное мышление достаточно, чтобы понимать разницу между кляксой (физический носитель), цифрой (символ, 1-й уровень абстракции), числом (абстрактный объект с определёнными свойствами). Равно как не все различают между сотрясением воздуха / кляксой (физ. носитель), предложением (абстрактным утвердительным выражением некоторого языка) и пропозицей (абстрактным внеязыковым суждением).
Кто-то не доучился в эту сторону, а кто-то одарён в других областях. Крутой художник, актёр, пасечник, ассенизатор - все ценны, все нужны. Не комплексуйте. Ну или доучитесь.
Какая очевидная манипулятивная хрень. Никто лично вам не запрещает видеть в кляксе всё что угодно, только другим не надо это вещать. Роршах пусть останется в вашей бедовой головушке, спрос на него нонче невелик.
Какая очевидная манипулятивная хрень.
Сторонник теорий заговора детектед. :)
Ну разное это, разное - цифра, числительное, число. Не я это придумал. Вот, например, прямо очень простым языком об этом же самом:
https://www.mathsisfun.com/numbers/numbers-numerals-digits.html
Когда мы в быту говорим, что 4 это число, это просто "синтаксический сахар". Он сильно упрощает общение, но при этом "заметает под ковёр" большие пласты структуры нашей действительности.
(К слову, практически вся наша "речь" за пределами строго формальных исчислений насквозь пронизана всевозможными разновидностями подобного "синтаксического сахара". Потому что в жизни куда чаще важна быстрота обмена информацией при достаточно хорошем качестве, а не абсолютно точно соответствующие действительности формулировки.)
С помощью класса символов "цифры" мы ссылаемся на числа, используя принятые в нашем языке и среде ассоциации и методы построения. Цифры это, по сути, имена (всего нескольких) чисел. Вот разные наименования, ссылающиеся на одно и то же число: 4, IV, четыре, 100, four, ארבע, ד. И т.д. и т.п., этот список далеко не исчерпывающий.
Причём, безымянных чисел бесконечно больше, чем именованных. А принципиально неназываемых (цифрами) бесконечно больше, чем потенциально именуемых. То же число
невозможно обозначить цифрами точно. А таких (трансцендентных) чисел неисчислимо много - бесконечно больше, чем целых и рациональных.
Если в гугле не забанили, всё это проверяется на раз-два.
только другим не надо это вещать
"Не говорите мне, что делать/не делать" и дальше по тексту.
Роршах пусть останется в вашей бедовой головушке
Дельная самокритика - у меня даже мысли о Роршахе не было, а у вас из головы да в текст. :)
У меня в головушке каллиграфические и даже печатные записи это частный случай кляксы. По той простой причине, что случайно разлитые чернила могут образовать в том числе и форму 4.
Детектед у персонажа... Так 4- число, или всё-таки цифра? Или клякса? ))
Повторение мать учения. Читайте выше, там всё разжёвано.
Читайте сами выше, не умеющий вести дискуссию "жевала". Стопроцентно линию обсуждения потерял ещё в начале и стал просто формально придираться )))
И рекомендую прочесть Сигнал — Википедия (wikipedia.org) для начала, вдруг поймете сложность этого ФИЗИЧЕСКОГО мира, а не мира абстракций. Не благодарите.
"У меня в головушке каллиграфические и даже печатные записи это частный случай кляксы. "
"Фантазёр... Только этого мало!" (с) это для вас, а так рекомендую к прочтению рассказ «Фантазёры» Николая Носова.
"Причём, безымянных чисел бесконечно больше, чем именованных. А принципиально неназываемых (цифрами) бесконечно больше, чем потенциально именуемых. То же числоневозможно обозначить цифрами точно. А таких (трансцендентных) чисел неисчислимо много - бесконечно больше, чем целых и рациональных. "
И где в реальном производстве Вам понадобится с разрядностью после запятой выше общеизвестных 3,1415? Где Вам лично потребуется число выше кветта- , и ниже, чем квекто-? Полезете в Вики, встретите фразу "Например, на уровне моря на Земле вес электрона составляет 8,94 квектоньютон", не ведитесь, масса не измеряется в ньютонах. В ньютонах измеряется сила. Да и уровень моря такое себе начало отсчёта...
Короче сначала учиться, потом практиковаться, а уж потом писать на публику.
Полезете в Вики, встретите фразу "Например, на уровне моря на Земле вес электрона составляет 8,94 квектоньютон", не ведитесь, масса не измеряется в ньютонах.
Ваши навыки чтения поражают...
Можете пожалуйста ещё написать оценку потерь в случае если скорость доставки изменений уменьшается на 1% ?
Просто закон Мура работать перестал. А разработчики уже привыкли на него полагаться.
По большому счету, львиная доля создаваемого ПО - она ни за чем не нужна, она не решает никакой актуальной задачи. Это вообще популярная схема в капиталистической экономике, сначала создать запрос (например через "моду"), а потом продать "решение"... Но в ПО это особенно удобно делать - достаточно рубануть обратную совместимость, запрограммировать старение - и все пользователи будут вынуждены покупать новый смартфон каждые пару лет, а с ним - новый софт, обновлять браузеры, фреймворки, переферию.. Хотя старый софт работал лучше, но для того чтобы преукрасить это, добавляют новые "модные" свистелки-перделки...
В общем-то, это та-же пирамидальная схема, только в технической области. И исход для нее должен быть сходным - на новый виток не хватит ресурса. И дальше мы будет долго и муторно ковыряться в старых исходниках, проводя рефакторинг и оптимизацию..
Это не так. Сравните соседние версии тех же браузеров. Даже хрома.
А тут Сцилла и Харибда (я, если что, программировать-то начинал с советских книжек, тетрадок и железок). Причём что "забавно" -- "разнообразие" входит именно в левацкую повесточку.
И ещё: столь же левацкий инструмент под обобщённым названием "зелёные" оглушительно молчал что по поводу "углеродного следа" тотального SSL, что по поводу вот этого вот экспоненциального роста сложности при хорошо если линейном, а не вовсе отрицательном, росте потребительских характеристик софта (и да, это пирамида/пузырь).
Как пару лет назад упоминал на #OSSDEVCONF -- разбирать обломки и вытаскивать то хорошее, что осталось по большей части от старого опенсорса (где-то до 2010) и корпоративной археологии (включая утечки), нам скорее всего предстоит с китайцами и индусами.
Ну, если не будем все дружно светиться не вполне от счастья, конечно. // пиджак запаса РХБЗ
По большому счету, львиная доля создаваемого ПО - она ни за чем не нужна, она не решает никакой актуальной задачи. Это вообще популярная схема в капиталистической экономике, сначала создать запрос (например через "моду"), а потом продать "решение"...
О как. А кто решает, какое ПО "нужное", а какое ПО "ни за чем не нужно"? Есть какое-нибудь объективное исследование?
Есть авторитетное мнение уважаемых экспертов, или это ваше собственное? И это было просто голословное утверждение "если оно не нужно мне, значит, оно не нужно никому", чтобы был повод толкнуть свою политическую повесточку?
…при этом Microsoft до сих пор успешно апдейтит антикварные Windows XP, Embedded в системах транспорта, аэропортов, поездов и ничего, памяти не надо добавлять, туда где важна надежность. А мы да, питаемся новейшим фастфудом в виде фреймворков , а потом удивляемся почему живот болит и язва…сорри почему все медленно и плохо работает😞
Впечатление что утечки памяти это бич программистов. Про Rust не буду упоминать, не работал с ним, но уверен что и на нем при желании можно написать код так что память будет отжираться и не использоваться.
как же я задолбался в свое время с относительно простым приложением на Objective C для айфона! Вроде все проверил, потестил, прошел проверку в Apple и потом все равно нашел утечки... Но утечки памяти в Java, казалось бы? Одно приложение работало (web, ear/war) уже у многих клиентов лет 5 и только случайно один тестер заметил что оно жрет память после рестарта. Вылечили конечно, и причин было несколько, но это напомнило мне аналогичную проблему на первой работе, но с апплетом Java - тот съедал память после рестарта, но причина была другая - баг был в сборщике мусора, он не успевал разбирать конструкции, пришлось помогать используя destroy(), который позже стал депрекейтнутым методом.
Rust всё же не про защиту против утечек
Но утечки памяти в Java, казалось бы?
Запросто. Кривая работа с контейнерами, на которые ссылаются долгоживущие или статические переменные, или выделение памяти излишнего объёма - и память может течь даже без багов в gc. Но, конечно, в классических языках без gc утечку сделать гораздо проще.
И да, в Rust тоже можно наворотить, но сделать это менее просто.
это понятно, в основном причина в статике.
Однажды прикольный баг с кешем поймали, eh который.
В одном из тикетов кто то тихо добавил помойку типа Map в один класс который сериализовывался в кеше в другом приложении. И не пометил это поле как несериализуемое.
В проде кеш встал. Оказалось в мапу попадал subject, а из него ссылка на почти полное дерево классов веб контейнера, полтора гигабайт примерно.
Веб приложение сохраняло в кеше веб контейнер...
Не memory leak но близкая тема.
Простецкое приложение калькулятора страдает большей утечкой памяти, чем компьютеры десятилетие назад.
В оригинале:
> A basic calculator app is hemorrhaging more memory than most computers had a decade ago.
что переводится как:
В обычном приложении калькулятора утекает больше памяти, чем большинство компьютеров имели 10 лет назад.
Попытка делать акцент на количестве ГБ которые утекают выглядит странной. Если приложение течет, то скорее всего утечет в итоге вся память которая доступна. Будь на машине 1ТБ то утечет в конце концов 1ТБ. В прошлом тоже приложения текли и крашились, даже может больше чем сейчас т.к. ручное управление памятью было более распространенным. Так можно найти любое старое приложение с утечкой, запустить на современной машине с 1ТБ и подождать нужное количество времени.
Например, в IE6 были утечки которых сейчас нет https://www.quirksmode.org/blog/archives/2006/04/ie_7_and_javasc.html. О ужас! Раньше код писали хуже, браузер может слить в никуда 1ТБ!
Может разве что текло медленнее тк в среднем на компьютерах было меньше памяти и это заметнее.
Вообщем мой посыл в том, что некоторые анекдотические случаи утечек в современности это плохой показатель того, больше ли сейчас проблем с управлением памяти чем раньше или нет. Было бы интересно провести исследование на эту тему, влияние современных технологий и фреймворков на кол-во утечек в среднем.
А утечки лучше мерить скоростью и воспроизводимостью чем размером.
Идеальным было бы указывать обе метрики -утечка со скоростью X привела к потере Y гб памяти за Z часов работы - картина была бы полная, но для формата статьи-мнения выбранный автором подход вполне оправдан
В прошлом тоже приложения текли и крашились, даже может больше чем сейчас т.к. ручное управление памятью было более распространенным
За всех не скажу, а у нас было принято фиксировать, сколько в системе было свободной памяти ДО запуска приложения и сколько стало после остановки приложения. Если всё ок, то ничего не течёт. И да, ОС не была многозадачной. А сейчас может течь, и не по вине разработчика. Т.е. проблема не в коде программиста, а в каком-то слое абстракции, который неподконтролен разработчику, но тот вынужден эту абстракцию использовать.
Остановка приложения сама по себе возвращает системе почти все использованные ресурсы, даже на старых ОС без многозадачности, обычную утечку памяти так не отловить.
Я, пожалуй, немного неточно выразился.
Мы выводили объём свободной памяти прямо в футер приложения (Turbo Vision), и благодаря этому все операции с памятью были наглядно видны. Если подо что-то выделялась память, она затем обязательно должна была быть освобождена. В конце рабочего цикла, перед закрытием программы, хорошим тоном считалось видеть тот же объём свободной памяти, что и в начале, так было понятно, что утечек нет.
Если открывалось какое-либо окно, затем закрывалось, а объём свободной памяти не восстанавливался, это означало, что программист забыл освободить ресурсы. Несколько таких открытий подряд могли выжрать всю доступную память.
Данный трюк использовался при разработке и отладке. При передаче в "прод" вывод информации о свободной памяти в футер отключался.
Это пока у вас нет адаптивного преэллокейта. А без него много чего будет работать еще хуже, чем сейчас.
Если подо что-то выделялась память, она затем обязательно должна была быть освобождена.
Разработчики TSR-софтин смотрят на Вас с недоумением. Я в своё время вообще любил с MCB похулиганить, так что "объём свободной памяти" иногда - полная абстракция... а уж если в protected mode уходить... и возвращаться - там вообще лютый адище с памятью начинается (это последняя освоенная мной когда-то технология - с 1995 признал себя профнепригодным программистом).
Ну, кто виноват - понятно. Вопрос, как будем решать? ^ _ ^
А как вы связали утечки памяти в хроме с AI? На моей памяти утечки памяти в хроме были задолго до того как AI умудрились написать одну осмысленную строчку кода.
По поводу что AI стёр продакшн, то просто глупая ошибка на уровня написания "реквизитов входа от админки" в html на публичном сайте (Привет Sony)
Если только Вы не попытались натянуть сову на глобус объеденив вместе разные страшилки.
Я писал примерно про это же, только другими словами: https://habr.com/ru/articles/959358/
"Почему то" никто не упоминает одну из важнейших причин падения качества, мы пожинаем плоды политики инклюзивности, мировой рынок наводнили дешевые программисты из стран третьего мира, в частности из Индии. Но если в старые добрые времена ни одна приличная компания таких товарищей набирать не будет, то в наше время в силу необходимости не качества, а расовой разнообразности набирают нередко именно их все корпоративные гиганты в первую очередь. Отсюда и грязный код и другие косяки.
Нейросети только облегчили работу индийским друзьям и делать можно ещё меньше за те же деньги.
Ну инклюзивочка будто скорее про негров, индусов-то брали ещё до этой чумы и по соображениям экономии (один старый приятель отмечал, что целая идеология J2EE была выстроена уже под этот подход -- "набрать кучу народу, как-то отменеджить и сделать заведомо небыстро, но предсказуемо по срокам и деньгам"). Там скорее оплата за строки кода/комментариев вредила, как понимаю -- в том числе прямо поощряя копипаст.
А "разнообразность" вместо меритократии -- это вообще открытая война здравому смыслу. Со всеми вытекающими.
Россия так то тоже входит/входила в этот список "стран третьего мира с дешёвыми программистами", как и прочее СНГ и около. Причём буквально, потому что после исчезновения "второго мира"(то есть распада Варшавского Договора) по старому определению тех миров остались только первый("США и союзники", куда попасть РФ не смогла) и третий("всякие нейтралы"), а зарплаты тут большими по западным меркам и не были.
И это не инклюзивность, а, скорее, "оффшорность" и "оптимизация прибылей". Пока бизнесу выгоднее нанимать дешевле(и умудряться продавать результат достаточно стабильно достаточно дорого достаточно широко) - будут нанимать дешевле, а из Индии или условного Сомали - вопрос вторичный.
Если джуниорам негде будет получать реальный опыт, откуда должно вырасти следующее поколение старших разработчиков?
уберём джуниоров сегодня = лишимся сеньоров завтра
Я думаю, что дело наоборот в другом. Это экономят на сеньорах. Сейчас веб-разработка настолько простая стала, что почти со всеми задачами справляется команда из джуниоров управляемая мидлом.
А сеньора предпочитают не нанимать т.к. это дорого и со софтскилами у них "не удобно". По этому вырастить своих сеньоров из своих - более привлекательная идея.
Задачу: сделать калькулятор под ios - наверное посчитали настолько простой в Apple, что дали её мидлу или даже джуниору. Оптимизировали ресурсы так сказать. В итоге и получилось то, что получилось.
Отсутствие одной проверки выхода за границу массива в одном файле конфигурации
Это что было? Вы как в конфигурационном файле собраетесь проверять границы массива? Поделитесь опытом …
Проблема в том что, например, функция ожидает получения из конфигурации списка в 21 элемент, а реально там только 20, функция не делает проверку сколько реально было получено элементов и пытается взять 21-й. Вот и получается выход за границу массива из-за отсутствия элемента в конфигурации. Ну в чём проблема сделать проверку количества полученных элементов из конфигурации?
То есть паттерн налицо: поставим кривое, исправим потом. Может быть.
Потому что аджайл, успеть в спринт любой ценой!
"Глас вопиющего в пустыне". Проблемы фундаментальные - если не хватает памяти, то поставьте больше. А далее, закон Мура, Agile, SCRUM, и вообще, капитализм. Больше соревнования систем нет, поэтому кризиса капитализма неизбежны.
Elite игра - 48kb, 8 bit, 3D, развитая система развития, не линейный сюжет ...
Ulead MediaStudio Pro 7.0 - комплект ПО для медиа производства полного цикла занимала 160 МБ, из которых 50 МБ отводилось под примеры файлов...
Windows 2000 - минимальные требования, при этом у многих так и работала, только проц чаще всего помощнее был 133 Mh CPU, 32Mb RAM, 2 Gb HDD...
примеров ещё может быть очень много (добавьте свои)...
... а потом программистов сменили Разработчики !
Windows 2000 - минимальные требования, при этом у многих так и работала, только проц чаще всего помощнее был 133 Mh CPU, 32Mb RAM, 2 Gb HDD...
При этом если смотреть чисто как обыкновенный пользователь, ничем особенным от современной Win11 она не отличалась. Те-же окошки, кнопочки и т.п. Запусти на современном компьютере эту Ось, посади за него современного пользователя, он не сразу и поймет что не так..
Запусти на современном компьютере эту Ось, посади за него современного пользователя, он не сразу и поймет что не так..
Ошибаетесь. Пользователь начнёт жаловаться: а чой-та углы не скруглённые? А чой-та окно раскрывается/закрывается без анимации? А чой-та заголовок не транспарентный?
Вот собственно из-за таких-вот свистелок и перделок возрастают требования к системе. Ах да, ещё же фоновая индексация всего и вся.
ну, WinXP с темами закроет потребность в свистелках полностью, при таком-же уровне потребления ресурсов, что и 2000я. Так что действительно, почему сейчас требуется 32Гб под то, что раньше требовало 32Мб не понятно.
Не отрицая общей идеи, могу сказать, что у Win 10-11 по сравнению с XP есть киллер фича, отсутствие которой делает работу просто физически некомфортной - возможность раскрыть окно на пол/четверть экрана, оттащив его на границу/угол. В какой именно Винде это появилось, уже не помню, но. И да, на первый взгляд мелочь, но оказавшаяся лично для меня принципиальной.
Появилось это в Windows 7. Но и для XP были сторонние программы - AquaSnap, WindowSpace
Не отрицая общей идеи, могу сказать, что у Win 10-11 по сравнению с XP есть киллер фича
А в Вин 11 есть киллер-фича перед десяткой - она умеет раскладки окон запоминать под разные задачи.
11 винда не умеет даже файлы перетягивать через панель задач в другие окна. Это настолько логично и удобно долгие годы работало в предыдущих версиях винды, что я понять не могу, почему это не реализовали в 11 изначало или во всех многочисленных обновлениях.
Умеет, я регулярно так перетаскиваю из тотала. Win11 24H2
У меня таже версия - не работает. Уверены, что работает из коробки, а не с помощью утилит и всяких правок реестра? Через панель задач перетаскиваете, а не просто в открытое окно? Также панели быстрого запуска не хватает, а в остальном мне без разницы какая операционка, лишь бы проги запускала. )
Да, из коробки - никаких утилит не ставил, реестр не правил. Вот только что проделал: взял файл из тотала и держал над кнопкой Teams на панели задач пока окно Teams не всплыло, затем кинул в окно - файл добавился к сообщению.
Вместо панели быстрого запуска можно закреплять приложения на панели задач.
Умеет, давно добавили.
А в Вин 11 есть киллер-фича перед десяткой - она умеет раскладки окон запоминать под разные задачи.
Эммм... можно чуть подробнее - у меня на одном из компов как раз 11-я случайно завелась несколько лет назад, но данную "киллер-фичу" как-то не замечал... да, раскладки я ещё как "Pri/Sec" в Windows переключал - да, в 3.х был глобальный переключатель, в 9х сделали локальным - для каждой программы, в 8, вроде, опять глобальным сделали, а как в 11? Честное слово, интересно - просто на дачу не скоро попаду, а 11-я винда только там.
кмк он про раскладки в смысле расположения окон по экранам. а пооконные раскладки клавиатуры есть примерно в любой винде 21 ввека, только они их периодически туда-сюда шатают, в смысле то включат, то выключат по дефолту.
Это про "Window arrange -> Parket/Cascade/Fullscreen"? Или про что-то более изощрённое (типа запоминание расположений окон при 1-2-4 мониторах)? Если про второе, то на моём рабочем ПК с десяткой это уже есть (когда с удалёнки подключаюсь с единственным моником, все окна на одном экране, когда вхожу в ту же сессию локально - корректно разбросаны по 4 мониторам).
Это про то, что вы можете мышкой расставить окна на экране (экранах) под конкретную задачу и сохранить их расположение. Потом можете расставить под другую задачу, и тоже сохранить их расположение. А потом можете быстро переключаться между сохраненными лейаутами в зависимости от задачи/проекта
Спорная фича - у меня штатно около двух окон (на двух мониторах) используется - я даже терминалы на полную раскрываю - видимо, пережиток 14" ЭЛТ-юности, а сложившиеся привычки поди исправь =)
Спорная фича - у меня штатно около двух окон
Ну как спорная, у абсолютно любой фичи есть люди, которым она нужна, и есть люди, которым она не нужна. Эта, например, реально множеству профессий зайдёт. Банально для программиста - в простейшем случае прилепить на экранах IDE, приложение и терминал, а если дебажишь микросервисы, то разложить на экране консольный вывод нескольких приложений, это очень удобно.
Возьмите экран 50" - довольно быстро расхочется раскрывать терминал. И захочется раскидать окна удобно.
Композитный менеджер плюс 4к монитор, и вот уже не хватает 32 мегабайт.
ОК, придется проапгрейдить до умопомрачительных 128Мб!
:)) У меня первый мой комп ("настоящий", не считая Спектрума) был как раз такой, со 128Мб, WinXP, тогда казался какой-то ракетой просто! И реально все вполне пристойно работало.
Сейчас как раз про эту статью вспомнил - скачал файлик в пдф, и меня задолбало заедание при его прокруртке. Это просто злит неимоверно. Комп если сравнивать с теми машинами, это ведь просто запредельная мощность, но он все так-же заедает при прокрутке текстового файла, как на машине со 128Мб памяти и "железным" жестким диском. Куда делись почти 25 лет прогресса, ХЗ..
Сижу попеременно на 7 и на 11. Последняя заедающая, глючная, очень раздражающая. Исправляют эти баги, появляются другие.
Заедал даже курсор! Хотя как это может быть, если он апаратный...
Ну хоть грузиться стала быстрее с одним из последних обновлений.
Заедал даже курсор! Хотя как это может быть, если он апаратный...
Не совсем так - в любом "графическом" режиме отображение курсора - полностью программная задача (гуглим про рендеринг курсора в ранних версиях VSCode); аппаратным он бывает только в "текстовых" режимах, которые из Windows недоступны уж поколений 5+ (последнее, где у меня по Alt+Enter консольные приложения переходили в текстовый режим, если склероз не врёт, была XP, кабы не 2000).
Аппаратные курсоры графического режима существуют, и существуют довольно давно.
Правда, документации на них нет ничерта, но по крайней мере свидетельства их существования я нашел: https://man.archlinux.org/man/drm-kms.7.en#Cursors
Similar to planes, many hardware also supports cursors. A cursor is a very small buffer with an image that is blended over the CRTC framebuffer. You can set a different cursor for each CRTC with drmModeSetCursor(3) and move it on the screen with drmModeMoveCursor(3). This allows to move the cursor on the screen without rerendering.
Нарастить количество железок - вопрос технический, быстро решаемый. Нарастить генерацию - вопрос тоже решаемый в разумные сроки (5-10-15 лет), особенно, если политики мешать не будут. Нарастить количество разработчиков, способных в сложные оптимизации, чтобы делать более качественное ПО - вопрос не решаемый в разумные сроки. Процентное количество талантливых людей в популяции константно, и чтобы их было больше, надо увеличивать популяцию в целом, которая сожрет на порядки больше ресурсов, чем эти ваши датацентры. Не говоря уже о катастрофическом перенаселении комфортных для проживания мест (тундра пустая, да, но сами там живите), и безумной конкуренции, превращающей жизнь любого в ад бешеной беготни по кругу.
Так что выбрано меньшее из зол, на самом деле. На критической инфраструктуре вполне себе пишут нормальный оптимизированный и качественный код, но это стоит конских денег. В прикладном ПО людей на все не хвататет, как не хватает и бюджетов... Так что если хром жрет 10 гигов - так поставьте 32/64 планку и забудте о проблеме - никто его на ассемблере с супер-оптимизациями не перепишет, никогда.
Процентное количество талантливых людей в популяции константно
Я бы поправил, что не "в популяции", а скорее "в стране, при отсутствии фундаментальных сдвигов в экономике и образовании". То, что русское крестьянство за 1000 лет существования породило буквально одного Ломоносова, а потом за 100 лет взорвалось талантами, указывает нам на то, что современная африканская, латиноамериканская и юговосточноазиатская популяция имеет не меньший потенциал.
До расцвета деятельности Ломоносова были такие таланты как Нартов, Никонов. Глинков и Леонтий Злобин, Ремезов, Клеопин, Иван Моторин и Яков Батищев, Дмитрий Тумашев, задолго до них – Чохов и Федор Конь, Федоров, Кречетников. Тут можно и Ганнибала-арапа вспомнить. он как раз предположительно эфиопом был. Конечно, не все из них "простого" происхождения: Глинков – купец, Клеопин – потомственный дворянин, Ремезов же из детей боярских. Тем не менее, вполне отечественные кадры, постепенно видим продвижение из прежних ремесленников в инженеры. Хотя сколько имен до нас просто не дошло, сколько людей не раскрылось из-за отсутствия подходящей среды, это верно.
Чтобы из крестьянина получилось что-то толковое, этому крестьянину с детства нужно иметь время на думание головой, и, крайне желательно, учителя. Если же ты с 4-5 лет в поле, вырваться смогут лишь те, кому крайне повезло (например, приметил барин/барыня). А вот как появился доступ к нормальному образованию, вот тут-то и пошли косяком люди из народа...
Задача усложняется тем, что
1) не все талантливые люди будут выявлены
2) корпорации продвигают по несвязанным признакам. В результате надо их тоже развивать.
Про кадровый конвейер - это самое важное, это бомба замедленного действия. Заменяя джунов ИИ, мы экономим сегодня, но уничтожаем фундамент, на котором должна была бы строиться экспертиза завтрашнего дня. Сеньоры которые выросли на отладке core dump-ов когда-нибудь уйдут на пенсию, и кто придет им на смену? Промпт-инженеры, которые не знают, что такое указатель? Это реальная экзистенциальная угроза для всей индустрии
Нет никакой угрозы. Будет ровно тоже самое, что было, например, с врачами. Появилось профильное образование, его госрегулирование, ветки обучения разошлись - где-то нужен терапевт, где-то нейрохирург, а где-то просто медсестра - и в целом отрасль работает без сбоев. Медсестре незачем знать о тонкостях операций на сердце...
Не знаю, я вижу джунов с мышлением менегеров по продажам из начала 2000-х.. Желания что-то изучать ноль, зато энергии и стремления к заработку тьма.. Я думаю, что усидчивые люди, кто программированием занимался в школе и универе себе пробьют дорогу.. Ребят хороших достаточно, чтобы не говорили. А всё нытье в рунете от выпускников курсов с юридическим образованием ( в моё время самое блатное)
Это реальная экзистенциальная угроза для всей индустрии
Никакой "экзистенцыальности" - всегда будут богатые компании, которые смогут оплачивать дорогих спецыалистов. Может даже будут монополистами из-за этого.
С браузерами особенно весело: раз в десятилетие кто-нибудь не выдерживает бороться с существующим браузером и пишет с нуля новый.
Вообще, ИИ-кодинг вселяет в меня надежду на то, что переписывание софта с нуля станет новой нормой.
Сложность веб-технологий с учётом обратной совместимости такова, что создать новый браузер с нуля и довести его до уровня современных Chrome, Firefox, Safari сейчас не может никто.
Хороший тест для настоящего ИИ-разработчика. Если сможет - пц всей отрасли.
Только один стандарт HTML — примерно 900000 токенов. А ещё нужно добавить CSS и прочие стандарты.
Только один стандарт HTML — примерно 900000 токенов.
Для модели это можно и почистить, и разбить на подзадачи. Другое дело, что и люди с этой задачей сейчас справляются так себе, ИМХО. Я не могу отказать себе в сравнении современного браузера и MS Word этак 25-летней давности. По функционалу примерно одно и то же, по прожорливости браузер больше раз в сто.
Браузеру нужно быть интерактивным и в плане DOM, и CSSOM, и респонсивности. Это намного сложнее.
Браузеру нужно быть интерактивным и в плане DOM, и CSSOM, и респонсивности. Это намного сложнее.
Это всё умеет и MS Word образца 2000-х. Браузер не сложнее по функционалу (ну, по крайней мере, не сложнее существенно), он просто написан сложнее.
Неа, не умеет по-настоящему. У браузеров сложность неспроста такая.
Ну как не умеет? Вы можете как угодно менять размеры рабочей области мышкой, и Word 2000 будет автоматически перевёрстывать страницу под её размеры, с учётом расположения всех объектов на ней. Там есть каскадные стили, применяющиеся к любому элементу. Вы тоже можете динамически их менять, и Word 2000 вам сразу это отобразит. Вы можете менять это руками и программно, вы можете программно получить доступ к любому объекту в документе, и изменить его, или даже анимировать, и так далее.
Вы можете как угодно менять размеры рабочей области мышкой, и Word
...перекосит к чертям всё оформление. Это известно любому, кто пытался сверстать большой сложный документ в Word.
есть каскадные стили, применяющиеся к любому элементу
Они могут только наследоваться, а это довольно тривиально. В браузере же на любой элемент можно наложить хоть сотни разных сложных правил, которые будут динамически применяться в зависимости от структуры DOM или действий пользователя (например, по hover).
или даже анимировать
Сложные анимации тормозили даже в предназначенном для этого Power Point, а в Word они будут ещё медленнее. Тем более, нужно будет вручную просчитывать координаты и свойства объектов для каждого кадра, а браузер умеет интерполировать свойства по ключевым кадрам.
...перекосит к чертям всё оформление. Это известно любому, кто пытался сверстать большой сложный документ в Word.
Это зависит от того, как вы его сверстали. Сделать вёрстку HTML, которая едет при изменении размеров - тоже как два байта переслать.
Они могут только наследоваться, а это довольно тривиально. В браузере же на любой элемент можно наложить хоть сотни разных сложных правил
Да, два разных стиля одновременно в Word вы к элементу не примените. Но это вот вообще ни разу не радикальное усложнение. Это сделано для удобства вёрстки (там, собственно, такое банально не требуется), но технически последовательно применить несколько стилей к элементу - это не бог весть какая задача.
Сложные анимации тормозили даже в предназначенном для этого Power Point, а в Word они будут ещё медленнее.
Опять же таки, там как минимум, это работает. Если бы это было востребовано для текстового процессора, нашлёпать рендеринг через аппаратное ускорение, как в браузере, тоже не есть существенное усложнение.
Я не буду спорить, что современный браузер в каких-то вещах сложнее, чем текстовый процессор четвертьвековой давности. Я всего лишь утверждаю, что это продукты примерно одного уровня сложности, и разница в объеме кода браузера, и в его потреблении ресурсов вообще и близко не соответствует разнице в его функционале по сравнению с тем текстовым процессором.
Это зависит от того, как вы его сверстали. Сделать вёрстку HTML, которая едет при изменении размеров - тоже как два байта переслать.
Для начала, в Word практически невозможно сверстать сложный документ так, чтобы он пережил смену ориентации страницы с portrait на landscape и обратно без изменений.
Word в целом даже не гарантировал, что документ правильно откроется в следующей версии, что для веб-страниц всегда было абсолютно неприемлемо. Большое значение в веб-стандартах уделено описанию корректного поведения в разных случаях, при этом стандарты DOC и OpenXML фокусируются исключительно на описании исходных данных, а не получаемого результата.
Да, два разных стиля одновременно в Word вы к элементу не примените. Но это вот вообще ни разу не радикальное усложнение.
Даже в браузерах 25-летней давности стили применялись не по тупому списку классов, а по достаточно сложным правилам, описываемым комбинацией нетривиальных селекторов, включая, например, *, :not, :nth-child, + и так далее. Браузеру необходимо сначала вычислить, какие именно стили необходимо применить к документу, а это как раз и есть радикальное усложнение задачи.
Опять же таки, там как минимум, это работает.
Так можно прийти к тому, что Paint и Photoshop — продукты одного класса сложности :)
Я всего лишь утверждаю, что это продукты примерно одного уровня сложности
А я последовательно обосновываю, что это не так, и браузеры даже 25 лет назад были сложнее.
Для начала, в Word практически невозможно сверстать сложный документ так, чтобы он пережил смену ориентации страницы с portrait на landscape и обратно без изменений.
Почему? Это делается ровным счётом так же, как и в HTML, просто казуальные пользователи крайне редко заморачиваются такими задачами, как определение расположения каждого объекта в тексте, или там установку отступов с помощью стилей.
Word в целом даже не гарантировал, что документ правильно откроется в следующей версии
Не гарантировал, но опять же таки, этот вопрос ортогонален сложности задачи. У них не было требования обеспечивать идеальную обратную совместимость любой ценой, это их софтина и их собственный формат документов.
Даже в браузерах 25-летней давности стили применялись не по тупому списку классов, а по достаточно сложным правилам, описываемым комбинацией нетривиальных селекторов, включая, например,
*,:not,:nth-child,+и так далее
Ну так это же просто. Правила-то сложные для запоминания человеком, со всеми их сайд-эффектами (ещё один хороший пример отстойности стандартов CSS, кстати), а для движка наоборот, они детерминированные, и применяются строго последовательно в одном и том же порядке.
Так можно прийти к тому, что Paint и Photoshop — продукты одного класса сложности :)
Ну, не перегибайте :) Если уж ближе аналогию брать, то скорее Photoshop и Krita.
Почему? Это делается ровным счётом так же, как и в HTML
В том и дело, что эти возможности в Word сильно ограничены: например, нельзя задать табуляцию (tab stops), ширину колонок таблицы и, если не ошибаюсь, отступы и размеры объектов в процентах от ширины экрана. Тем более, нельзя задать значения относительно размеров родительского контейнера и шрифта. Поэтому даже простую респонзивность в Word сделать не получится.
У них не было требования обеспечивать идеальную обратную совместимость любой ценой, это их софтина и их собственный формат документов.
Вот поэтому, в том числе, код Word проще, чем код браузеров.
Ну так это же просто. Правила-то сложные для запоминания человеком, со всеми их сайд-эффектами (ещё один хороший пример отстойности стандартов CSS, кстати), а для движка наоборот, они детерминированные, и применяются строго последовательно в одном и том же порядке.
Вот нет, наоборот: как раз селекторы с подобными правилами могут быть когнитивно просты для человека, но сложны в эффективной реализации для движка. Просто так их переприменять при любом изменении DOM будет невероятно затратно, поэтому, скорее всего, в браузерах реализована некоторая система реактивности для подписки селекторов на потенциально необходимые им ветви дерева и элементы.
нельзя задать табуляцию (tab stops), ширину колонок таблицы и, если не ошибаюсь, отступы и размеры объектов в процентах от ширины экрана.
Ширину колонок таблицы в Word задать можно. Отступы и размеры задаются не в процентах от ширины экрана, а в базовых единицах измерения для документа. Это же не экранная вёрстка, а полиграфическая, тут свои правила.
Вот поэтому, в том числе, код Word проще, чем код браузеров.
Возможность переписать какие-то неудачные решения, ломая в каких-то мелких моментах обратную совместимость - это не про простоту кода, а скорее про его качество.
Просто так их переприменять при любом изменении DOM будет невероятно затратно, поэтому, скорее всего, в браузерах реализована некоторая система реактивности
Может быть, но учитывая, насколько в браузере неповоротливо выполняются изменения DOM, скорее всего, нет. Или оно реализовано совсем уж плохо.
Это же не экранная вёрстка, а полиграфическая, тут свои правила.
Так о том и речь же, что правила полиграфической вёртски не вполне подходят для задач браузера.
а в базовых единицах измерения для документа. Это же не экранная вёрстка, а полиграфическая, тут свои правила
Вот в частности поэтому и нельзя сверстать в Word документ, который не разъедется при изменении размеров и ориентации страницы.
учитывая, насколько в браузере неповоротливо выполняются изменения DOM, скорее всего, нет
Так потому они и медленные, что необходимо вычислить все используемые стили, а ещё обновить «живые коллекции» элементов, что требует стандарт. Это не только про сложность вычислений, но и про потребление памяти. Чтобы сэкономить на вычислениях, можно добавить кеш, а это плюс к расходу памяти и дополнительный код для правильной инвалидации кеша.
Вот в частности поэтому и нельзя сверстать в Word документ, который не разъедется при изменении размеров и ориентации страницы.
Блин. Можно, и даже несложно :) Только это будет документ, который сохраняет размеры элементов, меняя только их расположение.
Так потому они и медленные, что необходимо вычислить все используемые стили, а ещё обновить «живые коллекции» элементов, что требует стандарт.
Неа. Они медленные, потому что разработчики браузеров их прикручивали костылями год за годом пару десятилетий, не тратя время на пересмотр архитектуры. Не существует никаких здравых причин, кроме плохого кода, почему современный компьютер не в состоянии быстро отрендерить в реальном времени текст и картинки на плоской канве с наложением каких угодно мыслимых эффектов и анимаций.
Блин. Можно, и даже несложно :) Только это будет документ, который сохраняет размеры элементов, меняя только их расположение.
Нет. Это буквально означает, что документ не респонзивный. В браузере тоже можно прибить размеры руками, и ничего разъезжаться не будет. Только это не то поведение, которое ожидается.
почему современный компьютер не в состоянии быстро отрендерить в реальном времени текст и картинки на плоской канве с наложением каких угодно мыслимых эффектов и анимаций
Так не отрисовка же тормозит. Она вполне себе шустро работает, иначе это сразу было бы заметно по дёрганиям.
разработчики браузеров их прикручивали костылями год за годом пару десятилетий
Если бы это было так, то разработчики Servo добились бы значительных улучшений в производительности, но в DOM, как я уже писал, есть особенности, которые не позволяют применять тривиальные алгоритмы.
Нет. Это буквально означает, что документ не респонзивный.
Почему? Он как раз респонзивый, адаптируется под изменение размера поверхности, так как и должен. Просто в случае браузера он должен адаптироваться одним способом, а в случае полиграфии - другим.
Так не отрисовка же тормозит.
Рендеринг - это же не только отрисовка, это и просчёт того, как надо рисовать.
Если бы это было так, то разработчики Servo добились бы значительных улучшений в производительности
Ну так может быть, они и добились, все равно пока неизвестно, чего они там добились.
так как и должен
А где-то можно увидеть, как специфицировано это «должен»? Я, например, ожидаю, что если меняю ориентацию страницы, то таблица, если она занимала всю ширину полосы (пространство между полями), то должна продолжать это делать. Если же она продолжает иметь заранее заданную ширину, то это как раз называется фиксированной вёрсткой в случае браузеров. В этом случае технически браузер мог бы не делать reflow и repaint, но он вынужден это делать для каждого элемента с респонзивно заданными размерами.
все равно пока неизвестно
Почему же неизвестно? Они не скрывают свои наработки.
Рендеринг - это же не только отрисовка, это и просчёт того, как надо рисовать.
В таком случае очевидно, что приложение, которое вынуждено делать постоянные перерасчёты при изменении размеров элементов и структуры DOM, будет работать медленнее, чем приложение, которому этого делать не нужно.
то таблица, если она занимала всю ширину полосы (пространство между полями), то должна продолжать это делать
На печатной странице - нет. Объект в полиграфии подбирается не под размеры страницы, а под его читабельность. А она не зависит от размера страницы, наоборот, 14-й шрифт должен остаться 14-м шрифтом и на конверте, и на А4, и на альбомном А4. Точно так же и таблица, вы её форматируете таким образом, чтобы она выглядела и читалась хорошо, и при изменении размера полосы, она так же должна сохранить изначальный шрифт и изначальные отступы, а вот её расположение и обтекание текстом уже должны подстраиваться под новый размер.
В таком случае очевидно, что приложение, которое вынуждено делать постоянные перерасчёты при изменении размеров элементов и структуры DOM, будет работать медленнее, чем приложение, которому этого делать не нужно.
Да, но так Word это тоже делает. Возьмите документ какой угодно сложности, перетащите в нём отступы, поля или ещё что, и он у вас на глазах мгновенно перестроится.
Объект в полиграфии подбирается не под размеры страницы, а под его читабельность. А она не зависит от размера страницы, наоборот, 14-й шрифт должен остаться 14-м шрифтом и на конверте, и на А4, и на альбомном А4.
Да, верно, но Word не делает автоматически несколько колонок для текста при переключении ориентации. А вот в браузере возможно настроить такое поведение.
Возьмите документ какой угодно сложности, перетащите в нём отступы, поля или ещё что, и он у вас на глазах мгновенно перестроится.
С точки зрения DOM даже достаточно сложные документы в Word имеют простую структуру и содержат не так много элементов. Тем не менее, даже открытие 100-страничного документа занимает значительное время для расчёта layout. В то же время на типичной веб-странице могут быть тысячи элементов.
Да, верно, но Word не делает автоматически несколько колонок для текста при переключении ориентации.
Но опять же таки, он это не делает не потому, что не умеет, а потому, что по парадигме работы с ним изменение макета предполагается вручную и сознательно. Так-то функционал "автоматически переверстать контент на несколько колонок при изменении макета" там присутствует в полной мере.
Тем не менее, даже открытие 100-страничного документа занимает значительное время для расчёта layout.
Ну как значительное, в конце 90-х на Р-150 с 12 мб ОЗУ я работал со 120-страничным документом, и он с ним работал, в общем-то, мгновенно, несколько притормаживал лишь предпросмотр для печати. И, минуточку, 120 страниц - это несколько тысяч объектов.
и он с ним работал, в общем-то, мгновенно
Во-первых, при первом открытии документа он мог довольно длительное время рассчитывать страницы. Во-вторых, как я уже говорил, кардинальных изменений раскладки не было, поскольку в вордовских документах нет таких зависимостей между объектами, а их размеры фиксированны. В-третьих, Word мог себе позволить пересчитывать страницы в ленивом режиме по мере пролистывания (что тоже было заметно по подтормаживаниям). Отсюда и притормаживание при предпросмотре для печати, когда требуется реально рассчитать все страницы.
Во-первых, при первом открытии документа он мог довольно длительное время рассчитывать страницы
Не очень. Как вы верно заметили ниже, рендерит документ он постепенно. В общем случае и браузер так делает. И, минуточку, речь шла про Pentium-150 и 8 мегабайт памяти.
Во-вторых, как я уже говорил, кардинальных изменений раскладки не было, поскольку в вордовских документах нет таких зависимостей между объектами, а их размеры фиксированны.
Ну так и в браузере то же самое. Страница у вас на экране ведь не меняет ежесекундно свою разметку, если только вдруг там что-то этакое не понаписано. Появилось какое-то внешнее событие - обновилось. Не появилось - отображается статично.
Я, например, ожидаю, что если меняю ориентацию страницы, то таблица, если она занимала всю ширину полосы (пространство между полями), то должна продолжать это делать.
А я не ожидаю. Я ожидаю, что текст, что раньше был под таблицей, стал сбоку от нее. Так что тут с требованиями надо уточняться и уточняться.
Токены - это не про ИИ, это про нынешние поделия.
Настоящий ИИ - это "Напиши, пожалуйста, замену Google Chrome, в качестве платы - энергия для твоего датацентра на год вперёд."
Есть тесты, есть стандарты, есть референсная имплементация, очень даже удобная задача для ИИ, ну вот чуть посложнее шахмат. Просто... Зачем? Писать браузер для нищебродов, которые у вас ничего не купят?
1) отсутствие любви к тому, чем занимаешься
2) жадность и непрофессионализм (ц) АЕН, 2009
3) самая поздняя точка отсчёта -- 1995 год (win95, для не заставших), а то и условный 1970 (~unix)...
ну и призовая старпёрская ссылка для Дениса, если вдруг когда угораздит заметить -- про чуть другой калькулятор, хоть и тоже яблочный
А как ваша компания реагирует на кризис качества?
Мы его порождаем!
А вообще, главная проблема глючного софта - это те, кого устраивает глючный софт. Потому что отсутствие глюков - это точно такая же характеристика софта, как и его функциональность. И, да, снижение количества багов, скорее всего, снизит функциональность.
Дешево, быстро, качественно. Выбирайте два любых пункта.
главная проблема глючного софта — это те, кого устраивает глючный софт.
Проблема в том, что нет ответственности за глючный софт. Каждая первая лицензия начинается с «ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ».
Правда, если ввести ответственность, то софт станет нельзя клепать со скоростью пулемёта, и стоить он станет как чугунный мост. Два.
Firefox, пустая вкладка - 8 процессов, 200 мегабайт суммарно.
Одна открытая вкладка с этой статьей и комментариями - 11 процессов, 600 мегабайт суммарно. Чтобы показать текст и несколько картинок понадобилось 400 мегабайт памяти.
Вопрос: кто отвечает за такой расход памяти - разработчики Firefox, или веб-дизайнеры?
А теперь представьте, как это могло бы быть организовано, например, в виде внутреннего модуля в ОС, который просто подключается к серверу HABR по специальному протоколу, загружает всё в локальную базу данных и отображает сообщения в стандартной форме. Кто-то оставил в теме новое сообщение? — Получили несколько Кб. А если несколько форумов? — Несколько вкладок, но поток данных один (только идентификатор форума меняется). Посылаете сообщение? — Опять же! Несколько Кб в обратную сторону. Никаких GET, POST и PUT.
А за чей счет банкет? готовы подписку оплачивать баксов 10 в месяц с каждого форума?
Вообще, унификация интерфейса всех сайтов под тему операционки это то, за что я и 100 баксов в месяц заплатил бы. Но механизмов реализации пока на горизонте не видно.
Всё уже давно придумано до нас: Remote Procedure Call и CORBA.
Слишком универсально, чтобы получить что-то что можно показать пользователю - надо поверх этого соорудить протокол уровнем выше.
Любая активность на стороне пользователя должна быть в песочнице со строго модерируемыми пользователем правами.
Это может показаться удивительным, но ОС и есть та система, которая сооружает для пользователя такую "песочницу". Было бы здорово иметь все нужные права. Да, кто-ж, даст-то?
Нет большой проблемы в том, что динамический код подгружаемый из произвольного источника будет огорожен дополнительно. Ему и так разрешают слишком много.
Вопрос совершенно в другом: зачем подгружать какой-то код? Пока мне никто не объяснил, зачем это нужно делать. Например, если у меня есть почтовый клиент, то я загружаю письма и всё, более мне ничего не требуется.
Динамический код нужен когда статичнеский не поспевает за потребностями.
Но на практике это только рекламный мусор обычно - да. И тут мы возвращаемся к административной стороне вопроса.
В почте есть html письма, а там и скрипты, вроде.
Плохо, что в почте появился html. Красиво, но не безопасно. Если хотите красивые картинки и ссылки, создавайте новый протокол, который будет надстройкой над почтовым, и вперёд. А я хочу получать на почту письма, открывая которые, я буду уверен, что с моим компьютером ничего не случится. Да и со мною тоже.
То есть вы хотите иметь некий типовой клиент для форумов, чтобы через него подключаться к Хабру, Опеннету, ЛОРу, Реддиту и т.п., типовой клиент для магазинов, чтобы можно было подключиться к любому магазину одежды, продуктов, электроники, автозапчастей, стройматериалов и т.п. и так для всего остального?
Да. Типовой. И, считаю, что в этом и может быть единственно смысл компонентного проектирования программ. Три важных премущества:
Единообразие. Один раз научились — пользуемся везде и всегда. И разработчикам прикладного ПО проще — единый API.
Безопасность. Хорошо проработанный и консервативный к изменениям протокол взаимодействия — залог того, что не будут появляться новые дыры.
Удобство. Пользователь сам решает, в каком виде ему сейчас нужно управлять информацией.
Для этого и нужен системный анализ, чтобы выделить общие элементы разнородных систем, привести их, так сказать, к одному знаменателю, и предоставить программисту общую систему координат.
Он есть вы хотите иметь некий типовой клиент для форумов
Он был. Usenet/почтовый клиент. Потом пользователю предложили браузер и ему не надо стало ничего на своей машине ставить (и злить/дергать админов). Все радостно перешли (Сам usenet потом от спама помер, но клиенты тут не влияли).
А сейчас все снова все тащат в сторону "каждому сервису - по приложению". Так что, если все равно что-то ставить предлагают - почему бы и не типовой клиент?
Хорошо, тогда оцените, какова вероятность, что удалось бы затащить в один клиент хотя бы топовые мессенджеры: Ватсапп, Вайбер, Телеграм, ФБ Мессенджер, Тимс? А сотни магазинов по всему миру? Кому из поставщиков это нужно?
хотя бы топовые мессенджеры
Месседжер и площадка для публичного общения не совсем одно и то же.
Для площадки не нужны мудреные E2E шифрование и так далее и тому подобное.
Как только они научаться не смешивать одно с другим, то, скорее всего, договорятся.
А сотни магазинов по всему миру?
По всему миру - не знаю, но китайцам со своими далеко не сотнями магазинов, говорят, удалось. Клиент, правда, все равно чрезмерно универсальный, но явно менее развесистый, чем полноценный сайт в браузере.
Подход китайцев — это как если бы в России один только Вайлдберрис был, а на Западе — один только Амазон. Тогда суперприложение могло бы накрыть их всех. В условиях конкуренции и разнородных товаров единый эффективный интерфейс вы всё равно не сделаете.
В условиях конкуренции и разнородных товаров единый эффективный интерфейс вы всё равно не сделаете.
Ой да ладно. У всех плюс-минус лапоть фасетный поиск плюс карточка товара в виде фотографии-описание-возможные варианты комплектации. Плюс обратная связь в виде переписки. Плюс механизм оплаты. Вот не верю я, что это нельзя в один клиент поместить.
Тут дело в том, что они не хотят конкуренции. А собирание всех в одном приложении как раз ей и способствует.
Это только кажется. Либо разработчикам придётся учесть всё разнообразие товаров, либо получатся убогие типовые карточки, которые плохо подходят для специфичных товаров. Примерно такое было в Мейловской «Юле», когда они слили интерфейсы для барахолки, автомобилей и недвижимости. Даже сейчас можно убедиться, что в карточке автомобиля только лишь названия, года и цены ну никак недостаточно, особенно если сравнить с агрегаторами-конкурентами. Также и для других специфичных товаров: для автозапчастей добавляют специфичные фильтры по модели / модельному году / комплектации, а то и вычисление конкретной сборки по VIN-коду; для одежды и обуви нужно показать доступные цвета и размеры и так далее.
Да и любое расширение возможностей всегда будет упираться в возможности приложения-клиента. Например, если вдруг в API не будет поддержки отзывов о товаре или наличия товара в оффлайн-магазинах, придётся ждать, пока не обновится протокол, пока его не поддержат в клиенте, и пока пользователи не обновят у себя этот клиент.
Может возникнуть проблема перекупов. Поскольку у всех магазинов один и тот же API, ушлые ребята могут собрать свой «агрегатор» на той же платформе, объединяя выдачи всех магазинов и добавляя свою маржу. А вот искать один товар по разным магазинам пользователь без агрегаторов не сможет, потому что приложение — это только клиент к серверам магазинов.
А собирание всех в одном приложении как раз ей и способствует.
Так-то и сейчас все магазины собраны в одном поисковике или на одной карте города. Нужно только найти нужный. Это и в приложении придётся сделать.
Я о другом. Проблема скорее административная, а не техническая.
У вас два пути:
1. заставить все сайты отдавать содержимое в унифицированном формате без рекламы.
2. сделать систему которая будет транслировать все сайты в унифицированный формат.
При этом надо как-то решить вопрос финансирования "бесплатных" сайтов живущих на рекламе.
А уж чем отобразить - вопрос десятый.
Никаких технических препятствий для того, чтобы что-то сделать, нет. Проблема рекламы не в том, что она есть, а в том, что её навязывают в самой неудобной форме (перекрывающей основное содержание, прерывающее произведение и т.д. и т.п.), а у меня нет возможности (когда это нужно) заплатить за то, чтобы рекламы не было.
И ещё. Вот мы здесь пишем сообщения. что будет, если мы за возможность читать наши сообщения, будет требовать плату? Не знаю. Просто, я о том, что нельзя требовать платы где-то в одном месте, не требуя платы где-то в другом месте. Можно провозгласить принцип: каждая работа должна быть оплачена. За все ли работы предоставляется оплата? Всё ли воспринимается как работа?
А, уж, отобразить что-то — дело десятое. Тут Вы правы. Конечно же.
Интересно сколько он сожрет на чем-то похожем, но написанном под HTML 4 без тонны js/css, трекеров и прочей телеметрии
У хабра в комментах у меня периодически скрипты циклятся с полным фризом страницы. Хабр не лучший пример вебморды, браузер тут не при чем.
Виртуалка с преэллокейтом которой кроме прочего и является браузер - так и будет жрать.
Текст представляет собой острый и актуальный анализ текущего состояния индустрии разработки программного обеспечения, затрагивая темы утечек памяти, качества кода и влияния ИИ. Автор мастерски собирает вместе реальные примеры (как инцидент с CrowdStrike или сбои в Windows 11), что делает материал убедительным и заставляет задуматься о системных проблемах. Особенно ценно напоминание о физических ограничениях и энергопотреблении – это важный аспект, который часто игнорируют в погоне за инновациями.
В целом, это сильный материал. Он провокационный и мотивирует к размышлениям, но мог бы быть чуть более нюансированным для большей объективности. Текст немного пессимистичен по отношению к ИИ, хотя он действительно может быть инструментом для "некомпетентных" разработчиков, но и для ускорения работы опытных специалистов.
Спасибо за такой взгляд на индустрию; надеюсь на продолжение с практическими советами по улучшению качества!
Ну хорошо, белковые программаторы не оптимизируют ПО, потому что трудозатратно и дорого.
Почему его не оптимизируют с помощью ИИ? Оно же для этого и внедряется, для удешевления и улучшения. Сам написал прогу - сам проверил - сам оптимизировал. Или пишет один ИИ, проверяет другой, специализированный.
ИИ вообще может в проверку и оптимизацию?
А сколько за последние десятилетия сочинено всяких библиотек и фпеймворков? Сколько просто ушло в утиль? Вот, работала бы сегодня какая-нибудь программка на FoxPro, Turbo Vision или MFC и работала бы...
фокс про искусственно прикрыли. для ниши карманной бд ее вполне хватало
это прекрасный продукт, когда полноценную учетную систему с графическим интерфейсом, окнами, гридами, кнопками и прочим можно было визуально написать, отладить, запустить на XT/AT286 c 640kb и все это быстро работало с дискетки!. А при наличии сетевого диска на новелле, еще и многопользователский режим.
И это все на чистом С без ООП, ФП и прочих "достижениях".
Какой ДОС? В конце 90ых - начале нулевых еще применялся в налоговой вообще-то потом да почил бозе
Что мешает сейчас использовать? Проблем с безопасностью было бы на порядок меньше.
Тоже что и обычно. Их купил мелкософт и поглотил )
Что мешает сейчас использовать?
То же самое, что мешает использовать любой другой продукт из иной технологической эпохи - полное отсутствие интеграции с современным софтом и железом, к которой мы привыкли. Запустить-то через какие-то костыли под виртуальной машиной ещё можно. Организовать совместную работу уже нельзя, форматы современных файлов, даже текстовые, он не поймёт, с буфером обмена не подружится, с сетью тем более, от объема данных скорее всего удавится.
FoxPro в основном завоевал свою славу именно под ДОС. Под виндой уже была инерция.
потому что мс этот продукт по какой-то причине не стали развивать. уже сложно сказать почему
если память не подводит, то тогда шел переход от технологии файл-сервер на клиент сервер. Микрософт как раз выкатила свой MSSQL. Нишу локальной персональной БД была занята Аксессом, фоксу не было просто будущего. Хотя фокс бы отлично подошел и для писания клиентского ПО для клиент-сервер, но видать на горизонте был уже NET. Да и как назло корпорации, слишком он уж был хорош для клиентов, один раз купил и пользуйся для всего. А корпорации нужны продажи, а что бы давать продажи клиент должен быть постоянно немного голоден и в ожидании.
Я как раз против подобного говнища в разработке. Уволили за такие взгляды из скбт. Дайте работу, а? Писать асинхронные декораторы тройной вложенности не умею и не буду.
Когда то давно, в далекой галактике я изучал ассемблеры Z80 и 86. И удивлялся как много можно уложить в 32кБ памяти.VS не сильно испортил программистов, хотя нормой стали уже десятки Мб. А вот когда массово в народ пошла .NET и толпой стали писать на Java, а процессоры и память перестали ограничивать быстродействие и размеры, всем стало плевать на культуру программирования, никто не зализывал баги и утечки и стало страшно смотреть, как hello word написанное современным "пахарем на ниве программирования" занимает в дистрибутиве сотни Мб....
React → Electron → Chromium → Docker → Kubernetes → VM → управляемая DB → API-шлюзы
Причём попробуй только обойтись без того же докера — сразу же словишь косые взгляды модных да хайповых коллег и обвинения в профнепригодности. Как будто без докера чуда не будет и ничего не запустится, ага...
И вот, у вас Win+Ubuntu/WSL2 и, внезапно, нужно поддерживать помимо стандартной тройки Win-Mac-Lin ещё сборку под Alpine Linux, где нет glibc. Или - как водится, внезапно - у клиента чего-то не работает на, скажем, CentOS 7, и надо воспроизвести проблему.
Можно, конечно, обойтись и без докера (или аналога) - напр., поднимать сервера (хотя, в современных реалиях это всё равно виртуализация) и делать всё там. Только геморроя, скорее всего, будет куда больше. С докером тупо делаешь всё локально, никого не отвлекая, и без лишних задержек.
Если требования именно такие — тогда полностью согласен, докер нужен.
Но ведь его пихают даже в простейших проектах, где ОС одна-единственная, и виртуализация даром не нужна...
Но ведь его пихают даже в простейших проектах, где ОС одна-единственная, и виртуализация даром не нужна...
Согласен. В достаточно большом множестве людей всегда найдутся такие, кто (метафорически выражаясь... или буквально) будут лампочкой забивать гвозди, а молоток вкручивать в патрон светильника.
Но это, всё же, индивидуальные косяки каждого отдельного проекта. Докер как инструмент тут, конечно, не при чём.
К слову, некоторые настраивают среду разработки так, чтобы иметь локально работающий "сервер", чтобы можно было дебажить в моменте - посредством докер-контейнеров. Из этих контейнеров запускаются разные нужные штуки типа СУБД, веб-сервера, компиляторов, транспайлеров и т.д. Сам по разным причинам такой подход обычно не использую, но понимаю тех, кто это делает - так хост не "загаживается" установкой и настройкой всевозможного софта. Когда работаешь одновременно с несколькими проектами это может оказаться существенным.
Часто докер это просто удобно. При чем тут хайп вообще? Он уже в 7 класс пошёл, а вы все хайп да хайп.
Вспомнилось...
Где-то в 1990-х (точнее уже не скажу) в OS/2 Warp обнаружил утечку в REXX. Детали уже не помню, но при длительной работе типа сервера что-то утекало (не то память, не то хендлы), причем в режиме OREXX этого не было (или наоборот, уже не помню).
Нашел доказательно, с конкретным методом убедиться etc.
Сколько ни писал - ноль реакции. Т.е. в принципе ноль. Перекочевало в eComStation.
Интересно, хоть к концу OS/2 кто-то починил?
Нытьё и передёргивание. Всегда ПО было таким. Или забыли Windows 95, которая регулярно падала с экраном смерти и периодически её приходилось переустанавливать?
Ну а деньги выделенные на датацентры под ИИ вообще никакого отношения не имеют к десктопному софту, о котором тут речь.
Согласен с написанным процентов на 60.
Сам люблю повозиться с мелочами и повылизывать качество, но: говоря о качестве софта нужно учитывать баланс между стоимостью разработки и ценой ошибки. Калькулятор в каком-то редком сценарии сожрал кучу памяти и вылетел с out of memory exception? Ну и чёрт с ним, цена ошибки невелика, запустят заново, если случай редкий то проще забить. То же относится едва ли не ко всему упомянутому в статье клиентскому софту. С серверами конечно строже, но понятие баланса есть и там.
Мы избаловались и стали тратить кучу ресурсов впустую, а абстракцию доводить до абсурда? - Да.
На волю, в пампасы, давайте вернёмся к ассемблеру? - Нет.
Нужно принять, что качество важнее скорости. Гораздо дешевле сделать сразу как следует, чем исправлять крупные сбои в продакшене.
Не всегда. Это баланс. А упоминание про продакшен вообще намекает что рассматривается только сценарий с серверами. В клиентской области всё сильно смещается в область быстрой добавки фич. Сами же клиенты в массе предпочтут чтобы один раз упало, зато прямо сегодня и круто.
Про проблему с ИИ и воспитанием джунов согласен.
На волю, в пампасы, давайте вернёмся к ассемблеру? - Нет.
А вот знать бы его хотя бы в рамках IA64-AMD64 стоило бы.
Замечание про баланс такое себе. Купили подешевле продукт, а он тухлый. Не то что с мелкими багами, а совсем для Вас не подходящий, потому что неоптимизирован и не проверен на работоспособность в Вашем сценарии.
Я бы предложил МинОбу обучать ассемблеру с последующим преподаванием, сколько чего потребляет какой, к примеру, объект в разных реализациях разных языков. Класса с 6-го. Толк виден невооружённым взглядом. Ценить ресурсы- это всегда важно.
Пока у гребцов будет нулевой "Skin in the Game" и "Zero responsibility" качество будет падать.
Уж все печатаю, договора, посадочные, счета, брони.
Сталкивался уже что то брони нет, то документы не видят.
Глобальный упадок качества ПО: как катастрофа стала нормой