Comments 49
Как обычно в переводных статьях, простая мысль растянута на стену, нет СТЕНУ текста. Не понимаю
Притом что мысль стоит плюса и уж тем более его стоит труд переводчика
Но с приведением одного, другого примера становится понятнее. А с приведением десяти примеров уже значимой. А с приведением возможных бизнес рисков уже может привлечь внимание даже тех, кто может быть на что-то влияет.
внутренние объекты плоскости управления
OK, Google Translate, а теперь переведи это на русский. Например, как «внутренние объекты подсистемы управления».
Автор ставит Apple хилую троечку за совместимость, но тогда почему Linux он не поставил ноль или даже вообще отрицательную величину? Там-то даже на уровне libc вертикальную совместимость обеспечивать никто не желает. Про компоненты и говорить нечего — то у них systemd, то им X-сервер жить мешает и надо срочно всё на Wayland переписывать, то GTK несовместимо обновляется до тех пор, пока не задолбает всех разработчиков окончательно, и они не начнут шарахаться от него как от чумы…
Бекэнд-стек тоже не лучше. Это ж вполне штатная ситуация, когда вы обновляете какой-нибудь nginx, и тут вдруг перестаёт работать аплоад файлов, потому что ВНЕЗАПНО новой версией не поддерживается nginx-upload-module, и никакой вменяемой альтернативы конечно же не предусмотрено.
Вы сейчас серьёзно? Центос 5 сколько лет в строю? А 6? И кто-то говорит вам переписывать сервисы насильно, потому что отключаби сервис? Нет, просто нет обновлений. 5 цента может жить бесконечно со своими приложениями, пока не понадобится новое ядро из-за железа.
А при чем тут это?
Зачем это говно мамонта нужно? Софт в репах старый, обновлений безопасности не будет как поддержка кончится.
Централизованно разворачивать/обновлять приложение с зависимостями на сотнях центосей 5/6/7 просто ад.
Если Вы конкретно умудрились оставить версию 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 ориентируется на тех пользователей, которые готовы (и могут себе позволить) отказываться от груза прошлого во имя движения в будущееА можно поинтересоваться, зачем бизнесу это движение в будущее в головах программистов, которое ему никак не помогает (не приносит никакой прибыли), но оплачивать которое должен он?
Разработчики хотят развлекаться за чужой счет?
Если есть варианты, то имхо — стабильность важнее модернизма, если мы деньги зарабатываем, а не искусство творим.
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.
Не вижу проблемы, Вы серьезно хотите разрабатывать на железках старше 5 лет? Производительности хватает? Эффективность не страдает? Я не говорю про терминальные случаи набора текста в vim и сборке кода консольными тулингами
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 лет на современные. Наверное до этого она не работала в гос. компании.
Можно ли рядом положить на App Store версии 1.0 (поддержка версии iOS «n-1») и 1.1 (поддержка версии iOS «n») — этого я не знаю.
В мире Emacs (и во многих других областях, которые мы рассмотрим ниже) статус устаревших API в основном означает: «Вы действительно не должны использовать этот подход, потому что, хотя он и работает, он страдает от различных недостатков, которые мы перечислим здесь. Но, в конце концов, это ваш выбор».
В мире Google статус устаревшего продукта означает: «Мы нарушаем свои обязательства перед вами». (...) Им явно не нужны клиенты. Им нужны покупатели.
Ребята, вы же богатые. Мы, разработчики — нет.
Всё это выглядит как выпрашивание подаяния побольше, одновременно с попыткой зашеймить тех, кто подавать требуемые суммы не желает, с привлечением группы поддержки в виде распропагандированной общественности. "Вот GNU даёт нам бесплатный продукт и поддержку, а вы так не хотите, бяки!" — "Требуем раздачи хлеба и зрелищ!". То ли навязывание коммунизма, то ли развращённость халявой.
GCP продается как облако в соусе снижения доходов на обслуживание. Но гугл Google, на самом деле это так, довольно часто удаляет возможность использовать старые API. А это ведет к абсолютно противоположному — увелечению затрат на разработку (переписывание).
Я давно не работал с gcp, но в, данном конкреном случае, причина может быть и уважительной, поскольку GCP очень долго не то, что не мигрировала, а просто даже не имела поддержки python3, а вторая версия уже не поддерживается сообществом.
Не понимаю проблемы. В нашем мире никто никому ничего не должен, если не сказано обратное. У Гугл Клауда четкий релизный план и четкие обязательства по поддержке версий своих апи? Можно, пожалуйста, четкий ответ да/нет. В условиях быстро меняющейся действительности — даже поддержка апи стабильно в год — уже хорошо. А в пять — молодцы. Только за это заплатит сам клиент. Как в истории с redhat и VMware. Не вопрос. Стоимость поддержки никуда не девается.
Я уж не говорю о том, что софт в целом эродирует со временем. И это естественный процесс. Очень сложно запустить софтину ХХ летней давности и получить работоспособный результат. Вероятно Вы можете найти контрпримеры, но это будет либо читерство (из серии «давайте запустим виртуальную машину» — а почему бы и нет?), либо какие-то вырожденные случаи
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 битные программы (хотя и поделом)
и пр. пр.
Вы приводите немного некорректные сравнения.
О времени перехода на новую версию influx или docker решение принимает сама компания. Может если оно "работает", то и переходить не будут.
О решении замены API принимает решение поставщик в одномоментном порядке и шансов отказатся у вас нет. Просто вот через полгода сервиса, который вы пользуетесь больше не будет или он будет работать кардинально по другому API.
Представьте, если бы у amazon s3 апи обратно несоместимо менялся каждые 2 года.
Может если оно "работает", то и переходить не будут.
да, но это означает, что система уже не на поддержке (вероятно), либо ломаются какие-то интеграции (системы же не в вакууме существуют), либо что-то еще.
Вы приводите немного некорректные сравнения.
Вы правы — в случае он-премис решения ЕСТЬ ШАНС, что Вы сами можете разобраться и что-то придумать для митигации проблем, в случае с облаком — Вы — не хозяин, а гость. И владелец сервиса диктует Вам условия.
Правильно спроектированная и разработанная система не требует постоянной доработки, за исключением исправления багов. А если в вашем мире API меняются каждый год, мне вас (или ваших заказчиков, если вы разработчик этого API) жаль. У меня есть пару микропроектов, которые уже 5 лет крутятся. Переписывание их на новое API == написанию проекта с нуля. Но они же работают и выполняют свою задачу. WTF?
Кстати, конкретно эти два проекта, подняты на gcp и во время их написания, python3 уже был, но мне пришлось их писать на двойке, поскольку гугл дохрена медлил с третьей версией. Я тут вижу только проблемы гугла как облака.
В условиях быстро меняющейся действительности — даже поддержка апи стабильно в год — уже хорошо. А в пять — молодцы. Только за это заплатит сам клиент. Как в истории с redhat и VMware. Не вопрос. Стоимость поддержки никуда не девается.Это — демагогия. Все платят гуглу. На самом деле, стоимость проекта низкой сложности и нагрузки, выходит приблизительно одинакова на gcp/azure/aws, порядка 50 — 200 долларов. И оператор облака, так же как и вы экономит на поддержке, поскольку «массовость» и «типичность проблем», и я уже не говорю про балансировку нагрузки и перезаказ инстансов.
Убивает, убивает и всё никак убить не может.
И не только гугл клауд.
И не только отказ от обратной совместимости.
Может у Oracle Cloud по другому будет.
Ведение блога требует времени, энергии и креатива, которые я мог бы использовать с пользой: мои книги, музыка, моя игра и так далее.Хм, а у меня представление о пользе прямо противоположное. Потому что во втором случае польза только для одного человека, а в первом — для десятков, сотен, а может и тысяч людей.
Дорогой Google Cloud, отказ от обратной совместимости тебя убивает