а в генту сейчас можно поставить вообще всю остальную систему из бинарных пакетов за несколько минут (при наличии шустрого интернета)? Арч тем и хорош, что он бинарный — но свежий, и свои пакеты собирать легко. Поэтому можно экспериментировать с чем хочешь, а с чем не хочешь — ставить из репо готовое. Много-много лет назад я именно поэтому его и выбрал.
Меняются конечно. Обновляешь и нексткалуд на такой, который умеет в более новый php ;) Все-таки обычно тут не жесткая связь по версиям, и ситуаций «работает на 7.1, но не работает на 7.3» я даже и не вспомню уже (в публичном софте, в самописном внутри компании — другой разговор).
Arch вроде есть на неё. Малинку никогда не рассматривал в таком виде — до ковида собрать сервак на б/у xeon'e стоило достаточно недорого, чтобы не рассматривать малинку.
нажать кнопочку «Сделать бэкап» и кнопочку «Апгрейд», подождать и проверить как все рабоатет
оно с одной стороны так и есть, но с другой — все-таки сначала надо прочесть документацию. В целом, если не пропускать апдейты, но и не делать их в первую же минуту после релиза, то всё норм.
одна из самых больших проблем с СОХО серверами и как ее можно решить глобально?
rolling release дистрибутивы. У меня такой вот домашний сервер (плюс еще резервные) на Arch очень много лет, обновляюсь раз в 2-3 месяца. Последние лет 5 каких-то проблем при обновлении, которые бы не были описаны (в смысле описано что делать, чтобы ничего не сломалось) заранее в новостях на главной странице archlinux.org, не было.
и ездят себе дальше с родным двигателем, коробкой и тд.
если автомобиль внезапно заглохнет на дороге — скорее всего это не станет большой проблемой: съехал на обочину, вызвал эвакуатор. А вот у спец.техники требования сильно выше :)
какой запас накоплений (можно в месяцах жизни) вам достаточно иметь, чтобы позволить себе руководствоваться критериями нравится/не нравится.
А какое отношение запас накоплений имеет к этому? В целом на рынке немало предложений о работе, чтобы в разумный срок (от нескольких недель до нескольких месяцев) найти работу, которая понравится больше, чем текущая, которая перестала нравится. И уйти туда. Если вопрос о выборе новой профессии с нуля — тут сложнее, т.к. нужно выделять много времени на обучение, но это тоже решаемо (просто у каждого индивидуальное решение). Но, в любом случае, если такой пипец, как в последней истории про убер, то и без гроша в кармане терпеть такое не стоит.
Рискну предположить, что идея-то была о том, что недостаточно просто быть хорошим инженером, а еще и продавать себя тоже. Т.е. «быть, а не казаться» недостаточно, нужно «и быть и казаться». Но возможно это моя личная мысль, которую я попытался притянуть к тексту :D
Собственно, реформы в IT без аналогичных движений на административном уровне — странная затея и скорее всего бесполезная. Перейти не просто на Linux, а еще и процессы поменять, чтобы не пытаться legacy притащить в линукс, а пилить всё друг под друга — это выйгрышный ход. Но на него надо решится.
В любом нормальном техническом собеседовании то, что кандидат «немного знаком» с тем, на чем технари пишут, видно вообще сразу.
Но на техническом собеседовании могут про это и не спросить особо. Или взять, потому что понимают, что им не крутой питонист нужен, а как раз человек, который «если что — разберется». Да множество разных факторов, заранее неизвестных. Поэтому стратегия «откликайся на всё» вместе с «приукрашивай» и срабатывает — изначально охватываешь больше, а дальше сам же отсеиваешь (а где-то тебя отсеят).
Ну это ж другое ведомство. Опять же, у тех — палочная система, так еще и каждый отчетный период раскрываемость надо повышать. Так что возможно, что им не просто это известно — а даже всем взаимовыгодно получится.
Какое отношение эта фраза имеет к разговору выше? Окей, возможно вы меня не поняли, давайте я перефразирую. Вы говорите, что вам приходится писать k8s-операторы, чтобы не было проблем с деплоем приложений, состоящих из N контейнеров, связанных жестко друг с другом (т.е. которые нельзя деплоить в произвольном порядке). И далее называете такое — микросервисами. А я вам пытаюсь объяснить, что это — не микросервисная архитектура, это всё равно архитектура «монолит». Т.к. вся фишка микросервисов в том, что каждый из них имеет свой собственный релизный цикл, независящий от других. Захотел — обновил, захотел — перезапустил. Каждый микросервис сам поддерживает какую-то обратную совместимость с собственной прошлой версией через фиксацию соглашений, feature-флаги или как-то еще. Запускать свой монолит вы можете где угодно, хоть в k8s, но он от этого не перестаёт быть приложением, построенным по архитектурному принципу «монолит».
ну да. А что такое микросервисы? Это слабосвязанные сущности, их можно деплоить независимо. А если у вас зависимости — у вас монолит, просто разделенный на несколько приложений/контейнеров/etc, но монолит.
А какое отношение запас накоплений имеет к этому? В целом на рынке немало предложений о работе, чтобы в разумный срок (от нескольких недель до нескольких месяцев) найти работу, которая понравится больше, чем текущая, которая перестала нравится. И уйти туда. Если вопрос о выборе новой профессии с нуля — тут сложнее, т.к. нужно выделять много времени на обучение, но это тоже решаемо (просто у каждого индивидуальное решение). Но, в любом случае, если такой пипец, как в последней истории про убер, то и без гроша в кармане терпеть такое не стоит.
Но на техническом собеседовании могут про это и не спросить особо. Или взять, потому что понимают, что им не крутой питонист нужен, а как раз человек, который «если что — разберется». Да множество разных факторов, заранее неизвестных. Поэтому стратегия «откликайся на всё» вместе с «приукрашивай» и срабатывает — изначально охватываешь больше, а дальше сам же отсеиваешь (а где-то тебя отсеят).
Возможно я неправильно понял, объясните пожалуйста, что значит фраза
к которой в продолжение были упомянуты микросервисы?
Какое отношение эта фраза имеет к разговору выше? Окей, возможно вы меня не поняли, давайте я перефразирую. Вы говорите, что вам приходится писать k8s-операторы, чтобы не было проблем с деплоем приложений, состоящих из N контейнеров, связанных жестко друг с другом (т.е. которые нельзя деплоить в произвольном порядке). И далее называете такое — микросервисами. А я вам пытаюсь объяснить, что это — не микросервисная архитектура, это всё равно архитектура «монолит». Т.к. вся фишка микросервисов в том, что каждый из них имеет свой собственный релизный цикл, независящий от других. Захотел — обновил, захотел — перезапустил. Каждый микросервис сам поддерживает какую-то обратную совместимость с собственной прошлой версией через фиксацию соглашений, feature-флаги или как-то еще. Запускать свой монолит вы можете где угодно, хоть в k8s, но он от этого не перестаёт быть приложением, построенным по архитектурному принципу «монолит».
Ведь так ты заплатишь больше, у франча ж еще надо менеджеров окупить, их прибыль и т.п.