Как предлагается финансировать разработку Firefox?
то ведь работать придется
напомню, что Mozilla поддерживают один из трёх сколь-либо массовых браузерных движков. развал Mozilla приведёт к тому, что останутся только WebKit и Blink. Это почти монополизация. Точно хочется такой результат получить?
И с каких это пор программистов вообще стали допускать к выбору технологий?
Соболезную. В моих кругах везде разработчики влияли на выбор технического стека. Не всегда коллектив коллег соглашался с доводами конкретного инициатора, но нередко инициаторы могли убедить коллектив в целесообразности модификации стека, используя разумные аргументы и демонстрации.
так крепче, что Telegram в списке организаторов распространения информации, которые обязуются делиться с органами? https://habr.com/ru/articles/404985/
сложно представить, чтобы ядро системы, которое тесно взаимодействует с аппаратной частью, имела такой высокий уровень абстракции, чтобы не обращаться к памяти напрямую, и использовать безопасные языки.
В том числе этим руководствуются люди вроде Танненбаума, продвигающие концепцию микроядра.
Линус с самого начала был недоволен оным и спорил с Танненбаумом. В общем-то, весь Linux начался как пара доволнений к микроядерной Minix, и потом уже постепенно вырос в отдельную ОС.
всего-то 30m+ строк, которые написаны за 30+ лет тысячами разработчиков. строк, которые работают на экзотическом железе, которое сложно тестировать. строк, от корректноти которых зависит почти весь мир.
Так работает экономика. Можно сэкономить часы разработки за счёт ресурсов пользовательских устройств. Если у среднего (а лучше у 80%-90%) покупателя в Стиме подходят требования, то стоит ли тратиться на дополнительную оптимизацию?
Тут ещё как с побочными эффектами и сроком годости -- лучше выкрутить значения в свою пользу, чтобы избежать разоочарований/претензий.
Это широко известная в среде облачных инженеров история. Только вот эти стартаперы совсем не опытные, о чём они сами пишут в изначальном посте. И рекомендую почитать, что дальше произошло для полноты картины. GCP простил им этот долг.
Ну и ситуаций подобных описанной у меня не происходило, покуда я всегда держу в голове такой аспект и обвешиваю всё автобюджетированием, детекторами аномалий, ограничениями масштабирования и другими стандартными инструментами укрощения серверлесса.
А что, если я скажу, что я "воспользовался серверлессом" и выбил грантов на $700k "за красивые глаза" для стартапа от трёх крупнейших платформ, и все эти гранты удалось утилизировать на благо развития продуктов? Что у меня везде масштабирование с нуля настроено и утилизация ресурсов недостижимая для тех, кто сидит на своём железе? Не говоря уже про эластичность, гибкость и простоту прохождения любого рода аудитов и compliance процессов.
В итоге, конечно, рыночек рассудит -- я только за. Особенно, если посмотреть на числа и тенденции рынка. Что растёт и с какой скоростью. Какие компании куда миграции чаще делают.
"забыли" что этот админ/девопс уже есть, поскольку раздеплоить типичную нынешнюю развесистую лапшу
Чем больше инфраструктурного управления берёт на себя команда, тем больше придётся трудозатрат вкладывать для достижения заданных показателей надёжности и скорости разработки. И лапша самоуправляемого кубернетеса с двумя десятками компонент будет куда больше, чем описание аналогичных облачных ресурсов в терраформе.
Как человек, который делает и то и другое, я, конечно, буду всегда рекомендовать начинать с максимально высокоуровневых абстракций и брать максимально serverless зависимости, насколько это возможно для заданного проекта и опускаться на нижние уровни абстракции только имея конкретные соображения и расчёты.
Проблема в том, что мало кто умеет хорошо расчитывать непрямые расходы на инфраструктуру. Вот как раз в виде дополнительных человекочасов, рисков и замедления цикла разработки. Отсюда часто возникают мысли, что публичные облака -- это дорого, когда только вершина айсберга видна.
Могу лишь ещё раз повторить широко известный факт: бакеты находятся в глобальном пространстве имён. То есть, два клиента AWS не могут создать бакет с одинаковым именем. Поэтому, чтобы не налетать на конфликты, все сколь-либо опытные известные мне люди работают с префиксами. Часто вида "<company_name>-<env_name>-"
И проблема, описанная в посте, произошла ровно по причине попытки создать бакет с именем, которое кто-то мог переиспользовать. Если бы там был префикс с именем компании/проекта, вероятность такого исхода была бы куда ниже.
В общем виде эта проблема существовала ещё задолго то появления AWS и S3-совместимых хранилищ. Кто-то завязывает свой софт на доменное имя, которое перестают поддерживать, а потом его кто-то посторонний регистрирует заново и получает много обращений. Иногда с заведомо злыми намерениями.
Как предлагается финансировать разработку Firefox?
напомню, что Mozilla поддерживают один из трёх сколь-либо массовых браузерных движков. развал Mozilla приведёт к тому, что останутся только WebKit и Blink. Это почти монополизация. Точно хочется такой результат получить?
Соболезную. В моих кругах везде разработчики влияли на выбор технического стека. Не всегда коллектив коллег соглашался с доводами конкретного инициатора, но нередко инициаторы могли убедить коллектив в целесообразности модификации стека, используя разумные аргументы и демонстрации.
Чего бы не использовать serverless/autopilot kubernetes, где платить приходится только за фактически используемые ресурсы?
так крепче, что Telegram в списке организаторов распространения информации, которые обязуются делиться с органами? https://habr.com/ru/articles/404985/
В том числе этим руководствуются люди вроде Танненбаума, продвигающие концепцию микроядра.
Линус с самого начала был недоволен оным и спорил с Танненбаумом. В общем-то, весь Linux начался как пара доволнений к микроядерной Minix, и потом уже постепенно вырос в отдельную ОС.
всего-то 30m+ строк, которые написаны за 30+ лет тысячами разработчиков. строк, которые работают на экзотическом железе, которое сложно тестировать. строк, от корректноти которых зависит почти весь мир.
"приключение на 5 минут -- зашли и вышли"
https://www.schoenitzer.de/lks/lks_en.html
Так работает экономика. Можно сэкономить часы разработки за счёт ресурсов пользовательских устройств. Если у среднего (а лучше у 80%-90%) покупателя в Стиме подходят требования, то стоит ли тратиться на дополнительную оптимизацию?
Тут ещё как с побочными эффектами и сроком годости -- лучше выкрутить значения в свою пользу, чтобы избежать разоочарований/претензий.
Это если рассматривать только рынок процессоров архитектуры amd64, а если рассмотреть сервервые ARM, то уже иначе будет.
KrakenD может решать эти задачи.
Как и реализации API Gateway на основе Nginx+OpenResty вроде Kong
Странный вывод на основе статьи, где даже автор явно пишет в ретроспективе
Ну а сторонних рассуждений по теме вроде
https://www.linkedin.com/pulse/scaling-up-prime-video-audiovideo-monitoring-service-reducing-larry/ или https://www.infrastructureposts.com/p/e7-thoughts-on-scaling-up-the-prime
слишком много, чтобы в 100-ый раз это обсуждать.
В публичных облаках есть много разных способов решить одну задачу. Со своими плюсами и минусами.
Если какой-то подход всегда уступает другим, соответствующие сервисы теряют пользователей и просто закрываются.
Наброс же был "злой гугл коварно выставил счёт на $75k". Вот я просто показываю, что бывает ровно наоборот.
Тоже широко известная история. Сотрудники Amazon соптимизировали свои процессы внутри AWS и остались на нём же. Какие можно выводы сделать?
Это широко известная в среде облачных инженеров история. Только вот эти стартаперы совсем не опытные, о чём они сами пишут в изначальном посте. И рекомендую почитать, что дальше произошло для полноты картины. GCP простил им этот долг.
Ну и ситуаций подобных описанной у меня не происходило, покуда я всегда держу в голове такой аспект и обвешиваю всё автобюджетированием, детекторами аномалий, ограничениями масштабирования и другими стандартными инструментами укрощения серверлесса.
А что, если я скажу, что я "воспользовался серверлессом" и выбил грантов на $700k "за красивые глаза" для стартапа от трёх крупнейших платформ, и все эти гранты удалось утилизировать на благо развития продуктов? Что у меня везде масштабирование с нуля настроено и утилизация ресурсов недостижимая для тех, кто сидит на своём железе? Не говоря уже про эластичность, гибкость и простоту прохождения любого рода аудитов и compliance процессов.
В итоге, конечно, рыночек рассудит -- я только за. Особенно, если посмотреть на числа и тенденции рынка. Что растёт и с какой скоростью. Какие компании куда миграции чаще делают.
Чем больше инфраструктурного управления берёт на себя команда, тем больше придётся трудозатрат вкладывать для достижения заданных показателей надёжности и скорости разработки. И лапша самоуправляемого кубернетеса с двумя десятками компонент будет куда больше, чем описание аналогичных облачных ресурсов в терраформе.
Как человек, который делает и то и другое, я, конечно, буду всегда рекомендовать начинать с максимально высокоуровневых абстракций и брать максимально serverless зависимости, насколько это возможно для заданного проекта и опускаться на нижние уровни абстракции только имея конкретные соображения и расчёты.
Проблема в том, что мало кто умеет хорошо расчитывать непрямые расходы на инфраструктуру. Вот как раз в виде дополнительных человекочасов, рисков и замедления цикла разработки. Отсюда часто возникают мысли, что публичные облака -- это дорого, когда только вершина айсберга видна.
Могу лишь ещё раз повторить широко известный факт: бакеты находятся в глобальном пространстве имён. То есть, два клиента AWS не могут создать бакет с одинаковым именем. Поэтому, чтобы не налетать на конфликты, все сколь-либо опытные известные мне люди работают с префиксами. Часто вида "<company_name>-<env_name>-"
И проблема, описанная в посте, произошла ровно по причине попытки создать бакет с именем, которое кто-то мог переиспользовать. Если бы там был префикс с именем компании/проекта, вероятность такого исхода была бы куда ниже.
В общем виде эта проблема существовала ещё задолго то появления AWS и S3-совместимых хранилищ. Кто-то завязывает свой софт на доменное имя, которое перестают поддерживать, а потом его кто-то посторонний регистрирует заново и получает много обращений. Иногда с заведомо злыми намерениями.
Недавно на hacker news обсуждали эту проблему в контексте Google Workspaces и их работы с OAuth2/OIDC: https://news.ycombinator.com/item?id=42699099
То ли дело коварный "Prawo Jazdy", который бесцеремонно и серийно нарушает ПДД в Ирландии https://medium.com/@aydin.j.zubair/the-curious-case-of-prawo-jazdy-irelands-elusive-serial-traffic-offender-4c63f1150ac7
Обычно всё-таки префикса, и это делается примерно всеми и всегда.
И это явно указано в best praсtices, покуда у бакетов пространство глобальное имён.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html
У Ansible нет состояния. Простой пример, где декларативность хромает:
Создаётся конфигурация, описывающая файл конфига. Выполняется синхронизация.
Файл конфига удаляется из конфигурации. Выполняется синхронизация.
В итоге синхронизация выполнена. Файл на машине есть, а в конфигурации его нет.
Можно писать отдельный пункт в конфигурации про явное удаление файла, но это уже почти императивное указание.
Эта проблема решена в альтернативных инструментах, имеющих состояние (Salt, Terraform).
Жаловаться можно, но лучше это делать анонимно. "Делай добро и беги"