Comments 48

Как обычно в переводных статьях, простая мысль растянута на стену, нет СТЕНУ текста. Не понимаю
Притом что мысль стоит плюса и уж тем более его стоит труд переводчика

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

Но с приведением одного, другого примера становится понятнее. А с приведением десяти примеров уже значимой. А с приведением возможных бизнес рисков уже может привлечь внимание даже тех, кто может быть на что-то влияет.

Угу, а с приведением 11 примеров это уже — внезапно — книга! Такая типичная бизнес литература, наверченнаясю вокруг по-прежнему одной мысли

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

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

OK, Google Translate, а теперь переведи это на русский. Например, как «внутренние объекты подсистемы управления».
Увы, в мире OpenSource с вертикальной совместимостью всё намного хуже, чем в проприетарных продуктах. Проприетарщики хотя бы иногда вынуждены думать о клиентах, если не хотят однажды вылететь с рынка. А вот мир OpenSource — это тотальное наплевательство. Всем плевать на всех, никто никому ничем не обязан.
Автор ставит Apple хилую троечку за совместимость, но тогда почему Linux он не поставил ноль или даже вообще отрицательную величину? Там-то даже на уровне libc вертикальную совместимость обеспечивать никто не желает. Про компоненты и говорить нечего — то у них systemd, то им X-сервер жить мешает и надо срочно всё на Wayland переписывать, то GTK несовместимо обновляется до тех пор, пока не задолбает всех разработчиков окончательно, и они не начнут шарахаться от него как от чумы…
Бекэнд-стек тоже не лучше. Это ж вполне штатная ситуация, когда вы обновляете какой-нибудь nginx, и тут вдруг перестаёт работать аплоад файлов, потому что ВНЕЗАПНО новой версией не поддерживается nginx-upload-module, и никакой вменяемой альтернативы конечно же не предусмотрено.

Вы сейчас серьёзно? Центос 5 сколько лет в строю? А 6? И кто-то говорит вам переписывать сервисы насильно, потому что отключаби сервис? Нет, просто нет обновлений. 5 цента может жить бесконечно со своими приложениями, пока не понадобится новое ядро из-за железа.

А при чем тут это?
Зачем это говно мамонта нужно? Софт в репах старый, обновлений безопасности не будет как поддержка кончится.
Централизованно разворачивать/обновлять приложение с зависимостями на сотнях центосей 5/6/7 просто ад.

Насколько я понимаю, в октябре 2016 вышла FreeBSD 11.0, в июле 2017 — 11.1.
Если Вы конкретно умудрились оставить версию 11.0 где-то в октябре 2017 года, то могли бы получить отказ от стандартного репозитория на установку почти любого софта?
Смысл проблемы в том, что поддержка конкретно версии 11.0 была не очень долгой.

Отличная статья. Написал всего 10 строчек питон кода для гцп, но собрал по пути полное несоответствие официальной документации и реальности. И да, админские права на бигквери и сторадж ради экспорта таблиц — рука лицо.

Что интересно, то о чём чувак пишет — одна из основных причин популярности «обожаемого» в этом сообществе Битрикса. И она же его больное место.
С одной стороны — монструозная до-PSR-ная архитектура, в которой можно разглядеть «культурные слои» нескольких поколений разработки разной степени пряморукости начиная от «каменного века» (вся логика одним «потоком сознания») до «промышленной революции» (абстракции, фабрики, рефлексия).
С другой, каждый новый слой не ломал предыдущего, поэтому модули и шаблоны, написанные даже 10 лет назад всё ещё работоспособны на актуальной версии ядра, и разработчики могут быть уверены, что если делать всё по инструкции, то проекты после сдачи не перейдут на вечное сопровождение и переписывание каждые 2 года.
И это уже скорее обратный пример, когда НУЖНО отказаться от обратной совместимости и запустить новое поколение движка, без тонн культурного наследия, но «политической воли» всё никак не наберётся.

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


Автор правильно сказал, что это разные философии — перекладывать расходы на обратную совместимость на плечи пользователя (Google Cloud) или тащить самим (Emacs/Android). Хочешь быть стабильным — используй Emacs, хочешь сделать что-то быстро — используй Vim (или Notepad++). Если я выбираю в 2020-м инструмент для редактирования текстов, то зачем мне монстры с 50-летней историей и шлейфом всех неудачных решений за это время?


Google ориентируется на тех пользователей, которые готовы (и могут себе позволить) отказываться от груза прошлого во имя движения в будущее. Это просто вопрос эффективности (не факт, что у Google это получается, но они работают над этим).


IMHO, автор не может смириться, что его накопленные за всё время наработки становятся бесполезными в новых реалиях. Он, как и Google, хочет переложить свои проблемы на чьи-то другие плечи. Это нормально, мы все так делаем.


P.S.
Осилил только половину статьи, переводчику — респект. Замечательная выдержка. Как тут уже сказали в комментах выше, одну мысль можно было бы выразить и короче.

Они не становятся бесполезными(по крайней мере не всегда), но нужно раз за разом переписывать код, чтобы он оставался работоспособным. Мартышкин труд.
Google ориентируется на тех пользователей, которые готовы (и могут себе позволить) отказываться от груза прошлого во имя движения в будущее
А можно поинтересоваться, зачем бизнесу это движение в будущее в головах программистов, которое ему никак не помогает (не приносит никакой прибыли), но оплачивать которое должен он?

Разработчики хотят развлекаться за чужой счет?
Подавляющее количество опенсорс софта вообще не выжило бы в условиях постоянного изменения платформы. И так множество довольно полезного опенсорса работает благодаря парочке энтузиастов, и если бы им было необходимо переписывать 10% проекта каждый год просто чтобы он запускался при очередном обновлении, все бы забили.
Имеет ли смысл вкладываться в разработку на инструментарии, который в любой момент может тебя подставить, вместо того, что бы использовать практичный инструмент?

Если есть варианты, то имхо — стабильность важнее модернизма, если мы деньги зарабатываем, а не искусство творим.
Насчёт обратной совместимости в инструментах Apple Я бы поспорил. Apple регулярно требует от разработчиков поддержки последний версий iOS угрожая не пропускать такие программы в App Store. А про их новый язык программирования Swift, который обновляет major версию каждый год:

Module stability (being able to compile against binaries compiled with a different Swift version) is also only coming in Swift 5.1, which means that you still can't link against a library (system or third party) compiled with Swift 5.0 or earlier. So replacing the Swift version in current releases with 5.1 could be a big, breaking change.
А как же не припомнить «чтобы залить приложение, его нужно скомпилировать в последнем XCode, последний XCode ставится только на последнюю MacOS, а последняя MacOS ставится только на железки не старше 5 лет»? (за точность цифр не уверен, но общий принцип такой).

Не вижу проблемы, Вы серьезно хотите разрабатывать на железках старше 5 лет? Производительности хватает? Эффективность не страдает? Я не говорю про терминальные случаи набора текста в vim и сборке кода консольными тулингами

Я на Вики нашел такое («was announced… on June 22, 2020»):
https://en.wikipedia.org/wiki/MacOS_Big_Sur
Unlike macOS Catalina, which supported every standard configuration Mac that Mojave supported, Big Sur drops support for various Macs released in 2012 and 2013. Big Sur runs on the following Macs:

MacBook Air: Mid 2013 or newer
MacBook Pro: Late 2013 or newer

Mac Pro: Late 2013 or newer

Ну, сейчас как бы 2020 год. 7 лет поддержки старых конфигураций — вроде как норм, не?

Я и говорю, что на некие девайсы старше 5 лет поддержка точно есть.
И да, слышал я от одной женщины идею о том, что компы нужно менять раз в 5 лет на современные. Наверное до этого она не работала в гос. компании.

Вообще-то она права. Срок гарантии закончилось, срок эксплуатации вышел, оборудование самортизировано в нули- пора покупать новое

Сроки гарантии??? Мы выдаем Pen. E2140 или вообще Pen D/Pen 4 в 90% случаев. Хотя кому-то таки попадается новое.
Хотя где-то видел новое железо, моноблок на i3-4170.

Отличная "идея" — сидеть на старом железе, наверное, еще и с неподдерживаемой операционной системой вроде Windows XP? Видел я таких. Там разве что ПеКа можно в качестве рдп терминала использовать (и то — с нюансами)

Big Sur на сегодняшний день еще не вышел в релиз официально и актуальной версией остаётся macOS Catalina, которую можно поставить на девайсы выпуска аж середины 2012 года, то есть ровно 8 лет поддержка была.
Да, «неправда», там нет строгой привязки ко времени выхода, а только к «поколения». Но вам от этого легче? Ведь обязанность апгрейдить железо исключительно ради права аплоада в стор от этого никуда не уходит.
Если у них в текущих продажах девайсы на«последней версии iOS» составляют не менее 50% — тогда логично им требовать. То есть Apple выгодно, чтобы юзеры на купленной свежей железке могли запустить этот софт.
Можно ли рядом положить на App Store версии 1.0 (поддержка версии iOS «n-1») и 1.1 (поддержка версии iOS «n») — этого я не знаю.
В мире Emacs (и во многих других областях, которые мы рассмотрим ниже) статус устаревших API в основном означает: «Вы действительно не должны использовать этот подход, потому что, хотя он и работает, он страдает от различных недостатков, которые мы перечислим здесь. Но, в конце концов, это ваш выбор».

В мире Google статус устаревшего продукта означает: «Мы нарушаем свои обязательства перед вами». (...) Им явно не нужны клиенты. Им нужны покупатели.

Ребята, вы же богатые. Мы, разработчики — нет.

Всё это выглядит как выпрашивание подаяния побольше, одновременно с попыткой зашеймить тех, кто подавать требуемые суммы не желает, с привлечением группы поддержки в виде распропагандированной общественности. "Вот GNU даёт нам бесплатный продукт и поддержку, а вы так не хотите, бяки!" — "Требуем раздачи хлеба и зрелищ!". То ли навязывание коммунизма, то ли развращённость халявой.
Суть же в другом!
GCP продается как облако в соусе снижения доходов на обслуживание. Но гугл Google, на самом деле это так, довольно часто удаляет возможность использовать старые API. А это ведет к абсолютно противоположному — увелечению затрат на разработку (переписывание).
Я давно не работал с gcp, но в, данном конкреном случае, причина может быть и уважительной, поскольку GCP очень долго не то, что не мигрировала, а просто даже не имела поддержки python3, а вторая версия уже не поддерживается сообществом.

Не понимаю проблемы. В нашем мире никто никому ничего не должен, если не сказано обратное. У Гугл Клауда четкий релизный план и четкие обязательства по поддержке версий своих апи? Можно, пожалуйста, четкий ответ да/нет. В условиях быстро меняющейся действительности — даже поддержка апи стабильно в год — уже хорошо. А в пять — молодцы. Только за это заплатит сам клиент. Как в истории с redhat и VMware. Не вопрос. Стоимость поддержки никуда не девается.
Я уж не говорю о том, что софт в целом эродирует со временем. И это естественный процесс. Очень сложно запустить софтину ХХ летней давности и получить работоспособный результат. Вероятно Вы можете найти контрпримеры, но это будет либо читерство (из серии «давайте запустим виртуальную машину» — а почему бы и нет?), либо какие-то вырожденные случаи

Герои 3 (SoD) я запускал на Win 7 на ноуте 2013 года (проц конкретно представлен
Q3'13, а линейка 22 нм — Q2'12). Да, я её не установил, а скопировал со старого компа (что начинался как Win 2k) + применил лежащий там reg-файл.
На самом деле не так, но этот метод я проверил на следующем поколении (Core i5 4670).
На железе 2020 года покупки я проверял только WoG, но это Ryzen 5 на 14nm. Использовал ли при этом «другой exe-файл» — не помню. К сожалению, на Десятке иногда вылетает.

Норм история ) Спасибо. Но с Quake, например, была прикольная история (не софтовая, не про API), когда fps становился выше определенной границы, то менялась сама физика игры. И игроки с мощными компами получали определенное преимущество. А за запуск Heroes 3 надо сказать спасибо и разработчикам HoMM3, и разработчикам Windows, которые реально напилили очень много слоев совместимости (плохо или хорошо ли это — отдельный вопрос). Скорее всего такое уже не повторится — даже игрушки сейчас становятся сетевыми и по сути одноразовыми.

В нашем мире никто никому ничего не должен, если не сказано обратное.

Ну так и в статье не написано "GKE ты должен поддерживать обратную совместивость", в статье написано, что вот без обратной совместимости серьезные клиенты не лезут в GKE, а те, что лезут, испытывают вот такие страдания и профита не испытывают.


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

так весь айти постоянно требует доработок. Одним человеком больше. Одним меньше. Незаметно


Пример — influx, которые прокинули всех своих клиентов, просто при переходе на следующий мажор не обеспечив обратную совместимость. А теперь попробуй пару сотен гигов таймсириз сконвертировать.
Потом докер — который вообще не про обратную совместимость (ага, попробуй образы, собранные, скажем 19.03, запустить на 1.10)
mac os = которая выпилила 32 битные программы (хотя и поделом)
и пр. пр.

Одно дело доработки, когда у тебя действительно серьёзно поехали требования/накопились радикальные изменения (условно говоря переезжаем с 32-битных железок на 64-битные и потому что это даёт реальные преимущества, поддержку большего объёма памяти, например). Другое дело, когда у тебя программисты решили, что нужно сделать «правильно», а по сути просто пилят новое, потому что могут и потому что система мотивации такая (без релизов и срочного «устаревания» старого — не будет повышений). Вот второе — как раз случай Гугла. С одной стороны — могут себе позволить, «не нравится — не пользуйся». С другой стороны — автор справедливо замечает, что очень сложно заметить молчаливое большинство, которое просто выбрало не пользоваться твоими услугами из-за такой политики, а ты просто не можешь понять — почему же у меня не растёт доля рынка, а скорее даже падает?

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

Вы приводите немного некорректные сравнения.


О времени перехода на новую версию influx или docker решение принимает сама компания. Может если оно "работает", то и переходить не будут.


О решении замены API принимает решение поставщик в одномоментном порядке и шансов отказатся у вас нет. Просто вот через полгода сервиса, который вы пользуетесь больше не будет или он будет работать кардинально по другому API.


Представьте, если бы у amazon s3 апи обратно несоместимо менялся каждые 2 года.

Может если оно "работает", то и переходить не будут.

да, но это означает, что система уже не на поддержке (вероятно), либо ломаются какие-то интеграции (системы же не в вакууме существуют), либо что-то еще.


Вы приводите немного некорректные сравнения.

Вы правы — в случае он-премис решения ЕСТЬ ШАНС, что Вы сами можете разобраться и что-то придумать для митигации проблем, в случае с облаком — Вы — не хозяин, а гость. И владелец сервиса диктует Вам условия.

Вы меня простите, но вы как-то неправильно смотрите на разработку.
Правильно спроектированная и разработанная система не требует постоянной доработки, за исключением исправления багов. А если в вашем мире API меняются каждый год, мне вас (или ваших заказчиков, если вы разработчик этого API) жаль. У меня есть пару микропроектов, которые уже 5 лет крутятся. Переписывание их на новое API == написанию проекта с нуля. Но они же работают и выполняют свою задачу. WTF?
Кстати, конкретно эти два проекта, подняты на gcp и во время их написания, python3 уже был, но мне пришлось их писать на двойке, поскольку гугл дохрена медлил с третьей версией. Я тут вижу только проблемы гугла как облака.
В условиях быстро меняющейся действительности — даже поддержка апи стабильно в год — уже хорошо. А в пять — молодцы. Только за это заплатит сам клиент. Как в истории с redhat и VMware. Не вопрос. Стоимость поддержки никуда не девается.
Это — демагогия. Все платят гуглу. На самом деле, стоимость проекта низкой сложности и нагрузки, выходит приблизительно одинакова на gcp/azure/aws, порядка 50 — 200 долларов. И оператор облака, так же как и вы экономит на поддержке, поскольку «массовость» и «типичность проблем», и я уже не говорю про балансировку нагрузки и перезаказ инстансов.
Слишком много букв для платформы про которую я думал что уже закылась.

Убивает, убивает и всё никак убить не может.
И не только гугл клауд.
И не только отказ от обратной совместимости.

Microsoft тоже забило на Azure Container Service. Никаких LTS и SLA для модели pay for what you use when you use it никто не обещал )
Может у Oracle Cloud по другому будет.
Only those users with full accounts are able to leave comments. Log in, please.