А как вы видите на приведённых диаграммах Dependency Tracking (отслеживаение уязвимостей в уже использующися сборках и образах, которые были выявлены после прохождения Security Gate)? Например, в ситуации, когда была найдена уязвимость в сторонней зависимости, которая используется в образе, задеплоенном несколько недель или месяцев назад, и о которой не было известно сканерам (той же Trivy) на момент прохождения Security Gate.
У Dell корпоративные Latitude были очень хороши: модульные (можно заменить / добавить что угодно на стандартных разъёмах), легко ремонтируются, крепкие металлические корпуса.
Latitude 7490 до сих пор пользуюсь, с Дебиан из коробки работает всё железо, даже встроенный LTE-модем.
А Precision всё-таки «гробики» были, очень уж тяжёлые и большие.
На HTTP сервер, как уже отметили выше, не тянет, только на TCP.
Хорошо было бы рассмотреть, как использовать уже имеющийся в JDK com.sun.net.httpserver.HttpServer в неблокируещем режиме, и, например, с использованием Virtual threads. Хотя, похоже, всё это сведётся к банальной строчке server.setExecutor(Executors.newVirtualThreadPerTaskExecutor()).
Есть telegram-curses (на базе ncurses TUI) от того же автора, что и telegram-cli. Этот клиент активно обновляется. Ну и вышеупомянутый tgt, если TUI не подходит, и хочется хоткеев. Оба (что нисколько не удивительно) являются обёрткой над официальной td-lib от команды Телеграм, разве что tgt, так как написан на Rust, использует Rust-обёртку над библиотекой от того же автора, что и сам клиент.
А Я.Браузер (который как раз на основе Chromium) в Аркадии же лежит? Не пробовали большой проект из Аркадии в SourceCraft перенести и производительность измерить?
Кажется, нужна статья от вас про актуальные компетенции админов ЦОДа и состояние рынка найма. Статей, как запрыгнуть в IT, как и курсов с рекламой, пруд пруди. Но я не видел ни одной про инженеров ЦОДа (кажется, на трёхмесячных курсах этом не учат).
Тут в чём проблема: id платежной связки можно инвалидировать только если он выдан самой Визой (так называемые scheme tokens, которые выглядят как номер карты, только другой).
С токенами, выданные платёжным шлюзом, так не получится: схема о них ничего не знает, знает (должна знать) только про идентификатор опорного платежа.
У вас тут Сбер присутствует как три совершенно разные, и, формально, не связанные между собой сущности: Сбер-платёжный-шлюз, Сбер-эквайер и Сбер-банк-выпустивший-карту. Между двумя последними должна ещё быть схема (НСПК + Мир), но привет, Сбер!
Токен (id платежной связки) возвращает шлюз (могла бы вернуть схема, но я не знаю, есть ли у Мира scheme tokens). Соответственно, токеном владеет только шлюз: он умеет сопоставить токен с карточными данными и «опорной» транзакцией—той, на которую был выдан токен, и идентификатор (RRN) которой отправляется в эквайера. Эквайер мог бы поделиться этими данными с банком-выпустившим-карту (и таки Visa, например, требует этот идентификатор, а, значит, его можно сделать доступным банку-выпустившему-карту), но тут уже внутренняя кухня Сбера.
Токен можно настроить разными способами, в том числе ограничив частоту применения (зависит от конкретного шлюза). И с токеном может ходить как сам мёрчант (расписание у мёрчанта), так и платёжный шлюз сам хранит расписание и списывает деньги (но не все шлюзы так могут).
Это вы ещё про card-on-file и unscheduled card-on-file не слышали, хотя, наверное, пользуетесь. Тут вообще никаких проверок: ваши карточные данные просто хранятся у магазина, а в PSP приходит файлик с номером карты и сколько списать.
Банк вообще не в курсе «подписок»: есть запрос на авторизацию, если условия соблюдены (аутентификация прошла и списание возможно), то происходит списание. Вся кухня токенизации (куда входят рекурренты и подписки) находится на стороне PSP и (с недавних пор) схемы.
Вряд ли дело в процессе: дело не в том, сколько времени нужно, чтобы поправить и применить конфиг для nginx (со всей бюрократией меньше часа).
Скорее всего такая конфигурация была умышленной. Возможно, после переезда морды с Яндекса поломались какие-то элементы, и требовалось, чтобы ответ от нод фронта (вот тот, который потом в window помещается) отдавался без проверки CORS.
Соответственно, задержка была связана не с правкой конфига, а с глубокой правкой фронта, чтобы он либо ходил по API, либо не разваливался с включённым CORS.
Ну и хотелось бы прочитать тут разбор, например, от @ilyakashlakov. Он, возможно, сам приложил руку к конкретно этому фрагменту.
На 99% уверен, что это было не багом, а фичей доя фронтов (умышленно так настроили nginx). Поэтому ждали так долго не когда конфиг применится, а когда фронты у себя поправят и зарелизят.
К сожалению, нет. Работодатель ничего не может оплатить из медстраховки, лучшее, чего можно добиться—это 5% коллективной скидки на страховку у одного из страховщиков. Даже бесплатный обед в офисе запрещён (приравнен к доходу и облагаем по максимальной ставке).
А почему работник не должен платить налоги со страховки? Это такой же доход с точки зрения налоговой. В Нидерландах такие схемы не работают: все опосредованные выплаты считаются доходом и облагаются налогом 54,5%. Так что даже бесплатные обеды в офисе просто так не сделать, нужно хитрые схемы придумывать с employee contribution.
А как вы видите на приведённых диаграммах Dependency Tracking (отслеживаение уязвимостей в уже использующися сборках и образах, которые были выявлены после прохождения Security Gate)?
Например, в ситуации, когда была найдена уязвимость в сторонней зависимости, которая используется в образе, задеплоенном несколько недель или месяцев назад, и о которой не было известно сканерам (той же Trivy) на момент прохождения Security Gate.
У Dell корпоративные Latitude были очень хороши: модульные (можно заменить / добавить что угодно на стандартных разъёмах), легко ремонтируются, крепкие металлические корпуса.
Latitude 7490 до сих пор пользуюсь, с Дебиан из коробки работает всё железо, даже встроенный LTE-модем.
А Precision всё-таки «гробики» были, очень уж тяжёлые и большие.
Testplane выглядит как Ашот (от yandex-qatools) as a Service.
На HTTP сервер, как уже отметили выше, не тянет, только на TCP.
Хорошо было бы рассмотреть, как использовать уже имеющийся в JDK
com.sun.net.httpserver.HttpServerв неблокируещем режиме, и, например, с использованием Virtual threads. Хотя, похоже, всё это сведётся к банальной строчкеserver.setExecutor(Executors.newVirtualThreadPerTaskExecutor()).Векторный API уже доступен в Java начиная с 17 LTS (с 16 как preview).
Проект девять лет не обновлялся. Подозреваю, issues уже не разбираются, да и, скорее всего, никто его не проверял с включённым
-Werror=all.Есть telegram-curses (на базе ncurses TUI) от того же автора, что и telegram-cli. Этот клиент активно обновляется. Ну и вышеупомянутый tgt, если TUI не подходит, и хочется хоткеев. Оба (что нисколько не удивительно) являются обёрткой над официальной td-lib от команды Телеграм, разве что tgt, так как написан на Rust, использует Rust-обёртку над библиотекой от того же автора, что и сам клиент.
А Я.Браузер (который как раз на основе Chromium) в Аркадии же лежит? Не пробовали большой проект из Аркадии в SourceCraft перенести и производительность измерить?
Кажется, нужна статья от вас про актуальные компетенции админов ЦОДа и состояние рынка найма. Статей, как запрыгнуть в IT, как и курсов с рекламой, пруд пруди. Но я не видел ни одной про инженеров ЦОДа (кажется, на трёхмесячных курсах этом не учат).
У Яндекса уже лет восемь как нейронки в основе поиска. Или вы про отображение результатов на СЕРПе через текстогенератор?
Я сразу, как увидел JSON, захотел поинтересоваться: а чего не CSV? Парсер и генератор сильно проще, типы вам не нужны (если все значения—строки).
Тут в чём проблема: id платежной связки можно инвалидировать только если он выдан самой Визой (так называемые scheme tokens, которые выглядят как номер карты, только другой).
С токенами, выданные платёжным шлюзом, так не получится: схема о них ничего не знает, знает (должна знать) только про идентификатор опорного платежа.
У вас тут Сбер присутствует как три совершенно разные, и, формально, не связанные между собой сущности: Сбер-платёжный-шлюз, Сбер-эквайер и Сбер-банк-выпустивший-карту. Между двумя последними должна ещё быть схема (НСПК + Мир), но привет, Сбер!
Токен (id платежной связки) возвращает шлюз (могла бы вернуть схема, но я не знаю, есть ли у Мира scheme tokens). Соответственно, токеном владеет только шлюз: он умеет сопоставить токен с карточными данными и «опорной» транзакцией—той, на которую был выдан токен, и идентификатор (RRN) которой отправляется в эквайера. Эквайер мог бы поделиться этими данными с банком-выпустившим-карту (и таки Visa, например, требует этот идентификатор, а, значит, его можно сделать доступным банку-выпустившему-карту), но тут уже внутренняя кухня Сбера.
Токен можно настроить разными способами, в том числе ограничив частоту применения (зависит от конкретного шлюза). И с токеном может ходить как сам мёрчант (расписание у мёрчанта), так и платёжный шлюз сам хранит расписание и списывает деньги (но не все шлюзы так могут).
Это вы ещё про card-on-file и unscheduled card-on-file не слышали, хотя, наверное, пользуетесь. Тут вообще никаких проверок: ваши карточные данные просто хранятся у магазина, а в PSP приходит файлик с номером карты и сколько списать.
Банк вообще не в курсе «подписок»: есть запрос на авторизацию, если условия соблюдены (аутентификация прошла и списание возможно), то происходит списание. Вся кухня токенизации (куда входят рекурренты и подписки) находится на стороне PSP и (с недавних пор) схемы.
Может, хостов слишком много, или не придумали как автоматизировать. Или не хотели «светить» все хосты в одном списке.
Вряд ли дело в процессе: дело не в том, сколько времени нужно, чтобы поправить и применить конфиг для nginx (со всей бюрократией меньше часа).
Скорее всего такая конфигурация была умышленной. Возможно, после переезда морды с Яндекса поломались какие-то элементы, и требовалось, чтобы ответ от нод фронта (вот тот, который потом в
windowпомещается) отдавался без проверки CORS.Соответственно, задержка была связана не с правкой конфига, а с глубокой правкой фронта, чтобы он либо ходил по API, либо не разваливался с включённым CORS.
Ну и хотелось бы прочитать тут разбор, например, от @ilyakashlakov. Он, возможно, сам приложил руку к конкретно этому фрагменту.
На 99% уверен, что это было не багом, а фичей доя фронтов (умышленно так настроили nginx). Поэтому ждали так долго не когда конфиг применится, а когда фронты у себя поправят и зарелизят.
К сожалению, нет. Работодатель ничего не может оплатить из медстраховки, лучшее, чего можно добиться—это 5% коллективной скидки на страховку у одного из страховщиков. Даже бесплатный обед в офисе запрещён (приравнен к доходу и облагаем по максимальной ставке).
А почему работник не должен платить налоги со страховки? Это такой же доход с точки зрения налоговой. В Нидерландах такие схемы не работают: все опосредованные выплаты считаются доходом и облагаются налогом 54,5%. Так что даже бесплатные обеды в офисе просто так не сделать, нужно хитрые схемы придумывать с employee contribution.