14 января 2020
Законы Мирволда
Александр Носков
Завершено расследование дела о «раздутом» софте и низкой производительности наших смартфонов. Кому предъявлены главные обвинения?
Наверное, каждый опытный пользователь понимает, что программное обеспечение его смартфона написано исходя из возможностей некоего среднего мобильного процессора, взятого разработчиком за основу, который в теории обеспечит плавную работу софта. Программист не станет писать новое приложение для смартфона 10-летней давности или такого, который еще не появился в продаже. Соответствуют этому утверждению и возможности текущей операционной системы, которую пишут исходя из возможностей современного вычислительного «железа». В общем и целом, программный код и вычислительные средства сосуществуют естественным образом, гармонируя друг с другом в своем развитии.
На первый взгляд, в этой гармонии все хорошо, но среди пользователей смартфонов нет-нет, да и раздастся удивленный вскрик. Откуда этот вскрик? В бытность Android OS 9/10, казалось бы, решены проблемы с безопасностью, с повышенным расходом заряда аккумулятора и плохой связью, но нерешенным остался один вопрос – вопрос внутреннего хранилища и размера приложений. С прискорбием констатируем, что проблема «распухающих» приложений, которые со временем заполняют жесткий диск любого объема, никуда не делась, а простые решения, такие как очистка временных файлов, не спасают, если распухает само приложение после очередного обновления. Самое удивительное в этом то, что когда мы говорим о простых приложениях, таких как «погода» или «новости», то абсолютно непонятно, зачем и что делают новые десятки мегабайт, какова их роль в отрисовке WEB-страницы, есть ли хоть что-то, для чего они были бы нужны. Самым простым ответом являлся бы ответ о встроенной рекламе или скрытом вирусе-майнере, но это не так. Другие пользователи могли заметить, что после многочисленных обновлений, а особенно когда речь идет о нескольких годах использования определенного смартфона, программное обеспечение начинает работать хуже. Непонятно, откуда берутся «микрофризы» и некая общая «задумчивость» смартфона. Глядя на то, как объем внутреннего хранилища смартфонов становится все внушительнее с каждой новой выпущенной моделью, легко впасть в заблуждение и предположить, что производитель вступил в сговор с разработчиками ПО. Целью такого сговора должна стать вынужденная покупка нового смартфона, ведь пользователь был бы практически выдавлен со старого смартфона разбухшими приложениями, образно выражаясь. Но и это не так. В основе всех описанных проблем лежат человек и производственные системы, которые он строит.
Недавно мне на глаза попалась очень интересная статья Джона Нотона (The Guardian), в которой автор все расставляет по полочкам. Не могу не привести ее целиком, выделив жирным текстом интересные утверждения:
Еще в 1960-х годах Гордон Мур, один из основателей Intel, отметил, что количество транзисторов, которое может быть установлено на кремниевом чипе, удваивается каждые два года. Поскольку количество транзисторов связано с вычислительной мощностью, это означало, что вычислительная мощность фактически удваивалась каждые два года. Так родился закон Мура, который вселил уверенность в большинство людей, работающих в компьютерной индустрии. Такую же уверенность в завтрашнем дне, какую законы Ньютона вселили в инженеров-механиков.
Однако есть одно отличие. Закон Мура — это просто утверждение эмпирической корреляции, наблюдаемой в определенный период истории, и мы достигаем пределов его применения. В 2010 году сам Мур предсказал, что законы физики остановят экспоненциальный рост. «С точки зрения размера транзистора, – сказал он, – вы можете видеть, что мы приближаемся к размеру атомов, что является фундаментальным барьером. Пройдет еще два или три поколения, прежде чем мы доберемся до такого уровня. У нас есть как максимум еще 10-20 лет, прежде чем мы достигнем фундаментального предела».
Сейчас мы достигли 2020 года, и поэтому уверенность в том, что у нас всегда будет достаточно мощное вычислительное оборудование для наших растущих потребностей, начинает казаться неоправданной. Так как это было очевидно в течение десятилетий для тех, кто в бизнесе, было проведено множество исследований по новым способам получения большей вычислительной мощности, например, с использованием многоядерных архитектур, в которых ЦП имеет два или более отдельных процессорных блока, называемых «ядрами», – в надежде отложить ужасный день, когда кремниевый чип наконец исчерпает себя. (Например, новый Apple Mac Pro работает на 28-ядерном процессоре Intel Xeon). И, конечно же, существует множество безумных исследований в области квантовых вычислений, которые, в принципе, могут стать эпохальной разработкой.
Но вычисления включают в себя комбинацию аппаратного и программного обеспечения, и одно из предсказуемых последствий закона Мура состоит в том, что они делают программистов ленивее. Написание программного обеспечения — это ремесло, в котором одни люди лучше, чем другие. Они пишут более элегантный код и, что более важно, более компактный, что позволяет ему выполняться быстрее. На заре индустрии, когда аппаратное обеспечение было относительно примитивным, мастерство действительно имело значение. Когда Билл Гейтс был юношей, он написал интерпретатор Basic для одного из самых ранних микрокомпьютеров, TRS-80. Поскольку у этого компьютера было крошечное ПЗУ, Гейтсу пришлось уместить код всего в 16 килобайт. Он написал это на ассемблере для повышения эффективности и экономии места (существует легенда, что даже спустя годы он мог прочесть код наизусть).
Есть тысячи таких историй времен первых компьютеров, но когда закон Мура вступил в силу, то необходимость писать компактный код постепенно исчезла. Программирование стало промышленной отраслью, а «разработка программного обеспечения» стала профессией. Построение разросшихся программных экосистем, таких как операционные системы и коммерческие приложения, требовало больших групп разработчиков. В группах разработчиков пустила корни бюрократия, появились руководители проектов и руководители над ними. Крупные проекты превратились в марш смерти, подобный описанному в знаменитой книге Фреда Брукса «Мифический человеко-месяц», которая была опубликована в 1975 году и издается до сих пор по причине своей актуальности. И этот бюрократический процесс в значительней степени несет ответственность за «раздутие» программного обеспечения, его неэффективность.
Но это все не имело значения, потому что аппаратное обеспечение (компьютерное железо) всегда обеспечивало вычислительную мощность, которая скрывала проблему «раздутого ПО». Добросовестных программистов часто это бесило. «Единственное следствие мощного аппаратного обеспечения, которое я вижу, – писал один, — это то, что программисты пишут на нем все больше и больше раздутого программного обеспечения. Из-за того, что ЭВМ мощная, они становятся ленивее, они не пытаются изучать алгоритмы, оптимизировать свой код … это безумие!».
На лекции в 1997 году Натан Мирволд, который когда-то был техническим директором Билла Гейтса, изложил свои «Четыре закона программного обеспечения»:
- Программное обеспечение похоже на газ – оно расширяется, чтобы заполнить свой контейнер.
- Программное обеспечение растет, пока оно не ограничено законом Мура.
- Рост программного обеспечения делает возможным закон Мура, ведь люди покупают новое оборудование, потому что оно требуется программному обеспечению.
- Программное обеспечение ограничено только человеческими амбициями и ожиданиями.
Поскольку закон Мура достигает конца своего владычества, законы Мирволда предполагают, что у нас осталось только два варианта. Либо мы умерим наши амбиции, либо вернемся к написанию более простого и эффективного кода. Другими словами, назад в будущее.
На этом заканчивается статья Д. Нортона.
Заключение
Недавно отгремело очередное событие мирового масштаба в сфере потребительской электроники CES. И, пожалуй, это первый раз, когда на выставке не было показано ничего по-настоящему инновационного. Это личное мнение, с которым могут не согласиться более удачливые наблюдатели инноваций. Были показаны устройства, которые можно описать как результат последовательного развития в рамках более ранних концепций. Условно, было десять мегапикселей, стало двадцать, было 256 ГБ, стало 512 ГБ, и так далее. Шаблонное развитие во всей своей красе. Также было много откровенно ненужных вещей, после знакомства с которыми, тем не менее, не жалеешь о потерянном времени. Типичной такой забавной инновацией является модуль с термометрами Weber Connect smart grilling hub, который делает любой гриль чуть ли не «умным» (в западных изданиях часто употребляют слово «smart» в его отношении).
Передовая инженерная мысль была направлена прямо внутрь куска мяса для гарантированного решения вопроса о степени его прожарки. И, как мне кажется, покупать его будут жители одно-двухэтажной Северной Америки, а для остальных частей света такой прибор не нужен, ибо мы любим готовить и прекрасно справляемся без датчиков. А того, кто не умеет, градусники не спасут. И принтами с такими примерами «инноваций» можно выстлать футбольное поле, отсюда и печальный итог – выставка достижений CES 2020 показалась провальной в вопросе демонстрации новых технологий. И этот печальный факт заставляет задуматься, искать причину, которая, как мне кажется, перекликается с проблемой «толстого» софта. По крайней мере, в части шаблонного «изобретательства» и «прогресса», из которой следует, что на следующий год процессор в блоке термометров для гриля станет быстрее, датчиков станет больше, а приложение-компаньон для смартфона станет «толще».
Вывод из статьи Нортона напрашивается сам собой – в раздутии программного обеспечения в наших смартфонах виноваты производители кода, среди которых нельзя отделять бюрократов от программистов, ибо все они являются частью системы. И эта система работает так, что размер кода (программы) – это последнее, на что обращается внимание. Мы поговорили о нехватке объема внутреннего накопителя, во многом из-за того, что об этом нам сообщает сам смартфон, эта проблема на виду во всех смыслах этого слова. Но отсутствие оптимизации кода проявляется и в нехватке оперативной памяти, а если рассматривать вопрос еще шире, то можно заметить отсутствие оптимизации даже в официальном оформлении социальных сетей (например, использование относительно «тяжелого» графического формата .png там, где он не нужен), а в еще более широком смысле – во всей нашей жизни. Выходом из ситуации может стать появление оптических ЭВМ, тогда человечество и дальше сможет производить и потреблять неоптимизированный софт. Такой исход кажется более вероятным, чем появление здравого смысла в головах коммерчески настроенных граждан. На нынешнем этапе развития отрасли мы видим подтверждение всему вышесказанному – появление мобильных ЦП с огромным количеством вычислительных ядер, основным хранилищем емкостью около терабайта и количеством оперативной памяти, которому позавидует игровой компьютер десятилетней давности.
А вы что думаете? Что может урезонить разбушевавшихся производителей? А особенно было бы интересно почитать мнение действующих профессиональных программистов, что бы они ответили на предъявленные обвинения?
Чушь вонючего носка
Кажется, кто-то решил побить рекорд?
Ну так программы только тогда не будут жрать место , когда их кто-то будет в этом ограничивать.
На Андроиде это никто не делает вообще — нет никакой политики в сторе ан эту тему.
А вот у Эпла наоборот — есть политика и при приеме приложения в стор проверяют в том числе и то какие файлы создаются и в каких папках. И если приложение плодит файлы папке которая предназначена для бекапа, то пока авторы не обьяснят что это и что это именно контент созданный пользователем, а не скачанный и т.п., то приложение в стор не попадет. А если приложение плодит файлы в других папках, то система в любой момент эти папки может прочистить (и прочищает) — приложение должно на это адекватно реагировать.
Но это понятно только на гламурных пидорских айфончиках — то ли дело брутальный свободный Андроид — свободный — ну так приложения и пользуются этой «свободой» как хотят их ленивые программисты.
Конечно-конечно, достаточно посмотреть на размер одного и того же приложения в сторах. Ну, например фейсбук:
Гугл: https://uploads.disquscdn.com/images/38ddbefe1ef530c772cb25a4a87be7382de5c21e0491277ada97013e8efda301.png
Яблоко:
https://uploads.disquscdn.com/images/977637222046b335573339b84873694191be11e580d097e761a88fd546d0f9f5.png https://uploads.disquscdn.com/images/8687199f42458d5c8344144cac8d764c66e40024136a2d29976e39a669f8a28e.png
Не говоря о том, что в магазине гугла размер приложения прямо перед глазами, а на яблоке до него еще докопаться надо.
А что потом показывает для развернутого приложения? А по оперативке?
Установил, залогинился, загрузил главную страницу:
https://uploads.disquscdn.com/images/35f0102ff6241108b7edfc6fb67665a855d02dbf20b795cab09c64b0e7844c0f.png https://uploads.disquscdn.com/images/91520b445f26c511f02a708c301fdb9ca3283287ec7994bc4d685a8268d5d0ad.png
Если научите, как на яблоке глянуть сколько каждое приложение жрет оперативки — гляну.
«делают программистов ленивее»
Да ерунда всё это, Саш. Размер исполнимого файла программы, написанной на языке высокого уровня, довольно таки слабо зависит от красоты алгоритмов, сочинённых программистом. Среда разработки переводит текст программы в машинный код по только ей известным правилам. Поэтому претензии предъявлять надо не к разработчикам, а к инструментарию, которым они пользуются. И ещё к возросшему разрешению экранов, на которых графические элементы 16х16 пикселей уже не смотрятся, а это в свою очередь ведёт к разбуханию несжимаемых ресурсов программы.
.kkrieger 3D-шутер, впихнутый в один-единственный исполняемый файл размером аж в 96 килобайт.
Да, это не полноценная игра, а всего лишь бета-версия. Да, она состоит из одного уровня и имеет немало недостатков.
Но это отличный показатель того, что могут сделать разработчики, если захотят!
Это демонстрация возможностей, вещь в себе.
Такие вау технодемки были всегда и во все времена.
При попытке масштабировать их на полноценную игру, придется или все переписывать, или стоимость и трудоемкость проекта взлетит в небеса.
Вы купите одну и туже игру размером 96Кб за 1000$ или 900Мб за 50$. Готовы переплатить за оптимизацию?
«Да, это не полноценная игра, а всего лишь бета-версия»
… таковой и останется. С 2002 года товарищи смогли создать один уровень с генерируемыми на ходу примитивными объектами типа колонн и ступенек, получили пару премий, да и притомились.
Даже Wolf3D интереснее выглядит и играется, чем эта технодемка.
К сожалению есть «ушлые» программисты и «тупые» коммерсанты. Нанимают его для разработки приложения (с сохранением авторских прав). После нескольких проблем он «благополучно» увольняется, и на его место приходит более ответственный программист, и пытается всё это исправить. Но к сожалению выкупить авторские права коммерсант не позволяет, и он вынужденно «толстеет» приложение, чтобы хоть что-то исправить. А как правило, таких приложений много, и у программиста приходит уныние (ему уже на всё наплевать!!).
Вспоминается строчка из песни Noize MC: «Эй коммерс гони бабло!! Не лезь в мои дела!!».
Так, да немного не так. Да, действительно, «Задачи, на реализацию которых лет 10-15 ушел бы месяц разработки, сейчас делаются за полдня. При этом считаются простыми.» Благодаря фреймворкам. А почему появились фреймворки? Потому что квалифицированных гениев-программистов не хватало, понадобилось, чтобы программировать смогли студенты, не заботясь о выделении-освобождении памяти. Дальше — больше, студентов стало не хватать, понадобилось, чтобы программирование освоили домохозяйки и дети. Появилась такая штука как фриланс, чтобы программист работал больше, некоторые пашут по 12 часов в день без выходных, при этом пишут лютый говнокод. Да, неплохо зарабатывают. Почему? Да потому, что программистов по-прежнему люто не хватает, говнокод отлично продаётся. Когда (если) программистов будет избыток, тогда профессия обесценится, и востребованными окажутся лишь квалифицированные гении. Вот тогда и качество кода начнёт цениться.
использование хорошего кода из фреймворка как бы хорошо, и велосипед не делать свой, только вот тянет за собой в сборку весь модуль, а что?, не трудно ведь дописать в dependency пару строчек.
а надёргать сейчас нужных классов из пакета тоже не надежный способ, мало ли в какой ситуации еще какой то класс понадобится во время работы кода.
вот и растет сборка как на дрожах 🙁 и только централизованые API тут могут хотя бы клоны фрейворуков с устройства убрать. Но программисты не сдаются и у каждого свои идеи какой фрейворк и какой версии надо и ненадо использовать.
Вот-вот. А всё почему? Потому, что программистов не хватает, и заказчику, по большому счёту, наплевать, сколько будет занимать сборка, ему вчера нужно было, чтобы всё работало. Ну хоть как-то, хоть половина функций. Поэтому если программист хоть что-то может, его берут. Если при этом он тащит в проект новый фреймворк — пофигу, работу надо было сдать ещё вчера.
использование хорошего кода из фреймворка как бы хорошо, и велосипед не делать свой, только вот тянет за собой в сборку весь модуль, а что?, не трудно ведь дописать в dependency пару строчек.
а надёргать сейчас нужных классов из пакета тоже не надежный способ, мало ли в какой ситуации еще какой то класс понадобится во время работы кода.
вот и растет сборка как на дрожах 🙁 и только централизованые API тут могут хотя бы клоны фрейворуков с устройства убрать. Но программисты не сдаются и у каждого свои идеи какой фрейворк и какой версии надо и ненадо использовать.
Ну вывод ясен, чаще покупать более мощное железо
Стиллавин?
Примеры раздувания софта, думаю все прекрасно знают и из прошлых времен — Nero, ACDSee. Куда быстрее программисткой лени, софт губят хотелки маркетолухов — еще, еще, быстрей, быстрей.
и то и другое…
Соглашусь с тем, что сейчас ПО пишут абы-как. Часто с этим сталкиваюсь по работе.
А вот с чем не соглашусь!
Вы, Александр, просто не в теме мяса на гриле, не более того. Это очень удобно, когда необходимо, например, коптить сразу 2/3/4 куска мяса разной толщины или вообще разное мясо.
Видать Вы ни разу не были на кухне хорошего мясного ресторана. Да даже в молекуряке щупы нужны повсеместно.
С последним соглашусь, но только если действительно будут компонентно новые датчики.
Я понимаю, что статья про «толщину» ПО, но с точки зрения CES и щупов для мяса все давно ждут тонкие и гибкие датчики,а также крайне жаропрочные провода.
И если у вас большой угольный/газовый гриль, и вы собираетесь готовить сразу несколько блюд из разного мяса, то такой хаб очень выручает.
Еще раз, Александр, Вы просто не в теме.
И поверьте, Вы не сможете на глаз без щупа сделать идеальную прожарку толстого куска мяса.
Боюсь, что я на
глаззуб, не смогу отличить идеальную прожарку толстого куска. И да, если решите возразить, не путайте неидеальную, с некачественной. Между ними еще громадный диапазон хороших прожарок. Кмк, вполне доступных без щупа, рядовому хоум-повару.Думаю, что у автора посыл был другой. Если нужен идеальный стейк, то, безусловно, такой щуп упростит процесс… Но и без него можно прекрасно обойтись, если есть чувство блюда. Но если человек с мясом не умеет работать, то хоть 10 щупов и умный гриль — все равно подошва получится! )
Зачем на глаз, если степень прожакрки можно определить тактильно (лопаточкой потрогать) и на вес проверить (тоже меняется)? А вообще, ок, кому как.
Жалобы на раздутый софт — это только от тех, кто далек от разработки и не видел как все развивалось.
Задачи, на реализацию которых лет 10-15 ушел бы месяц разработки, сейчас делаются за полдня. При этом считаются простыми.
А за счет чего? За счет того, что за эти годы для разработчиков наделали кучу готовых решений (фрейворков, библиотек с кодом), которые помогают реализовать стандартные сценарии.
Но как всякие универсальные решения — они весьма объемны, чтобы охватить как можно больше случаев, где их можно использовать.
Отсюда и вывод — используешь одну функцию, а в приложение включаются еще 99, которые были в библиотеке, которую ты использовал.
Хотя современные компиляторы стараются выкинуть лишние, неиспользуемые функции, но софт часто превращен в клубок взаимосвязей (которые порой на момент компиляции программы неизвестны), то далеко не всегда это помогает.
И никто не будет оптимизировать программы — это очень дорого и трудозатратно. Ну будет программа занимать чуть меньше, а кто заметит? Часто вы смотрите столько занимает та или иная программа на диске? Вряд ли. Максимум только тогда, когда все место заканчиватется.
Тогда стирается очередной фильм с диска (из памяти телефона) — и, вуаля, проблема решена!
Я не говорю сейчас про специфический промышленный софт — там проблемы иного характера, а вовсе не с занимаемым на диске местом.
Все верно — цепочки зависимости. Но это просто инструмент. И как любой инструмент, может быть направлен на пользу и во вред. Одно дело, если программист выбрал вдумчиво библиотеку под целый класс задач своей программы и вдвое уменьшил трудозатраты на появление новой мажорной версии, и совсем другое, если вдвое увеличил кодовую базу проекта и потребление им ресурсов, ради малозаметной минорной фичи.
За эти годы, именно что, наделали кучу готовых решений. Как тяжеловесных полноценных, так и легковесных микро-помощников. Отсюда вывод, если программист использовал такую библиотеку, что 99% ее функций оказались невостребованными, то он как минимум редиска.
Простота разработки это только одна из причин раздутия софта, причем не самая главная. И жалобы на раздутый софт вполне оправданы. Даже программисты вряд ли с пониманием относятся к занимающим 500Мб оперативки обычному месседжеру, по имени Сукайп.
«а кто заметит»
я замечу))) раньше «аська на яве занимала в зависимости от вида приложения от 64 до 150 килобайт и работала при этом замечательно (в режиме чата имеется ввиду), сейчас со старта 73 мегабайта… согласен что добавились голосовые и видеозвонки, прикольные эмодзи, передача файлов и т.д, но неужели это потребовало ТАКОГО раздутия? И это еще одна из самых что ни на есть компактных и стабильных програм…
А приложение ВК в 245 Мб без кэша?))) (с кэшем было около 600 Мб) Что там такое есть, чтобы занимать столько памяти?!!! Неужели просмотр ленты, чатики должны занимать столько места?)))
Я не спец и вполне может быть что сейчас абсолютную чушь сморожу (поправьте меня если что, а не какахами кидайтесь), но мне кажется, что в больших программах пора делать отдельные функции отдельными же модулями, которые нужно устанавливать дополнительно при необходимости. Ну вот например тот же ВК, ну не пользуюсь я там ничем кроме просмотра ленты и сообщений, можно же мне оставить только эти функции, причем воспроизведение видео перекинуть на один из видеоплееров телефона, аудио на встроенный плеер телефона, а остальные функции просто удалить (музыку из вк не слушаю, платежи не кидаю, смайлики не нужны, трансляции, игры, подкасты и т.д. все не нужно)?
Приложения с аддонами существуют. Но предположу, что этому мешает сам механизм их доставки пользователей. Представьте, к нынешнему зверинцу gPlay добавится еще столько же. Крупных программ может не много, но к каждой понадобится 3-5-10 аддонов.
Скорее выход в другом. Многие сервисы обзаводятся PWA или как минимум, неплохой мобильной версией. Просто пользоваться в браузере, если запросы не столь велики.
а вы сравните браузер Хром который летал на Samsung Galaxy S3 в 2012 году и того монстра, в которого он наобновлялся сейчас. Много вы в нём насидите в ВК на 1ГБ оперативки в телефоне?))
Разработчик что-то решает только в том случае, когда он пишет софт в одиночку. В случае команды всегда есть заказчик (для продуктовой разработки — product owner). Именно он решает, что и как будет сделано. Разработчик может только предоставить расклады (по срокам, качеству, рискам и т.д.), но права принятия решения у него чаще всего просто нет.
Для коммерческого (или любого заказного) приложения все упирается в деньги. Внутренний некоммерческий продукт может «пилиться» совсем по другим правилам. Можно до бесконечности улучшать и оптимизировать приложение. Но там есть и обратная сторона: если есть баги, не факт, что их будут оперативно исправлять.
Народ их не разделяет. Разработчик — тот кто создал софт. Будь это один программист или целая команда, в которой на одного программера приходится десяток менеджеров, включая заказчика, это все равно Разработчик.
Одобряю. Можно было бы даже добавить градуса и сделать что-то в духе «J’Accuse… !»
Ответ на все вопросы простой и очевидный: БАБЛО
Пока железо дешевле людей — так будет всегда.
Создание оптимизированного приложение требует денег, а, главное — времени. Никто не будет ждать годы, пока вы разродитесь с вашим, пусть даже идеально вылизанным и оптимизированным приложением, когда уже есть конкуренты, пусть и кривоватые, но они УЖЕ работают, и стоят дешевле.
Не надо ничего оптимизировать, просто не портьте что есть. Большинство претензии не к новому софту, а к раздуванию существующего, за счет внедрения вторичных фич.
Постоянно обновлял Foxit Reader и где-то полгода назад заметил, как-то тяжеловато он ворочается. Постепенно откатываюсь назад до версии 2013 года, размер меньше втрое, просто летает, ущерба функциональности не замечаю. Ну, думаю, это я такой нетребовательный. Предлагаю еще нескольким людям, результат аналогичный. Не исключаю что новые функции есть, как и то, что кому-то они все-таки надо, но не на два же таких дистрибутива, да чтобы это осталось незаметным остальной массе?
Ответ тот же: БАБЛО. Ну и плюс еще макетолухи.
Бизнес не платит за «не портьте что есть», бизнес платит за новые фичи.
Ответил в главной ветке. Бизнес платит за новые фичи везде, однако претензии предъявляются единицам. Значит не в бизнесе причина.
И да, Foxit Reader бесплатное приложение.
Ну, если верить статье, то претензии таки почти ко всем, ни разу не к единицам.
> … статья Джона Нотона (The Guardian), в которой автор все расставляет по полочкам.
И вот это вот абстрактное нытьё про «програмное обеспечение похоже на газ» называется «расставляет всё по полочкам»?
Лично мне было бы куда интереснее таки услышать конкретные рецепты: почему деинсталяция приложения не приводит к полному возврату места? К примеру, есть телефон с 32 гб, после какого-то времени это пространство забивается и надо бы место освободить, но даже если деинсталировать все игры, что там поставлены, то вернётся только часть. Где ответ на это?
Читаю комменты и знаете что? Все оправдания «программист не имеет контроля», «важно здесь и сейчас», «железо дешевле людей», «написаны куча библиотек» и прочее, просто не имеют смысла. Потому что все всё понимают и учитывают. А из всего многообразия софта, претензии предъявляются к очень небольшому количеству, которое явно выходит за все рамки. Рамки, необъяснимые никакой логикой, ибо остальные 95+% как-то ведь в них умудряются оставаться. Хотя все эти явления — библиотеки, контроль, сроки, бабки, — им также применимы.
Года через три этот текст будут читать на устройстве с одним ядром, в сотни раз более производительным, чем современные многоядерные, с хранилищем в сотни петабайт, и при этом посмеиваться.
Главное, что бы оно не подлагивало на скрроле этого самого текста…