Комментарии 197
Поэтому чтобы подтвердить свою точку зрения, я решил создать минималистичное, но функциональное решение обмена изображениями, которому смогу доверять
Ирония в том, что у истоков почти любого ПО искреннее стремление сделать что-то легковесное, быстрое, безопасное и т.д. А потом через N лет смотришь - блоатваря на те самые 50кк строк с зонтиком из 50 дочерних проектов.
Ирония в том, что у истоков почти любого ПО искреннее стремление сделать что-то легковесное, быстрое, безопасное и т.д.
Даже близко не у любого. Очень часто в истоках стоит желание исправить фатальный недостаток, переписать на язык X, сделать что-то на библиотеке Y, написать в стиле Z. Т.е. реальная причина для очередного софта вполне себе может не иметь никакого отношения к характеристикам продукта.
Кто первый напишет свою ОС - Nero или ACDSee?)
Есть у меня хобби-проект showcert (да, "реклама", пользуясь случаем - он опенсорсный) - такой мини-openssl тулкит. И с самого начала была четкая концепция - делаю простой и удобный инструмент, для 90-99% типовых админских/программистских задач.
Что я делаю, когда хочу посмотреть сертификат удаленного сервера. Во-первых - гуглю. Во вторых, пишу нанугленное, вроде:
openssl s_client -connect github.com:443 </dev/null 2>/dev/null | openssl x509 -inform pem -text
(Для простой задачи у нас аж два редиректа, пайп, два вызова одного и того же бинаря, и пять лишних ключей)! И это мы еще не грепали его вывод. Сравните:
showcert github.com
Вряд ли кому-нибудь придется гуглить эту команду - ее невозможно забыть! Если мы режем колбасу и открываем пиво - нам достаточно одного ножа с открывалкой, а офигенный швейцарский нож, которым можно звездолет починить - не слишком удобен.
И вот недавно метался с выбором, когда решил добавить функцию генерить сертификаты (self-signed и CA). Уж очень не хотелось увеличивать хелп в полтора раза и нарушать концепцию "ножа-открывалки". Решил через компромисс - добавил отдельную утилиту для этого.
Ну и вот за полтора года добавил всего один новый ключик (да и тот нужен для того, чтобы в 99.9% случаев другие ключики не указывать). Ибо вся суть проекта в том, чтобы было просто пользоваться. Проект, который во всем лучше, но сложно пользоваться (openssl) уже есть :-)
Когда сертификатов много, это боль, да.
Для консольного линукса я написал двухпанельный менеджер для jks и p12 контейнеров на баш, чтобы сертификаты менеджить ( https://github.com/sfkulyk/jks-manager )
showcert
добавить функцию генерить сертификаты
Ну вот был же соблазн)
К тому же само название утилиты не совпадает с функционалом генерации сертификатов.
Методология UNIX ещё ни кому не навредила.
Был соблазн, и я ему поддался в наиболее гуманной форме :-)
Cидел и философские думы думал.... Если этот мой пакет только для просмотра - тогда генерация не нужна. Если замена openssl - тогда нужна. Ну вот решил, что если добавить отдельной утилитой в пакет - это лучший способ. Кому нужна генерация - тем будет хорошо. А кому хочется просмотр сертификатов, ну так они разницы и не заметят, showcert (утилита) сложнее ведь не стала. Вес исходников - +6кб.
Я бы вообще в отдельную репу вынес.
Тоже думал про это. Я отказался по сумме, причины были такие:
Проще иметь один популярный репозиторий, чем два менее популярных. Тем более, что showcert уже как-то чуть-чуть известен, а gencert никак. Да и удобнее человеку поставить 1 пакет, чем 2. (да, отчасти это openssl-путь, но мне кажется, тут только плюсы с этого пути - т.к. вторая утилита не мешает)
"Стоимость" (место на диске) для лишнего скрипта в несколько кб - копеечная. Килобайты вполне можно до 0 округлить.
Современный тренд установки питоновских утилит - через pipx, когда для каждого проекта (утилитки) - свой virtual environment создается, а не все вместе, как раньше. Это отчасти хорошо - решает проблему, когда одному пакету нужна старая версия, а другому новая. Но все становится жирным. showcert со всеми зависимостями - уже 19 мегов. Если gencert делать отдельно, то оба будут 19+19=38 мегов. А если один - то всего 19.
Ну и unix-way - он скорее про программы, а не про пакеты. ls, tail, sort, stat, du и еще 100 утилит (каждая - вполне себе unixway'ная) - в одном coreutils, все вместе.
пишу нанугленное, вроде:
openssl s_client -connect github.com:443 </dev/null 2>/dev/null | openssl x509 -inform pem -text
Не проще будет написать эту команду в башевый скрипт и положить в ~/bin?
Для одной функции - да, я бы так и сделал - просто в коротком комменте не стал весь функционал расписывать. Но надо еще и проверять сертификаты pop3/imap/smtp серверов (а там через starttls), надо проверять сертификаты в файлах, надо иногда показывать только сам сертификат, а иногда интересна вся цепочка. Иногда нужен вывод в кратком формате, а иногда более полный (как у openssl). Иногда, если у нас проверка валидности неудачная - нужно выдать ошибку, а иногда нужно все равно показать сертификат, даже если он невалидный. Иногда нужно выдать особый код, если сертификат еще валидный, не просрочен, но просрочится скоро, через N дней (чтобы увидеть, что letsencrypt обновление где-то не прошло и надо чинить).
И вот весь этот набор фич надо так, чтобы не повторить проблему openssl - чтобы простые вещи по прежнему оставались простыми.
Есть похожая утилита sslscan, чтобы не гонять сканер от Qualys на каждый чих.
С одной стороны, я согласен со статьёй. А с другой - она всё-таки похожа на мем из КДПВ. Потому что нет анализа причин, приведших к текущему положению вещей. И нет никакого предложения, что с этим всем делать, чтобы улучшить ситуацию.
Ok, автор написал какую-то компактную программу. Но он при этом сам признаёт, что у неё есть более навороченный аналог. Откуда берётся уверенность, что экономия в размере - это достаточно весомый аргумент, чтобы большинство пользователей перешло на более урезанный функционал?
Проблема системная и решать её надо на уровне крупных корпораций, которые выпускают популярный софт. Сюда можно привязать, при желании, борьбу за экологию и заботу о пользователях.
Проблема системная и решать её надо на уровне крупных корпораций, которые выпускают популярный софт. Сюда можно привязать, при желании, борьбу за экологию и заботу о пользователях.
Системную глобальную проблему надо решать на уровне выше, чем корпорации. Ввести понятие энергоэффективности, например. Закрепить соглашением по типу "права на ремонт" экономический стимул повышать энергоэффективность.
Кстати, это уже вторая статья на похожую тему на Хабре на неделю.
Да, энергоэффективность - это один из факторов, который можно к экологии привязать. А так ключевой вопрос как раз в том, как сделать это выгодным для корпораций, ну или обязательным? При том, что правительство в этом ничего не понимает. Нужны, как минимум, какие-то экспертные исследования и петиции.
Корпорации сами заинтересованы в энергоэффективности - когда для выполнения той же задачи им потребуется в разы меньшее количество серверных стоек. Вот только никто не может предложить им такой софт.
Да могут им предложить такой софт. Просто он будет написан в два раза медленнее обычного софта, и более квалифицированными, а значит и более дорогими, разработчиками. И поэтому они его не купят, нужен-то он как обычно ещё вчера.
Половина корпораций платит за говнокод, который работает уже сейчас и даёт прибыль, а оптимизация начинается, когда приходит чек от какого-нибудь амазона в конце года.
Мне кажется, что все проще и необходимые механизмы уже существуют: если сумма исков из-за утечек (или затраты на юристов, чтобы эти иски отбить) выше прибыли от скоростного выпуска релиза, то повышение безопасности, а следовательно и снижение поверхности атаки, компании выгодно. А с экологией это театр безопасности типа рамок на входах: за счет внедрения "экологичных решений" снижается общий срок службы изделия и в пересчете на жизненный цикл устройство получается менее экологичным.
Как за счёт повышения качества может снизиться срок службы?
Не за счет повышения качества, а за счет повышения экологичности. Например, пайка бессвинцовым припоем, особенно при нарушении технологии. При этом я не очень понимаю, какие задачи решают ROHS и REACH, кроме меньшего отравления почв на свалках электроники.
Ну, это вы из какого-то своего контекста приплели. В контексте статьи, речь идёт о том, что более компактное и быстрое ПО потребляет меньше электричества и занимает меньше места на дисках, а значит их надольше хватит. Вот вам и экология.
Так-то да, но всегда можно написать кривые методы оценки, особенно если это кому-то выгодно. Например, собранная с ключом -Os программа маленькая, а с -Ofast быстрая, может получиться, что первая получит больше "экобаллов", потому как еще и нагрузка на каналы связи ниже :) Я к чему: если можно не привлекать государство сверх имеющегося, давайте не будем.
Ввести понятие энергоэффективности, например.
Мне это напомнило, что W3C выпустил черновик руководства по "устойчивому развитию".
Мол, юзайте технологии рационально, не делайте лишних запросов, не нагружайте веб-страницы, чтобы все это не приводило к лишним выбросам.
Кто знает, может в будущем в Google Lighthouse появится метрика, которая считает количество выбросов CO2 при использовании сайта. А там и законы подтянутся, как в случае с доступностью.
Два талона на интернет этому парню!
О, да, хухель как раз и поможет с экологичностью. большая часть малых, но по делу сайтов умерло из-за приколоченного намертво желания гугля только https. Всему своё. А гуглю важна прибыль, а на экологичность, если будет скидка на налоги, изобразят что-то, и с большой помпой, что в тысячи раз перекроет "выбросами" их экологичную продукцию.
Это просто очередной, как у ДюПонта, способ борьбы с конкурентами. Даёшь экологичные фреоны от ДюПонта... Прошло 30-40 лет и выяснилось что R12 никому кроме прибыли ДюПонта (патентные отчисления) не мешал. а теперь одноразовые системы охлаждения, с постоянной борьбой с смазкой и утекающими компонентами фреонов.
Сюда можно привязать, при желании, борьбу за экологию
Нужно найти или "создать" персонажа вроде Греты Т., только для мира IT.
Который максимально нелепо дискредитирует эту идею?
Нелепость подачи идеи не имеет значения.
"Для мира IT" == "оказывающий влияние на мир IT". Этот персонаж нужен не для вразумления ITшников, а для формирования общественного мнения. Чтобы можно было ткнуть пальцем на улей, сказать, что "это неправильные пчёлы, и мёд они делают неправильный" (с), и возмущённая общественность побежала бы закапывать свои мерзкие what_the_phone'ы, удалять возмутительно неэтичные приложения, публиковать эмоциональные ролики и т.п. Один улей похудеет, другие призадумаются.
Это, конечно же, всего лишь глупые фантазии.
Да, но перед этим она создаст охренительное море проблем для всех, и никто не уйдёт обойдённым. (с) АБС - Счастья, всем! И никто не уйдёт обиженным!
Главное создать кастинг на наиболее кретиническое лицо, чтобы Грета(тм) казалась эталоном красоты.
О причинах он упомянул, что скорее всего разработчикам дают слишком мало времени для нормального проектирования ПО.
И дальше у него есть предложение - закладывать больше времени на разработку.
Это довольно наивный взгляд. Если дать разработчикам в 2 раза больше времени на разработку, то большинство из них будут либо балду гонять, либо вторую работу себе найдут. И только весьма небольшой процент использует это время на написание более качественного и оптимального кода.
Согласен, потому что проблема не во времени, а в тени и компетенциях: зачем настраивать систему, когда можно просто взять готовый образ docker, пример утрированный, но по сути
Так понятное дело, что надо менеджить их ещё правильно.
Тут может ещё статься, что у большинства современных программистов тупо даже нет опыта оптимизации на достаточном уровне. Вспомните, сколько людей подключало лишнюю зависимость (left-pad) ради 10 строк кода. Так что ещё и тема с обучением маячит, а не только с менеджментом.
Да, так и есть. Приходят новички, которые никогда под медленные компы с малым количеством памяти не програмили. Ну и под старые мобилы.
...а я вот, когда между делом "рисовал web-отчёты", так ни одной библиотеки и не подключил - для графиков генерировал svg-картинки (да, прям текстом - благо, они были весьма простыми), для табличек использовал простейший css (расставляя стили прям в парсере данных, в процессе построения таблиц), всё обходилось штатными средствами седьмого PHP... правда, назвать меня не то, что современным, но даже и программистом-то - весьма сильное допущение (последний кусок кода, использованного "в проде" написал где-то в 93-м, на TP6, для учёта отпусков и больничных в одном из спортклубов, хотя глядя из "сегодня", писал бы на FoxPro, ну а потом свернул в несколько иное русло). Но глядя на коллег, которые на полном серьёзе тащят в проект целиком LibreOffice лишь для того, чтобы конвертировать приходящие в почту .xlsx в .csv, которые потом парсятся монструозными комбайнами на Java внутри контейнеров k8s, порождаемых на каждый пришедший файл, мне как-то не по себе становится порой...
если дать в 2 раза больше времени на разработку, все сливки с рынка снимут конкуренты.
какую-то компактную программу
какую-то
не какую-то, а с похожим на 99% функционалом, без необходимости подтягивать тонну зависимостей, et cetera
экономия в размере - это достаточно весомый аргумент, чтобы большинство пользователей перешло на более урезанный функционал
аргумент, чтобы большинство пользователей перешло
вот откуда можно сделать такой вывод?
Вся статья про то, что мерзкие людишки достали плохой код писать
не какую-то, а с похожим на 99% функционалом
Про 99% функционала вы откуда взяли? Сам автор статьи охарактеризовал конкурента так: "выглядит лучше и имеет больше функций". Из чего я делаю вывод, что он в лучшем случае 50-60% функционала пока сделал. Так как если бы там было хотя бы 90%, то можно было бы сказать "имеет сравнимый функционал".
вот откуда можно сделать такой вывод?
Пока можно сделать вывод только про то, что вы умеете вырывать фразы из контекста и превращать вопрос в якобы утверждение. Зачем вы так делаете, не подскажите?
решать её надо на уровне крупных корпораций, которые выпускают популярный софт
Конкуренция же. Голосовать надо "рублём".
Я долго выбирал домашний NAS и везде были какие-то проблемы с софтом. В итоге победил synology из-за их софта. И судя по отзывам не один такой.
Или при выборе между ПО на Qt и электроном на js, выбор будет в пользу Qt. Даже обычная домохозяйка или школьник заметят что нативные приложения работают быстрее и будут делать выбор в пользу них.
У большинства пользователей нет ни желания ни компетенций делать мало-мальский анализ. Покупается то что либо дёшево, либо хорошо рекламируется. Вы здесь исключение из правил.
У большинства пользователей нет ни желания ни компетенций делать мало-мальский анализ.
Бывает обсуждаю со своим окружением различные приложения. Многие отмечают разницу работы картографических приложений и часто отдают предпочтения тем или иным.
ПК геймеры часто выбирают какие-то приложения для игр, и перфоманс там далеко не на последнем месте.
Часто слышу у далёких от IT людей выражение "приложение тупит (или телефон), а вот это нет". Т.е. они так или иначе все равно делают выбор в пользу оптимизированного продукта.
Пользователи пользуются тем, что рекламируется в их окружении или стало привычным. Особенно чувствуется на телефонах тормозное и тяжёлое ПО. Начал искать по разным форумам и сторам - начал находить отличные примеры когда и apk мегабайта 2-3 и оффлайн быстро работает. А потом смотришь на обновление приложения для часов размером с 230мб. Проблема что хорошее ПО плохо рекламируется. А есть примеры когда изначально своими плюсами занимает место на подиуме (как 2гис когда-то, который работал офлайн), а потом продаются бизнесу (например сберу) и превращаются в донатную помойку.
Откуда берётся уверенность, что экономия в размере - это достаточно весомый аргумент, чтобы большинство пользователей перешло на более урезанный функционал?
У меня складывается впечатление, что современный маркетинг ПО основан на принципе "чем больше функций, тем лучше". Но на самом деле, чем больше (неиспользуемых) функций, тем хуже.
Представьте брелок с кнопкой для включения/отключения сигнализации. А теперь добавим ему ещё 100500 полезных функций и придётся выцеливать нужную кнопку среди десятка других. То есть, им станет (намного) менее удобно пользоваться для включения/отключения сигнализации.
В большинстве современных программ я использую менее 10% предоставляемых возможностей.
Это тоже верно. Впрочем, это скорее вопрос UX и позиционирования. В книге "Психбольница в руках пациентов" про это подробно расписано.
я использую менее 10% предоставляемых возможностей.
Но каждый пользователь использует свои 10%.
Но каждый пользователь использует свои 10%.
Да. Но значительная часть используемых функций, наверное, всё-таки общая почти для всех. Поэтому можно выпустить продукт в "базовой комплектации" и плагины к нему.
Если для двух пользователей значительная часть используемых функций различается, то им, очевидно, нужны разные продукты (вероятно, с разным интерфейсом). Издатель может выпустить два разных продукта, которые (где-то там внутри) используют общее ядро.
Спольский исходит из предположения, что "features make your life better (when you use them) and don’t usually hurt (when you don’t)". Но, в общем случае, данное предположение не верно. Из-за обилия ненужных функций мне сложно найти нужную.
Это увеличит время вывода продуктов на рынок, но уже готовятся законодательные нормы, которые заставят поставщиков ПО серьёзнее относиться к безопасности.
Боюсь что законодательные нормы только усугубят ситуацию, чтобы писать очень качественное ПО с акцентом на безопасность надо умножать любой бюджет на 2 (кто знает может даже на 22) и время соответственно, надо писать тесты, запускать инфру для тонны проверок (еще и проверять код всех зависимостей), контролировать исполнителей и т.п. бизнесы/государства точно готовы заплатить за это? А готовы ли конечные пользователи заплатить цену намного большую чем у конкурентов? Законодательная база фундаментально это ситуацию не изменит, просто уменьшит количество подрядчиков.
…как показывает автопром, чем больше надо получить сертификатов безопасности — тем больше в итоге дыр. Потому что задача безопасности подменяется задачей «ублажения», а если контролирующие организации пропустили дыру — её как бы и не было, они подпись поставили, значит, они теперь отвечают.
Ну, и юзер, у которого из-за бага умный руль вдруг на встречку повернёт. Но это их половые трудности, а не кодера, кодер с себя ответственность переложил.
Если бы экономия строчек кода на что-то влияла бы - все бы писали только компактные программы. А раз нет необходимости их экономить - никто этим не будет заниматься.
Мне как-то дали заказ - воспроизвести функционал программы. Оригинал был написан на Qt, весил 60 с лишним мегабайт, а папка после установки уже около 300мб. Моя реализация с тем же функционалом, но написанная на чистом c++ с GDI/GDI+ и с SQLite на борту заняла 1,9мб (и это с картинкой на бэкграунде). Установка вообще не нужна, запускается как калькулятор, коим, собственно и является программа (только узкоспециализированный).
Полностью поддерживаю крик души автора. А аргументы о том, что дешевле купить дополнительное железо, нежели год платить зарплату программистам, для меня разбиваются о затратах на ту же электроэнергию затраченную на время установки/запуска, если вдруг программа взлетела до миллионов установок. Понятно, что платит за это уже конечный потребитель, но тут как в анекдоте - зато ВВП выросло...
Калькулятор на QT налабает и тушканчик школьник. На чистых плюсах, наверное, нужен более высокооплачиваемый бобер специалист. Кого наймет сова-менеджер?
Там очень много причинно-следственных связей, которые влияют на скрытие/отображение заполняемых полей, а также SQL, так что Qt не особо поможет даже в интерфейсе: всё равно вся работа это поведение.
А ответ на ваш вопрос очевиден, поэтому даже отвечать не стану. Но очевиден и результат, о котором, собственно и пишет автор.
Нужно думать как решить проблему, а причин не решать я и сам десяток не задумываясь набросаю.
Нужно думать как решить проблему
Указывать размер бинарника в ТЗ.
Скорее - стек применяемых технологий. Например: C++, Boost, WIN32 API, etc..
А то с ограничениями на бинарик гарантированно придёшь к тому, что сейчас происходит у меня под носом: начальник требует ремонта за 8 часов, при том что список работ на 20 часов, которые нельзя выполнить параллельно, а только одну после другой.
C++, Boost, WIN32 API, etc..
А потом заказчик такой: "Надо такой же но под андройд".
Тут, как говорится - любой каприз за ваши деньги:-)
А если серьёзно, при продуманном проектировании, для переноса на android, потребуется дописать только интерфейс, который и без того пришлось бы перелопачивать при проектировании кроссплатформенного решения. А начинку вызывать как API через JNI. Работы на самом деле не на много больше.
А потом заказчик такой: "Надо такой же но под андройд"
Вот мы и докопались до причины всех бед.
Но и на других технологиях тоже можно сделать что-то лёгкое.
Например, в java довольно богатая стандартная библиотека, но она идёт вместе с JVM и общая для всех, тащить с программой её не надо. Сам байткод приложения довольно высокоуровневый и компактный, если не увлекаться зависимостями. Думаю, можно в 100-500 Кб уложиться.
Или например из забытых технологий более развитой цивилизации есть Delphi - в которой и кнопочки в интерфейсе было легко накидать, и итоговая программа весила немного.
Ну, со стандартным VCL все же проги на дельфе достаточно ощутимо для своего времени распухали и чем выше была версия дельфы - тем было хуже. Простейшая программа с парой кнопок и ничего почти не делающая могла под мегабайт и более быть. Но благо были проекты типа KOL/MCK и т.п., которые по сути при том же функционале позволяли генерить экзешники раз в 5-10 меньшие.
Но кому это надо? Недавно в Rust случайно обнаружили, что компилятор при релизной сборке кладёт в бинарник 4.8 мегабайта лишних данных - отладочные символы std. Сразу никто не заметил.
есть Delphi - в которой и кнопочки в интерфейсе было легко накидать, и итоговая программа весила немного.
с 1999 по 2002 я писал софт для радиостанций для управления выходом рекламы. писал на делфи. размер exe файла был 4.5 мегабайта и не умещался на дискету (это я молчу про необходимость наличия DLL BDE. В итоге открыл для себя UPX, который из EXE делал файл весом в 400 Кб. То есть очевидна проблема сборки EXE файла самой Делфи.
Ну помнится как раз варианты без обязательных bpl-библиотек в системе и весили много, т.к. все что надо для работы, необходимо было пихать в сам экзешник.
Я кстати тоже UPX-ом спасался в ситуациях когда надо было получить экзешник поменьше, но вот только вот антивирусы уж очень нервно в то время на упакованные экзешники реагировали, т.к. для них это как признак того что это возможно что-то вредоносное. Не раз бывало что тот же NIS, которым я тогда пользовался, прибивал экзешник сразу же, как только я его упаковывал :)
Нет там проблем, вес набирается из-за иконки, которая идет в комплекте и которую можно убрать. Вес идет от форм, которые в ресурсах ехе хранятся в виде текста. Ну и в те года мало кто задумывался о настройках компилятора, который можно настроить на оптимизацию и вычищение отладочной информации. В новых версиях добавили разные конфигурации и по умолчанию разделили Debug и Release, с соответствующими настройками.
Т.е. в 2002 ты мог в настройках проекта включить оптимизацию, исключение отладочных символов и убрать иконку проекта. И получил бы ехе размером в 1.3 мб (а то и меньше) без упаковщиков.
Мог также выключить рефлексию, которая много мета информации вкладывает в ехе.
вес набирается из-за иконки
XD вы сейчас серьезно? Размер иконки 766 байт - это классический размер тех лет.
Т.е. в 2002 ты мог в настройках проекта включить оптимизацию, исключение отладочных символов и убрать иконку проекта. И получил бы ехе размером в 1.3 мб (а то и меньше) без упаковщиков.
Я конечно безумно рад в такой беседе услышать про себя насколько я был тупой. Но нет, вы сильно переоцениваете мою тупость. Всё что требовалось для релиза - было проделано.
Вес идет от форм, которые в ресурсах ехе хранятся в виде текста
Они занимают немного места, хотя да, пакуются хорошо.
Вы просто Java обновите, хотя бы до 9 версии. Используйте jlink и модули и не придется jdk тащить. А если ещё GraalVM для компиляции будете использовать, то вам все в один бинарник нативный упакуют.
Указывать размер бинарника в ТЗ.
Соберут монстра и ужмут упаковщиком. :)
Причём у нетушкансика он и весить будет пусть не 2, но 5-6Мб. 300 получается, обычно, если человек не знает про windeployqt и копирует всю папку, включая отладочные библиотеки.
Аналогично, я такие вещи по сей день решаю «Си и плюсы в следовых количествах, „скулите“ или что там ещё нужно, винапи или под какую оно там платформу». Все эти «а оно у тебя на андроид не портируется» не работают. Ну, или покажите мне работающий GIMP или KDEnLiVE, которые «просто пересобрали под андроид» и они заработали, как талдычут эти апохренеты заворачивания всего в сто матрёшек.
Вся моя кодерская жизнь, пожалуй, в гигабайт влезет, это включая полные размеры проектов и скомпилированный код. Сколько сот терабайт данных через него прошло, сколько миллионов долларов он принёс — кто ж это скажет теперь… Был там и «школокод», и промышленный, и особо ответственный, и с красивыми картинками (а мне-то что, дизайнер рисует, а я отображу какой уж нужно), всякое было, короче.
Мой код даже тут понимания не встретил, чего уж греха таить. Да и не суть. Суть в том, что как минимум нас двоих рыночек не порешил, и я вполне дотянул до физического устаревания себя самого раньше, чем до морального, это свершившийся факт. Зачем так было писать? Ну, время и силы, которые я сэкономил на похеривании изучения каждый год новых модных-стильных-молодёжных средств разработки, тянут на небольшую человеческую жизнь. Это, кстати, относится и к предыдущему комментарию, «зачем экономить строчки кода». Я экономил не строчки, а себя.
зачем экономить строчки кода
зачем экономить строчки чужого кода. Думаете в том примере с Qt автор руками налабал 300 МБ бинарников?
Лицензия. Qt для коммерческого ПО с закрытым исходным кодом требует другой лицензии, нежели при его использовании в opensource.
Всё вышеперечисленное автором.
Любое усложнение запуска программы отпугивает большой процент пользователей (тут вопрос -тащить за собой зависимости или распространять единственный (подписанный) exe-файл. Я до сих пор уверен, что у одного разорившегося маркетплейса проблемы начались именно после того, как они принудительно перевели всех покупателей на двухфакторную аутентификацию, дико усложнив жизнь огромному проценту покупателей, которые в качестве решения проголосовали ногами.
То есть, тут вопрос не экономии строчек кода (напротив, строчек, как правило больше при нативном подходе), а забота о пользователе и энергосистеме государства. Ну и, конечно же, о собственном кармане, как бы не парадоксально это звучало.
Лицензия. Qt для коммерческого ПО с закрытым исходным кодом требует другой лицензии, нежели при его использовании в opensource.
Уже лет двадцать как только отдельные малонужные компоненты.
или распространять единственный (подписанный) exe-файл.
Самораспаковывающийся. С зависимостями. Типа как разные .exe под архитектуры у Sysinternals утилит.
"Калькулятор" нужно писать на Delphi/Lazarus.
Ну куркулятор, допустим, я напишу на C++ с GDI/GDI+, не вопрос. Но вот вспоминаю былые проекты, где нужен был гуй: то таблица нужна а-ля "Excel на минималках", то какое-нибудь docking окно или панель, то ещё какая хрень, совсем отнюдь не входящая в число стандартных элементов API. Ну я, допустим, при желании и это напишу, но, во-первых, сколько времени это займёт, а, во-вторых, со временем всё это разрастётся в эдакую "Qt на минималках", только не в пример хреново отлаженную и которую знают, кроме меня, дай боже ещё пара таких же ментальных инвалидов.
Что именно не входит в API? Common Controls отменили? Или ListView? А может Статические элементы, которые вы обрабатываете и изменяете как захотите? Это во-первых. А во-вторых, никто даже в чистом API не прописывает интерфейс через окна. Существуют ресурсы, которые вы спокойно рисуете визуально мышкой. Обработка сообщений от контрола не сложнее и не проще, чем у Qt, просто она другая. И никакой фреймворк вас от этого не освободит. Меняется лишь способ, а временные затраты практически те же. А вот вашему пользователю будет намного проще и скачать и установить это, хотя бы по соображениям затраченного времени. Помните как в сайтах? 4 секунды грузится- половина посетителей отваливается. А почему с загрузкой установщика по-другому? Особенно если программа скачивается только для того, чтобы посчитать и принять решение о покупке, да и то есть сомнения - а нужно ли это мне сейчас? Ещё и грузится долго... Думаете просто так все гуглы и микрософты компактные установщики дают, которые в свою очередь выкачивают нужное? Это в том числе и для разделения времени ожидания.
А потом потребуется это все на Линукс портировать. И пошло-поеxало - MainWin, ныне покойный, Wine, о котором заказчики не хотят и слышать, и т.д, и т.п, вплоть до полного переписывания виндозависимой части.
Но в целом да - компактные программы выглядят привлекательнее раздутых, при прочих равных.
Обработка сообщений от контрола не сложнее и не проще, чем у Qt, просто она другая
Если проект не слишком маленький, то часто нужна MVC архитектура. На голом WinAPI ее довольно дорого вышивать/тестировать/поддерживать. Библиотеки типа Qt или CopperSpice ее предоставляют из коробки. А так же неплохую рисовалку, и еще много чего нужного.
На всякий случай оговорюсь, что я только C++ приложения имею в виду, и только их GUI часть.
Ну, то есть, либо сделать всё по-простому на стандартных контролах Винды (или о чём там идёт речь), и убедить начальство/юзера, что им этого достаточно. Сомнительно, но окэй, кому-то, для каких-то случаев может действительно оказаться вполне достаточно. Либо упороться, на каждый случай, где нам не хватает стандартных контролов, собственноручно запилить свою отрисовку, свою обработку и пр. своё всё. Упарываться придётся плотно - например, даже такую простую вещь, как ресайз контролов под меняющиеся размеры окна ещё в MFC приходилось самому вручную писать (если я правильно помню, давно было, поправьте меня, если владеете более актуальными знаниями, отличными от моих). А в Qt/Wx положил этот контрол в layout/sizer и готово. Ну и далее, если делать хоть сколько-нибудь по-уму, придём к собственной библиотеке а-ля Qt, ну да, менее раздутой и, возможно, более заточенной под наши задачи на первых порах (это если у нас руки очень прямые). А если безумно каждый раз под каждый проект заново начинать, то о каком "писать компактно" мы вообще говорим? При чём тут какие-то "ресурсы рисуете визуально мышкой" я вообще не понимаю - rc-файлы? Которые текстовые, и в ранних версиях Visual Studio писались руками в текстовом редакторе, а потом примитивный графический добавили? Весьма нишевый и ограниченный инструмент, годный разве что для мелких статичных диалоговых окон.
Виртуально крепко жму вам руку. Но нас — программистов с таким подходом, по-моему, становится пугающе мало.
Да уже даже нас - программистов с подходом "просто возьмём Qt, фиг ли байты экономить" - становится пугающе мало, скоро, такое чувство, весь мир на Электроне перепишут.
<sarcasm>
20 лет спустя...
Да уже даже нас - программистов с подходом "просто возьмём Электрон, фиг ли мегабайты экономить" - становится пугающе мало
<\sarcasm>
40 лет спустя: "Да уже даже нас - программистов с подходом "просто спрашивай нейросеть, пока результат не примет плюс-минус желаемую форму в пятидесятом приближении, фиг ли промпты экономить - становится пугающе мало." Но я надеюсь к тому времени быть в глубоком маразме и не переживать по этому поводу.
Ага. Скоро как у юристов будет: либо ты гений и решаешь проблемы компаний, либо сидишь в в офисе, инструктажами по ОТ занимаешься... И что-то мне подсказывает, на вершине "пищевой цепочки" программистов окажутся нифига не "node.js" - разработчики...
Трогательно. Но Qt худо-бедно поддерживает не только MS, но и Linux, и вроде даже Mac. Там у Вас тоже с++ версии для них есть? И это только десктоп, а сегодня всем подавай мобайл. Андроид, Эппл там.
И всё это покрывают Web приложения безо всяких хлопот с нынешними и будущими версиями, и эффективность бекенда уже не так и волнует. Это про бизнес
Впрочем, если Вы работаете по цене электричества, так KDE под BSD, вроде так толком до сих пор и не портировали :)))
https://habr.com/ru/articles/789550/comments/#comment_26438962 ниже ответил. Версий под перечисленные платформы у оригинальной программы также нет и не предвидится.
Думаю, ваш пример не совсем релевантен, потому что исходный автор Qt приложения, вероятно, не мог предположить всех хотелок заказчика и бил наверняка, использовав заведомо достаточно мощный фреймворк. Вы уже знали, что конкретно требуется, и могли "срезать углы" без опаски.
Отнюдь! Это штатный программист компании, и его лико светится на сайте среди руководства. Сама компания не занимается программированием, а продаёт товар, для которого и создана расчётная программа. То есть, смею предположить, что автор точно знал что нужно от продукта. И, кстати, ни для Linux в целом, ни для Android в частности, версии нет и не предвидится... Казалось бы - Qt: просто пересобери, да?..
del - обсудили уже выше.
Наверно в простых задачах на раз - будет незаметно для простых пользователей. Вот когда хотим чего-то много, и часто, это выявит все проблемы разом и рассудит кто там наговнокодил
непостижимость должна вызывать подозрения, а не восхищение
Как в вопросе какого-нибудь божества ;)
Этот фреймворк слишком большой (перечисление всего, что написано в этой статье). Нужно написать новый фреймворк. Легкий. Быстрый. Безопасный.
Слишком много ошибок в велосипедах. Много кода. Читать невозможно. Применим вот эти и эти библиотеки. Они надежны.
Пользователи жалуются, что фреймворк почти ничего не умеет. Необходимо добавить два десятка фич. Открываем проект, даем всем желающим добавлять нужный функционал.
Наворотили фич, кода. "Все желающие" также наворотили фич, кода, понадобавляли библиотек.
Фреймворк еле шевелится. Читать его невозможно. Апи невменяемое, глючное, противоречивое, непонятное. Размер огромный. При каждом изменении версий библиотек проект разваливается.
Перейти к п. 1.
Фреймворк должен быть заточен под узкий класс задач, тогда он хорош.
Пример фреймворка для задач файловых менеджеров — Total Commander.
И его плагины, тысячи их! Не все хороши, но большинство. Потому что являются по сути приложениями для этого фреймворка, а он хорош и отвечает ровно своим задачам, не пытаясь предоставлять API для «полупрозрачного перетекания анимированного окошка с мультяшной деформацией содержимого».
1. Обозначить базовый функционал который не будет расширятся, только фиксы ошибок и багов.
2. Добавить возможность обвешивания плагинами.
3. ???
4. Получаем emacs
А надо всего лишь иметь некий utils.*, из которого по необходимости копировать нужные функции в проект :)
Вангую, учитывая скорость разрастания влияния на жизни людей программных продуктов и цифровых сервисов, не за горами бешеное родео жестких законов защиты прав потребителей в контексте ИТ, мы еще только у его истоков. Будут карать за качество, ложные обещания, утечки, распухания софта при той же функциональности, гораздо жестче чем сейчас, натурально оставлять без штанов шаромыжников-стартаперов. "Дикий запад" безответственности в софте сойдет на нет, подход станет взвешенным и прагматичным. Кто-то вспомнит эпоху со скупой слезинкой =)
Это не хорошо и не плохо, это будет реакция раздраженного общества и специалистов, кушающих это ложками, следствие - пакетных клоак JavaScript и фреймворков с зависимостями в стиле картин Маурица Эшера. Хотя "резервации" безусловно останутся, как они и сейчас есть в контексте других проблем.
Боюсь, что так. Общество не справилось с наркотиками само, путём «голосования рублём», хотя там была чистая продажа человеку новых проблем за его же деньги. Казалось бы, включи мозг и просто не покупай! Но не сработало. Здравый смысл не выручил.
Когда M$ ввёл эту новую парадигму (помним-помним, кто тот «герой», научивший всех торговать говном!) — было много надежд, что люди одумаются и не будут поощрять деградацию. «Город наводнился вдруг разумными людьми», ага. Наивно, конечно. Люди даже не смогли просто взять и не покупать наркотики, хотя там ну настолько всё очевиднее и настолько на поверхности лежит…
А куда денутся тонны легаси и привыкшие использовать его люди? Не просто будет поменять их привычки нежелание переучиваться. С этой иглы миру будет слезать так же больно как с нефтяной.
В подобных размышлениях нужно не забывать, что любая отрасль человеческой это не только абстракции и технологии сами по себе, а их неразрывная связь с нашей биологической иррациональностью и когнитивными искажениями.
Ведь все эти молодые и шутливые, усвоившие в юности парадигму разработки понесут её через всю свою жизнь.
С зарядок телефонных почти соскочили на одну, спустя 25 лет (переходный период у Apple) и тут смогут прийти к стандартам. Я верю в лучшее! =)))
Еще бы автомобильное "лоскутное одеяло" причесать, которое бортовые системы пишет и считает их творение идеальным и не требующем исправлений, с момента схода машины с конвейера, а если требует, то они его льют онлайн, что тоже отстой. Нужен баланс, а не крайности.
Те кто сейчас молодые и шутливые и так, все жизнь гоняются за модными способами разработки, как похотливый фавн за нимфами, так что переучиваться, им не привыкать - у них так вся жизнь прошла. Им только новую моду объявить нужно.
Это, однако, не объясняет того, что манагеры сносят имеющийся работающий продукт и приказывают переписать с нуля на говнопарадигмах всё ровно то же самое, да побыстрее, план горит.
Переход лепездрических книжек на ведроид в соседней теме — вопиющий пример. Там было всё и всё работало. Вдруг, откуда ни возьмись, появился в рот… сова эффективный менеджер.
Раньше (в любой момент времени) не было столько мамкиных программистов.
Увы, в мире рынка компании будут писать компактные программы только тогда, когда это будет выгодно.
Когда будет выгодно писать компактные программы?
Когда клиенты будут покупать десктопные приложения, а не web-энтерпрайз.
Когда эксплуатация компактных десктопных приложений будет дешевле web-приложений.
Когда клиенты будут покупать десктопные приложения, а не web-энтерпрайз.
На диске в 1 ТБ не особо заметна разница между приложением в 1мб и 100 мб.
Вот смотрите, на моем iMac с m1, то есть железо свежее, установлены Telegram и Whatsapp. Telegram на холодную запускается 1-2 секунды, Whatsapp 30–40 секунд, иногда минуту. Как вы думаете, заметна ли для меня разница между этими двумя приложениями по тому, сколько места они занимают на диске? Не знаю наверняка, на чем написан Whatsapp, подозреваю, что на Electron.
Свежий WhatsApp, установленный из AppStore, является нативным для Apple Silicon, и запускается быстрее телеграма (тоже нативный клиент, не tdesktop). Ни в одном клиенте при этом нет явных признаков электрона, но везде бинарник весит больше сотни МБ, но это просто больше похоже на статическую компиляцию зависимостей.
Так производители ПО боятся кряков, поэтому переносят код на серверы. Как решить эту проблему?
Это не является проблемой. Перенос кода в облако имеет множество плюсов. С точки зрения производителя ПО - он получает полный контроль над лицензированием этого ПО :) Перестал платить абонентку - выключаем или переводим в readonly.
Вторая причина - гибкость масштабирования и обновления. Можно поделить облако по регионам, можно делать канареечный деплой, можно поднять копию облака для тестирования. Можно оперативно выкатывать обновления в случае нахождения уязвимостей, можно бакапить с любыми критериями и т.д. Много плюсов вобщем добавляется при переносе кода на сервера.
Как решить эту проблему?
Если Вы готовы пойти стопами Ульянова-старшего, то можете подложить бомбу под дата-центр ;)
Кто в 2024 вообще ставит десктопные приложения, если практически все (в моем случае кроме idea) есть в браузере?
2024 год. Фильм в 10ГБ - норма. Ютуб по 1ГБ за ролик может тянут. Игры по 100ГБ. Диски за десятки ТБ.
И только какие-то чудики жалуются, что Хром со всей статистической линковкой в 230МБ. А то, что эти 230МБ позволяют на ЛЮБОЙ ОСи (коих сейчас дофига) работать - учесть не хотим...
Не нужны Java, .NET, Go, Rust с их за 100МБ! Назад в DOS/Unix!
Меня не особо бесят проблемы Хрома, но меня раздражает пухнущий софт на android от создателей самой ОС, системные приложения, или толстые приложения программы лояльности очередного магазина, без которого покупки в нем иррациональны, магазин мне нравятся, мне не нравится те кто ведет их мобильный проект. Если мне нравится условная ААА игра на 100-150ГБ, то почему тогда я должен покупать из за говнокодеров SSD на 2 ТБ под 10 таких игр + мои файлы, хотя проблема очевидно у индустрии, они просто спихнули свои издержки на сообщество и оно прожевало.
Возможно так и развивались ssd, hdd, ram. С повышенным спросом и конкуренцией. В будущем может петабайты будут стоят на компьютере, а вы хотите остаться на 256 гигабайт на системы + личные нужды
Я хочу память на кристаллах, как в Супермене и Стартреке =)
Любые факторы, даже негативные, безусловно двигают эволюцию. Только зачем самим себе их создавать? Для увлечения скорости и объема памяти существует масса более позитивных факторов, чем быдлокод гемдева - выборки данных в прикладных задачах стали больше, зависимости сложнее, нужно хранить и крутить их в разных ракурсах на дисках и в оперативной памяти. Скорость вообще всегда пользуется спросом.
На Андроиде наверняка запакованные иконки и картинки разных размеров весят больше кода с зависимостями. По-моему Гугл какие-то подвижки делает в сторону (на лету) составных приложений.
Если мне нравится условная ААА игра на 100-150ГБ, то почему тогда я должен покупать из за говнокодеров SSD на 2 ТБ под 10 таких игр + мои файлы
А вы и не должны. То есть вопрос скорее в том почему вы на это ведётесь и всё это покупаете.
Ну то есть сразу вспоминается Захар Май с его "Главная проблема музыки в России — это лично ТЫ! " :)
А если предзаказ, чтобы сэкономить 500р? Там объемы файлов не анонсят, или когда после и полировки тяжелыми патчами игра пухнет. Так-то да, при избирательном и консервативном подходе к покупке игр можно увернутся от таких пухлящей и наказать студию рублем. Но силы будут не равны, единомышленников будет меньшинство.
А если предзаказ, чтобы сэкономить 500р?
А вас кто-то заставляет брать предзаказ? Оно того стоит это "сэкономить 500р"? Получается что не особо.
Но силы будут не равны, единомышленников будет меньшинство.
Но вас всё ещё никто не заставляет это покупать вы всё ещё не должны это делать. То есть это ваше личное абсолютно добровольное решение.
Вот только размеры бинарников к этим 100-150ГБ имеет примерно никакого отношения, это текстуры, видео и аудио. Ради интереса даже проверил на своей текущей стимовской библиотеке, 0.6% приходится на .exe, 1.6% на dll. Еще лет 10 назад шутки про мыльные текстуры были актуальны, даже не вспоминая что до этого было. И единственное реалистичное решение (бесплатное dlc для UHD текстур и прочего) не то, чтобы без минусов, уверен куча людей не заметит и будет в отзывах писать про мыло в глазах и прочие шутки.
Мне очень сильно кажется, что в 150 гигов от кодеров зависит максимум несколько гигабайтов
Остальное - медиаконтент. Мы же все-таки ожидаем, что текстуры будут чуть менее мыльными нежели в Готике или Medal of Honor
Да какие несколько гигабайтов?) Самого кода там лишь несколько десятков или сотня мегабайт максимум, и это с учётом зависимостей и с раздуванием объёма из-за навешанной защиты, посмотрите современные игры. Другое дело что сами паки ресурсов – это не только текстуры, но и модели и всякие мапы с триггерами и логикой, в которых кодеры тоже часто участвуют.
Фильм в 10ГБ - норма. Ютуб по 1ГБ за ролик может тянут.
Вы весь фильм одномоментно сморите? В каждую секунду в память загружено от силы 50 Мб, это терпимо.
Ради интереса, слазил в свежую статистику стима.
Я вот как раз сторонник "дисков за десятки Тб", но "не всё так однозначно" (ну и вспоминается смешной случай буквально с выходных, когда в конторе занимающейся дисками и насами на вопрос про 14-16tb диски получил ответ "ну что вы, это уже энтерпрайз, у нас такого нету")
Ну и против хрома с его 230Мб работающим на любой системе (а мне на конкретной системе это зачем?) я почти ничего не имею. А вот к обязательно лежащей скачанной версии обновления еще на столько же и хорошо если одной, уже вопросики есть... (а ведь было время, делали люди диф-патчи, гордились этим..). Ну и когда в одной системе заводится второй, третий, четвертый....десятый хром электрон, то... снова не так всё однозначно становится.
А еще опера и edge, и каждый со своей уникальной статической линковкой позволяющей неизвестно зачем работать на любой системе.. И тоже с обновлениями..
И вот тут вроде бы осознать зачем когда-то придумали динамическую линковку, но паровоз им. Хрома уже не остановить, увы.
Вот да, последнее на что я смотрю - это на размер софта. Я например никогда не интересовался, сколько занимают chrome, notion, телега или какие-нибудь продукты jetbrains, мне без разницы. Они прекрасно выполняют свои функции и этого достаточно.
А вы сами захотите нужное вам приложение ждать, допустим, не год, а в пять раз больше, ради того чтобы оно вместо сотни мегабайт занимало десять? Даже, допустим, пускай оно будут вообще бесплатное и увеличение стоимости разработки роли не играет.
Обоснуйте откуда возник x5.
Ну пусть будет х3, как вам угодно. Ничего бесплатно не бывает. В общем-то, для этого давным-давно введена такая штука как "нефункциональные требования" - т.е. на скорость, потребление ресурсов, надежность и т.п. Или, типа, вы реально считаете, что кто-то специально в свои приложения вставляет пустые циклы и выделяет память под гигабайтовые неиспользуемые массивы? Сделали, что больше ресурсов потребляет, значит так было проще и быстрее - если все это при этом все равно укладывается в изначальные требования, то в этом нет ничего криминального. Возьмите с работы кусок кода и ради любви к прекрасному пооптимизируйте его в свободное и неоплачиваемое время - хотите такое?
Возьмите с работы кусок кода и ради любви к прекрасному пооптимизируйте его в свободное и неоплачиваемое время - хотите такое?
Да у меня полный гитхаб этого.
Вы используете старый и унылый аргумент "некогда точить пилу, надо пилить". Но я утверждаю что с какого-то момента ваша стратегия проиграет в эффективности.
Да у меня полный гитхаб этого.
Ага. У меня как бы тоже полный гитхаб таких же проектов - которые перманентно пребывают в состоянии переписывания "так чтобы было идеально", и так никогда и не допиливаются до состояния в котором их хотя бы уже можно использовать :) Совсем другое дело это когда вам надо сделать что-то действительно лично вам нужное - а тогда уже подход другой, а именно сделать это приемлемо для использования сейчас, чтобы начать это использовать сейчас, и только потом уже делать "чтоб суперкрасиво", "чтоб супероптимально", "чтоб супербыстро" и т.п. (и, на самом деле, "потом", оказывается, что и необходимости в этом как-то нет). Если вам реально нужен автомобиль для поездок в деревню, то вы не станете ждать когда у вас появятся (а, очень возможно, что и вообще никогда не появятся) деньги на последнюю модель "Лендровера" - вы просто купите то, на что у вас деньги есть, и уже на следующий день будете на этом туда ездить.
Вы используете старый и унылый аргумент "некогда точить пилу, надо пилить".
Да, но только вот (допустим), чтобы наточить пилу, надо на неделю вообще бросить пилить и везти её в ближайший город за три сотни км, потому что только там есть специальный инструмент для заточки именно таких пил. Либо (учитывая, что пила все-таки пилит), просто взять и закончить свою работу по распилке до вечера.
Я и говорю что с какого-то момента. Если вечером мы вливаем последний коммит и больше никогда к этой программе не вернёмся, конечно можно и срезать углы. Только вот по моим наблюдениям обычно ситуация не такая.
А что мешает оптимизировать что-либо потом, когда действительно понятно, что надобность есть? Делать "не самым оптимальным способом" это не означает "делать лапшу". Пишешь просто изначально хотя бы просто нормально структурированный код, потом, когда (и если) будет надо, то оптимизируешь именно ту часть для которой это имеет смысл. А если ты, наоборот, изначально пишешь говнокод, то всё равно рано или поздно ты с ним горя хапнешь - с тем насколько он при этом оптимальный или неоптимальный это никак не связано.
Так оно сразу понятно, что если вы плите 5 часов вместо трех, то в каждый конкретный день проще допилить до вечера, чем весь день ахнуть на поездку в соседний город на целый день.
Только потеря 2 часов в день окупает поездку уже за неделю. Но в каждый конкретный день - уж лучше 2 часа потерять чем восемь.
А если надо положить неделю на заточку в городе за 300 км, то окупится за 20 дней, но мы все равно год будем откладывать. Это ж целая неделя без полезного выхлопа!!!
Как энтерпрайзник, скажу - да, никто не требует писать правильно и хорошо. Наоборот, требуют делать быстро и не заморачиваться оптимизацией. Хотя под "не выполнять оптимизацию" вся контора начинать понимать, что надо писать ПЛОХОЙ код. А потом при запуске клиентом расчета по всем своим клиентам-потребителям вдруг внезапно выясняется, что вместо примемлемых трех-пяти часов расчет по всей базе клиентов выполняется несколько суток.
И начинается беготня и горение пуканов.
Да, между "неоптимизированным" и "плохим" кодом огромная пропасть.
В то время как конкурент сделает обычным способом за условный год и заберет твой рынок :)) пока ты делаешь супероптимальный софт :)
Эти конкуренты — они сейчас с вами в одной комнате?
Полно софта, которому уже не надо (или даже и не надо было) никого обгонять. Выше сравнивали Телегу и тормозной Ватсап — почему Ватсап до сих пор не сделали таким же быстрым? Рынок у него уже есть — в чём дело? Не кажется ли, что его тормознутость может начать тянуть его долю вниз?
Рынок у него уже есть
И на минуточку - гигантский рынок. А не оптимизируют, потому что надобности нет. Потому что всё равно пользуют, ибо население весьма консервативно в этом отношении как показывает статистика использование того же вацапа по годам.
так написали ж что переписали ватсап нативно и теперь он быстр и прельстивен. Видимо прочитали комменты на хабре
История с Okta.
Я давно уже приглядываюсь к сервисам аутентификации и считаю, что да - они нужны, полезны и это прекрасно, что такую сложную штуку, как аутентификация можно не писать самому, а "взять взаймы". Особенно для маленьких проектов, где написать правильную аутентификацию - это сложнее, чем сам проект. И я согласен с их частым рекламным доводом - "будешь сам писать аутентификацию - наделаешь ошибок и тебя взломают".
Однако, как ни странно, окту взломали, а мои проекты - нет. Почему? Может быть потому что я правильно реализовал простую аутентификацию (у окты - явно сложнее). А еще - может и потому что "неуловимый джо" и "security through obscurity". Никому мой микро-проект не интересен. Но это, тем не менее, предохраняет. А вот у Окты этого козыря нет, и встает вопрос - а все ли они сделали правильно? Каждая ли строчка кода - безуспешна? Ибо взломать их - это получить доступ к корзинке, где все яйца. Требования к сервису аутентификации несравненно выше и объем кода у них огроменный. Так что, собственная дырявая аутентификация может иногда оказаться безопаснее.
Количество юзеров окты и своего сервиса ты тоже сравнил?
Здесь ведь вопрос интереса и денег - окта очень много где используется, и эти сервисы могут быть интересны потенциальным взломщикам. Ну и да, окта несоизмеримо сложнее, потому что универсальность. Тот же auth0 за два клика позволяет добавлять кастомные аутентификации через соцсети. Добавить в твой проект аутентификацию через linkedin или twitter - это даже кодить не придётся. И да, это требует кода на стороне auth0.
Меня в безопасности давно привлекает проблема "барьеров", "водоразделов", или "отсеков" (как в подводной лодке) не знаю как сказать, в общем, надежных препятствий на пути взломщика. Смотрите, самый простой случай - джун пишет вебсайт. Естественно, делает кучу ошибок, и там у нас куча дырок. Да. Может быть, там будет SQL Injection или RCE. Допустим. Но при этом:
Взломщик получит доступ к юзеру в этой базе данных, но не получит доступа за эти пределы. Разграничение доступа в СУБД работает надежно и как-то взламывается крайне редко.
Пусть даже сможет взломщик исполнять команды от www-data на системе. Неприятно, да. Однако, выйти за пределы юзера - не сможет. privilege escalation в ОС встречаются крайне редко и быстро фиксятся.
Допустим он как-то зарутил даже машину. Но это контейнер в докере. Выйти за пределы докера - тоже не сможет. Такого рода уязвимости тоже крайне редко встречаются.
Мне кажется, правильный подход - это создание вот таких вот надежных барьеров. Они должны быть простые и почти "вечные" (не переписываться при каждой новой фиче в программе). Так же, как в Linux вряд ли часто есть изменения в коде sudo / setuid().
Если мы один раз это отладили - все, ожидаемые потери уже гораздо ниже. Можно делать это самим, разбивая систему на разные API, но по возможности лучше использовать готовые, проверенные (как разграничение доступа в СУБД, разные юзера в линуксе и докер-контейнеры).
Если мы вынесли всю логику во фронт, и на бэке у нас только простой API - его проще сделать безопасным. А фронтендеры пусть там резвятся, у них при всем старании сделать дырку - вряд ли это получится.
А есть какие‑то сайты‑подборки с условным адресом noelectron.apps? По аналогии с privacytools.io, который агрегирует софт без скрытого отслеживания.
Даже на alternativeto.net такой фильтр отсутствует — только вручную смотреть по описанию программ, использован ли там богомерзкий «Электрон».
Увы, возиться с чистым и экологичным кодом сейчас мало кому охота; тяп‑ляп, куча библиотек, фреймворков и зависимостей — и в продакшн. А юзвери пусть грызут кактус и докупают плашку «оперативки».
А ещё на Ру‑борде есть тема «Маленькие программы (размер в архиве не более 99 кб)», активна до сих пор. Умеют же люди писать экономный код.
suckless.org например, хоть он и немного про другое
Да обычно стараешься, пишешь что-то маленькое, разделяешь, а потом часа в 3 ночи, когда у тебя уже нервы сдают, ты просто вставляешь то, что будет просто работать.... Вот вам и начало тяжелых ПО....
Я не работал в команде, поэтому не могу представить. Но почему в команде не может быть разработчик, который только и делает, что рефакторит разрабатываемый проект? Упрощает, организует.
Все так и ничего с этим не поделать, к сожалению.
мне нравится генерить exe на C#, по размеру получались меньше 10K, но с переходом на 6.0 и сейчас 8.0 минимальный размер уже чуть больше 100К, но всё же не так страшно.
плюс тут именно в том, что .NET уже есть в системе и используется другим софтом, мне кажется точно такой же эффект получается когда в винде пишешь софт с использованием WinAPI, думаю все знают достаточно много софта для винду с конца 90-х которое занимало пару сотен килобайт но делало массу полезного.
Поясните, откуда взялась вообще необходимость паковать ПО в Docker для его распространения, на что жалуется автор? Неужели там столько системных зависимостей? Или всё дело в каком-нибудь Python, который глубоко пускает корни в системе?
паковать ПО в Docker
Хоть не в virtualbox ;)
Просто, удобно, воспроизводимо. Не нужны простыни с инструкциями "подключить вот эти репозитории вот таким образом, установить вот эти пакеты. а для вот этого линукса - вот так."
Разработчикам, особенно энтерпайсовым хочется - чтобы их софт просто запускался и работал, особенно если их конечный пользователь с трудом в состоянии открыть терминал.
Даже с deb пакетами из официального репозитория при этом есть ненулевая вероятность словить ситуацию конфликта версий библиотек, когда пользователю выдаётся совершенно неочевидная ошибка, и он в лучшем случае идет писать в гите вопрос про это дело.
Теперь представьте что у вас такой не 1, а их тысячи, и всё из за того, что их система не той версии, не так сконфигурирована или имеет не те зависимости. Вы хотели заниматься разработкой продукта - а стали техподдержкой линукса.
Кстати интересно - почему-то на харбе часто появляются статьи про умшенное устаревание техники, но редко про умышленное устаревание софта - ведь по сути вся система разделяемых библиотек, обратной стороной имеет то, что приложение выпущенное для позапрошлого релиза ОС просто не запустится т.к. все библиотеки уже обновлены на несовместимые. Получается даже законечнная программа весь функционал которой реализован будет нуждаться в поддержке...
Тут более грамотное решение - паковать все зависимости с программой, а не нахлобучивать поверх Docker. Да и вроде для этого существуют штуки вроде Flatpack.
На счёт устаревание софта это прямо мая боль - на Ubuntu 18.04 до сих пор обновляются регулярно snap пакеты, при этом иногда ломаясь из-за того, что каких-то свежих библиотек им не хватает.
Подход Windows мне больше нравится - там бинарная переносимость довольно хорошо работает, так что программы, написанные под WindowsXP часто и на Windows 10 работают. И какой-нибудь Docker там никто для распространения софта не использует. Проблемы могут только быть, если в Windows какой-то Linux-овый софт пролазит, вроде того же самого Python.
Flatpack и snap тоже имеют разные проблемы совместимости (где-то вроде тут недавно была статья про то, что steam запакованный в snap работает плохо, а flatpack грешит таким уровнем изоляции, что часть пользовательского функционала в нём не реализовать без тонны костылей типо прокидывания в контейнер чего-то там).
Docker выглдяит как более тяжелое но еще более устойчивое решение (на мой взгляд).
Windows корят за то, что за некоторыми исключениями каждое приложение тащит все зависимости внутри себя, и из за этого раздуывается до неадекватных размеров, а так-же не устраняются уязвимости которые являются следствием уязвимых библиотек.
Короче есть несколько вариантов и все плохие)
Линус на каком-то докладе почти слово в слово излагал те же мысли. Он сказал что за совместимостью апи ядра они следят, но за тоннами библиотек нет, и кто-то другой должен решить как линуксу развиваться в плане зависимостей. Мне кажется докер хорошая среда для запуска сервисов. Но вот с десктопным применением пока нет единства. У меня сейчас есть и снап и флетпак - смотрю сам как они в пользовании. Флэтпак больше идейно нравится чем снап. Ещё удобно ставить в них софт посмотреть, решить нужно оно или нет.
Тут более грамотное решение - паковать все зависимости с программой
Более грамотное решение — иметь зависимости в общей локации (как/windows/system), однако при этом версионировать их, то есть не /windows/system/msvcrt.dll, а /windows/system/msvcrt.2.323.4123.dll При этом, с одной стороны, все программы работают с теми версиями интерфейсов, каковые им "привычны", а с другой стороны, лишнее место не тратится.
А кто будет туда эти зависимости складывать? Если системный пакетный менеджер - то будет тот же ворох проблем, что есть сейчас, с устаревшими программами на старой системе.
А если же это будет как в Windows, когда установщик каждой программы сам туда что-то записывает, то могут быть проблемы с тем, что библиотеки фактически различны при номинальном совпадении версии, что в итоге вызывает сложнодиагностируемые проблемы.
Расшаривание библиотек сейчас вообще мало смысла имеет, за исключением именно что исконно-системных, вроде kernel32.dll или glibc. Памяти сейчас полно, что оперативной, что дисковой, так что уж лучше дублировать библиотеки, чем иметь dll hell. В принципе сейчас и так уже такой происходит с упомянутыми ранее Electron приложениями, где каждый чат-клиент с собой целый браузер тащит.
Угу, были у меня как-то покер стратеджи и 1С. Решил я помучить постгрес, раз уж он бесплатный и клиенты импортозамещать MSSQL начали активно. Денек убил на то, чтобы найти админ пароль от постгреса, который поставила себе покер стратеджи. Было бы все в докере - было бы просто 2 докера с постгресом от 1С и от PS и пара вольюмов с базами данных.
И какой-нибудь Docker там никто для распространения софта не использует.
В Windows это называется MSIX.
ситуацию конфликта версий библиотек, когда пользователю выдаётся совершенно неочевидная ошибка
То есть вариант «писать в сообщении об ошибке детали произошедшего вместо невнятного „что-то пошло не так“» даже и не рассматривается?
Ухтыж, как дети. Софт делают потому что платят. Платят что бы сделать за 3 секунды. Сделаете за 4 - не заплатят. Выбор - сделать на електроне за 3 секунды и кушать месяц, или сделать принципиально маленькую софтину, и стать солнцеедом?
Большинство (почти все) людей, к сожалению, так устроены, что не станут напрягаться, чтобы начать решать какую-либо проблему, пока эта проблема не перерастёт в катастрофу
Программирование перестало быть искуством в массе своей, это труд и каждый трудится как может и как может продать то что он сделал. Кто-то, как автор и как я -- ругается. Кто-то надеется, что AI решит проблему. Я не верю в решение, потому что AI будет обучаться на том что есть, а то что есть - это толстые системы. Зачем AI писать на С++ или Rust, если масса кода на TS/JS/Py и, конечно, Java.
Призыв писать компактное ПО, версия 2024 года (с примером кода)