ну уж нет! С это как раз портабельный ассемблер, который позволил очень быстро перетаскивать огромные кодовые базы с архитектуры на архитектуру, которых тогды было как у дурака фантиков: каждый делал своё видение.
мне тоже понравился пассаж "вам просто надо человека, знакомого с kubernetes, а уж он то за день разберётся как админить кластера из тысяч виртуальных машин под продовой нагрузкой"
раньше книги-переводы от BHV были простым нередактированным выводом переводчика. Я несколько раз обжёгся и с тех пор не купил ни одну книгу этого издательства. Сейчас это поправлено?
По облачной части тест достаточно хорош: в обсуждаемом тесте постгресс тестируется на одинаковых compute одного провайдера. Также мы никак не лимитированы в настройках нод кубера в managed kubernetes от yandex cloud: daemonset + nsexec/nsenter, я таким успешно пользуюсь. Так что всем остальным в плане облака можно смело пренебречь в рамках обсуждаемого тестирования производительности postgresql в единых условиях. Однако автор использует по разному настроенные postgresql, в качестве аргумента используя "я настроил 10 одинаковых параметров", игнорируя остальную "навеску" от операторного решения. Я бы просто поднял под с голым постгрессом без всяких операторов с одинаковым конфигом на VM и в поде.
ну так-то на vm будут всё те же экспортеры и сборщики логов. Соседи отстреливаются через taints, если вдруг у нас такой highload. Так что единственная разница с VM это сетевой путь до пода, поскольку разницы между systemd unit и запущенными в контейнере сервисами нет никакой. Ну а так, на мой взгляд, внутрикуберовые постгрессы решают задачу множественности выделенных кластеров постгресса для множества сред исполнения: тестовые стенды. Или обычные кластера обычных сервисов, из которых не делают ядро сервисов высокочастотного криптотрейдинга. Всё это даёт отличную плотность использования ресурсов для рядовой нагрузки. Наборы на VM существенно более расточительные в плане инфраструктуры.
а раскройте пожалуйста поконкретнее это ваше "все говорят", которое вы описали как "Исследования подтверждают, что по итогам пяти лет владения собственный сервер экономически более выгоден при любом сценарии, кроме краткосрочных или резко изменчивых нагрузок."
А что-то может помешать пользователю назвать домашний wifi или wifi телефона как "Office WiFi HotSpot1"? И сетевую адресацию поставить аналогичную офисной. Это правда если у него есть права на управление сетями и их паролями.
а у меня есть ощущение, что сейчас происходит массовая трансформация сознания: благодаря появившейся мгновенной связности всех со всеми постепенно отмирают государства. Полные технологические цепочки всех высокотехнологичных продуктов экономически не по силам ни одной отдельно взятой стране. Взрослые поколения ещё держатся за понятия "страна", "другие", а молодёжь в своём глобальном информационном поле растёт и развивается как граждане всего мира сразу. Это не быстрый процесс, уровня нескольких поколений, а в особо зарегулированных обществах и 4-5, но всё равно он идёт на мой взгляд. И это очередной шаг в сторону колонизации космоса человечеством
у дэйликов много одновременных задач, а не только информирование начальника. Это ещё и синхронизация самих команд внутри них и триггеры к инициации отдетльных внутренних обсуждений по архитектуре, адекватности решений или по брейнштормингу как коллеге решить задачу, которая встала. Ну и публичная демонстрация производительности конечно же.
Есть такая замечательная утилитка: ncdu. Она показывает какие каталоги с подкаталогами сколько весят. Было бы клёво получить по этому же принципу ценник по фолдеру с разбивкой по сервисам, в которые можно провалиться. Даже линейный tree-style вывод был бы шикарным
именно так и именно об этом я пишу, когда вижу жалобы, что "Девопсы хотят одного, разработчики другого". Именно поэтому компании перепрофилируются с департаментно-отдельных в стримовые структуры с целью выстраивания самодостаточных "you build it - you run it", состоящих из инженеров и бизнесменов, объединённых одной общей целью: получить премию за новые фичи и одновременно не потерять её за простои.
дык тут же классическое: если вы сделали отдел девопс, отдел тестирования, отдел разработки и отдел мониторинга, то все будут смотреть друг на друга сквозь амбразуру, поскольку оценка результатов у каждого отдела будет своя. А девопс он про одну единую самостоятельную продуктовую команду, живущую в режиме "you build it - you run it" и тогда все специализации бьются за один и тот же результат: премия за новые фичи в общем scouped живом продукте
Для ИТ должна быть возможность отдать первоначальный скрининг резюме в откликах нанимающему ит-менеджеру. Типа: менеджер нажал да/нет и все "да" ушли в hr. Отдавать только конкретную вакансию, а не все вакансии в подборе у компании. Это бы сильно помогло всем: перестанут отсеиваться релевантные конвертируемые скиллы и отклики, которые почти нереально запрограммировать в промптах и далёких от темы людях. Нанимающему работать с нанимаемым года и он найдёт несколько часов на качественную фильтрацию. Кандидатам больше не надо будет врать в резюме, чтобы пройти плохо и формально работающих AI-ботов кадровиков. Мне когда-то приходилось нанимать большую команду айтишников, hr дал мне свой аккаунт и я сам фильтровал: оказались довольны оба: я видел картину и мог подправлять описание вакансии, а она успешно закрывала массовый набор.
ну уж нет! С это как раз портабельный ассемблер, который позволил очень быстро перетаскивать огромные кодовые базы с архитектуры на архитектуру, которых тогды было как у дурака фантиков: каждый делал своё видение.
мне тоже понравился пассаж "вам просто надо человека, знакомого с kubernetes, а уж он то за день разберётся как админить кластера из тысяч виртуальных машин под продовой нагрузкой"
я тоже. Кайф
а писцам то кто передал?
раньше книги-переводы от BHV были простым нередактированным выводом переводчика. Я несколько раз обжёгся и с тех пор не купил ни одну книгу этого издательства. Сейчас это поправлено?
По облачной части тест достаточно хорош: в обсуждаемом тесте постгресс тестируется на одинаковых compute одного провайдера. Также мы никак не лимитированы в настройках нод кубера в managed kubernetes от yandex cloud: daemonset + nsexec/nsenter, я таким успешно пользуюсь. Так что всем остальным в плане облака можно смело пренебречь в рамках обсуждаемого тестирования производительности postgresql в единых условиях. Однако автор использует по разному настроенные postgresql, в качестве аргумента используя "я настроил 10 одинаковых параметров", игнорируя остальную "навеску" от операторного решения. Я бы просто поднял под с голым постгрессом без всяких операторов с одинаковым конфигом на VM и в поде.
ну так-то на vm будут всё те же экспортеры и сборщики логов. Соседи отстреливаются через taints, если вдруг у нас такой highload. Так что единственная разница с VM это сетевой путь до пода, поскольку разницы между systemd unit и запущенными в контейнере сервисами нет никакой.
Ну а так, на мой взгляд, внутрикуберовые постгрессы решают задачу множественности выделенных кластеров постгресса для множества сред исполнения: тестовые стенды. Или обычные кластера обычных сервисов, из которых не делают ядро сервисов высокочастотного криптотрейдинга. Всё это даёт отличную плотность использования ресурсов для рядовой нагрузки. Наборы на VM существенно более расточительные в плане инфраструктуры.
а раскройте пожалуйста поконкретнее это ваше "все говорят", которое вы описали как "Исследования подтверждают, что по итогам пяти лет владения собственный сервер экономически более выгоден при любом сценарии, кроме краткосрочных или резко изменчивых нагрузок."
на что только не идут, лишь бы не пользоваться vim
А что-то может помешать пользователю назвать домашний wifi или wifi телефона как "Office WiFi HotSpot1"? И сетевую адресацию поставить аналогичную офисной. Это правда если у него есть права на управление сетями и их паролями.
а у меня есть ощущение, что сейчас происходит массовая трансформация сознания: благодаря появившейся мгновенной связности всех со всеми постепенно отмирают государства. Полные технологические цепочки всех высокотехнологичных продуктов экономически не по силам ни одной отдельно взятой стране. Взрослые поколения ещё держатся за понятия "страна", "другие", а молодёжь в своём глобальном информационном поле растёт и развивается как граждане всего мира сразу. Это не быстрый процесс, уровня нескольких поколений, а в особо зарегулированных обществах и 4-5, но всё равно он идёт на мой взгляд. И это очередной шаг в сторону колонизации космоса человечеством
у дэйликов много одновременных задач, а не только информирование начальника. Это ещё и синхронизация самих команд внутри них и триггеры к инициации отдетльных внутренних обсуждений по архитектуре, адекватности решений или по брейнштормингу как коллеге решить задачу, которая встала. Ну и публичная демонстрация производительности конечно же.
Есть такая замечательная утилитка: ncdu. Она показывает какие каталоги с подкаталогами сколько весят. Было бы клёво получить по этому же принципу ценник по фолдеру с разбивкой по сервисам, в которые можно провалиться. Даже линейный tree-style вывод был бы шикарным
именно так и именно об этом я пишу, когда вижу жалобы, что "Девопсы хотят одного, разработчики другого". Именно поэтому компании перепрофилируются с департаментно-отдельных в стримовые структуры с целью выстраивания самодостаточных "you build it - you run it", состоящих из инженеров и бизнесменов, объединённых одной общей целью: получить премию за новые фичи и одновременно не потерять её за простои.
дык тут же классическое: если вы сделали отдел девопс, отдел тестирования, отдел разработки и отдел мониторинга, то все будут смотреть друг на друга сквозь амбразуру, поскольку оценка результатов у каждого отдела будет своя. А девопс он про одну единую самостоятельную продуктовую команду, живущую в режиме "you build it - you run it" и тогда все специализации бьются за один и тот же результат: премия за новые фичи в общем scouped живом продукте
по истечении лицензий дату на сервере отмотаете назад на пару лет и забьёте на статистику и автоматизацию списаний?
у вашего решения фактор автобуса чудовищен
del
Для ИТ должна быть возможность отдать первоначальный скрининг резюме в откликах нанимающему ит-менеджеру. Типа: менеджер нажал да/нет и все "да" ушли в hr. Отдавать только конкретную вакансию, а не все вакансии в подборе у компании. Это бы сильно помогло всем: перестанут отсеиваться релевантные конвертируемые скиллы и отклики, которые почти нереально запрограммировать в промптах и далёких от темы людях. Нанимающему работать с нанимаемым года и он найдёт несколько часов на качественную фильтрацию. Кандидатам больше не надо будет врать в резюме, чтобы пройти плохо и формально работающих AI-ботов кадровиков. Мне когда-то приходилось нанимать большую команду айтишников, hr дал мне свой аккаунт и я сам фильтровал: оказались довольны оба: я видел картину и мог подправлять описание вакансии, а она успешно закрывала массовый набор.
решает, поднимая вопрос доверия: а точно ли нам стоит внутренний код доверять стороннему честно-честно деликатному сайту?