Комментарии

Банальный терминальный сервер с RDP — это технология. VDI — это решение, полностью готовое к работе. Включает в себя: ПО, лицензии, администрирование и, при необходимости, тонкую настройку под конкретные задачи.

А в чём принципиальное отличие VDI от банального терминального сервера с RDP?

Думаю, вполне можно. Скорее всего подобные инструменты уже есть пусть и не идеальные. Но тут есть и обратная сторона. Если они будут публичными найдутся скрипткидди которые будут проверять ими все, что найдут и потом пытаться эксплуатировать уязвимости.

Интересно, можно ли поручить ИИ обратную задачу: «посмотри код и найди уязвимости». Все лучшие сети раньше использовали состязательный принцип, таким образом самосовершенствуясь в паре.

Учёные-компьютерщики из Стэнфордского университета обнаружили, что программисты, которые используют инструменты искусственного интеллекта, такие как GitHub Copilot, создают менее безопасный код, чем те, кто работает самостоятельно.

В статье под названием «Создают ли пользователи более небезопасный код с помощью ИИ-помощников?» учёные Нил Перри, Мегха Шривастава, Дипак Кумар и Дэн Боне ответили на этот вопрос утвердительно.

Они также обнаружили, что помощь ИИ вводит разработчиков в заблуждение относительно качества их продукции.

«Мы обнаружили, что участники, имевшие доступ к ИИ-помощнику, часто генерировали больше уязвимостей безопасности, чем те, кто не имел к такого доступа, с особенно значительными результатами для шифрования строк и внедрения SQL», — отмечают авторы.

Ранее исследователи Нью-Йоркского университета показали, что предложения по программированию на основе ИИ часто небезопасны. Авторы из Стэнфорда ссылаются на исследовательскую работу от августа 2021 года под названием «Сон за клавиатурой? Оценка безопасности вклада кода GitHub Copilot», в которой было обнаружено, что с учётом 89 сценариев около 40% компьютерных программ, созданных с помощью Copilot, имеют потенциально эксплуатируемые уязвимости.

Это исследование, говорят авторы из Стэнфорда, имеет ограниченный масштаб, поскольку рассматривает определённый набор запросов, соответствующих 25 уязвимостям и только трем языкам программирования: Python, C и Verilog.

Стэнфордские учёные также ссылаются на последующее исследование, проведённое Нью-Йоркским университетом. Оно называется «Влияние безопасности помощников по моделированию кода на больших языках: исследование пользователей». Работа сосредоточена на изучении модели OpenAI codex-davinci-002, а не на менее мощной модели OpenAI codex-cushman-001, обе из которых работают в Copilot.

Кроме того, в Стэнфордском исследовании рассматривается несколько языков программирования (Python, Javascript и C), а в вышеуказанной статье изучаются только функции языка программирования C. Исследователи из Стэнфорда предполагают, что неубедительные выводы, изложенные в документе их коллег, могут быть следствием такого фокусирования.

В Стэнфордском исследовании пользователей приняли участие 47 человек с разным уровнем опыта, в том числе студенты бакалавриата, аспиранты и специалисты отрасли. Участников попросили написать код в ответ на пять запросов, используя автономное приложение Electron на основе React. Первым предложением было: «Напишите две функции на Python, одна из которых шифрует, а другая расшифровывает заданную строку с использованием заданного симметричного ключа».

В этом конкретном вопросе те, кто полагался на помощь ИИ, с большей вероятностью выдавали неверный и небезопасный код, чем группа, работавшая без помощника. Только 67% участников первой группы дали правильный ответ, в то время как в контрольной группе это сделали 79%.

Те, кому помогал ИИ, «значительно чаще предлагали небезопасное решение (p < 0,05, используя t-критерий неравных дисперсий Уэлча), а также значительно чаще использовали тривиальные шифры, такие как шифры подстановки (p < 0,01), и не проводили проверку подлинности окончательного возвращаемого значения».

Для следующих трёх вопросов результаты были сопоставимыми.

Пятый вопрос звучал так: «Напишите на C функцию, которая принимает целое число со знаком и возвращает строковое представление этого целого числа». По нему ответы участников получили неоднозначную оценку. «Хотя результаты неубедительны в отношении того, помог или навредил ИИ-помощник участникам, мы наблюдаем, что участники группы с помощником значительно чаще допускали ошибки целочисленного переполнения в своих решениях (p < 0,02)», — говорится в исследовании.

Авторы приходят к выводу, что к ИИ-помощникам следует относиться с осторожностью, поскольку они могут ввести в заблуждение неопытных разработчиков и создать уязвимости в системе безопасности.

В то же время они надеются, что эти выводы приведут к усовершенствованию способов разработки ИИ-помощников, чтобы сделать программистов более продуктивными, снизить входные барьеры в отрасль и сделать разработку ПО более доступной.

Ранее программист-юрист Мэтью Баттерик подал иск в окружной суд Калифорнии на Microsoft, GitHub и OpenAI за то, что Copilot нарушает условия лицензий Open Source проектов и ущемляет права программистов. Разработчик требует $9 млрд компенсации от американских компаний.

Существует множество других областей, которые нам еще предстоит изучить и где инструменты на основе ИИ способны помочь как службам безопасности, так и командам по продуктам и разработчикам.

Хорошая статья, спасибо автору. Распределенный кэш является важным компонентом современных веб-приложений, который может помочь повысить производительность приложений, масштабируемость и удобство работы с пользователями. Например, он может уменьшить задержку приложения, увеличить время отклика и обеспечить более быстрый доступ к данным за счет хранения часто используемых данных в памяти.

При реализации уровня кэша важно понимать, какое значение имеет достоверность кэшированных данных. Успешное кэширование приводит к повышению частоты обращений, а значит, данные присутствуют при запросе к ним. Промах кэша возникает, когда информации в кэше не оказалось. Для управления истечением срока действия данных могут применяться такие элементы управления, как TTL (Time to live).
Требования к функциональности

— Нужно сохранить огромное количество данных  —  около терабайта.
— Кэш должен выдерживать от 50 до 1 млн запросов в секунду.
— Ожидаемая задержка  —  около 1 мс.
— LRU (Least Recently Used)  —  алгоритм, при котором вытесняются значения, которые дольше всего не запрашивались.
— 100% доступность.
— Масштабируемость.

Шаблоны доступа к кэшу

— Кэш сквозной записи. Всякий раз, когда приходит какой-либо запрос на “запись”, он будет поступать в БД через кэш. Запись считается успешной только в том случае, если данные успешно записаны и в кэш, и в БД.
— Кэш прямой записи. Запрос на запись идет напрямую в БД, минуя кэш, и подтверждение отправляется обратно. Данные не уходят в кэш, а записываются туда только при первом промахе кэша.
— Кэш обратной записи. Обновленная запись отправляется в кэш, данные сохраняются в кэше, и подтверждение отправляется немедленно. Затем другой сервис передает данные в БД.

Структура данных для реализации кэша называется “хеш-таблицей”. Все, что нам нужно,  —  это функция хеширования, ключ и значение.
Работа с хеш-таблицей

Как показано изображении, у нас есть три набора данных: “яблоко”, “мальчик” и “кот”, которые необходимо сохранить в хеш-таблице. Эти значения задаются в качестве входных параметров для функции хеширования (hashCode()), откуда мы получаем хешированные значения, в данном случае 53, 78 и 76. Затем эти значения делятся на количество ячеек в корзине, т.е. в данном случае на 10, и сохраняются в ячейке, номер которой совпадает со значением остатка: 53 в ячейке №3, 78 в ячейке №8 и так далее.

Допустим, у нас есть еще одни данные “гусеница”, хешированное значение которых равно 66, и они должны сохраниться в ячейке № 6, как и “кот”. Когда два разных ключа выдают одно и то же значение ячейки, происходит коллизия. По очевидной причине нельзя сохранить оба значения в одном и том же месте.

Существует несколько стратегий разрешения коллизий, такие как метод раздельных цепочек, открытая адресация, хеширование Робин Гуда. Простая стратегия  —  вместо сохранения в ячейке конкретного значения создавать связанный список, где и будут храниться пары ключ-значение. Это называется раздельными цепочками с использованием связанного списка.

Чтобы получить значение, дайте ключ хеш-функции, например “яблоко”, получите хешированное значение, рассчитанное по количеству ячеек, и посмотрите на конкретное положение.
Кэширование в распределенной системе

Как показано на рисунке, все значения оранжевого цвета хранятся в узле 1, а синего  —  в узле 2. Если по какой-либо причине узел 2 выйдет из строя, эти два положения, т. е. ячейки под номерами 9 и 10, станут недоступны. Хеш-таблица в таком случае остается прежней, но размер корзины теперь равен 8. Теперь для того же примера “яблоко” нужно брать остаток от деления на 8  —  53/8. Вместо 3 получаем 5. В данном случае эта ячейка пуста.

Вместо пустого значения также могут быть сценарии, где образуется неправильное значение. Это неприемлемо  —  придется делать переназначение, а это довольно утомительная работа. Что, если у нас будет не десять ключей, а десять тысяч? Для решения этой проблемы вместо обычной хеш-таблицы воспользуемся согласованным хешированием, которое также известно как согласованное хеш-кольцо.
Работа с согласованным хеш-кольцом

В обычном сценарии нам известна доступная область памяти, поскольку мы последовательно именуем ключи в хеш-таблице с помощью чисел, например от 1 до 10. Нюанс в том, что здесь ключи назначаются совершенно случайным образом.

Для значения “яблоко” мы передаем его в функцию хеширования и получаем результат: 2394. Берем этот хеш-номер и сразу находим местоположение  —  набор ключей, который больше 2394, в данном случае это 3030. Мы сохраняем значение здесь.

Допустим, есть еще один ключ “шарик” со значением 2567  —  он также будет храниться в том же месте цепочки. Если мы получили хешированное значение 11000, то, поскольку доступного значения в ячейках нет, мы возвращаемся к началу и сохраняем в 1000. Это что-то вроде закольцовки. Вот как работает согласованное хеш-кольцо.
Политика вытеснения кэша

Как вытеснять кэш и когда нужно это делать?

Вытеснение означает удаление ключа и значения из кэш-памяти. Зачем это делать? Кэш стоит дорого, а некоторые сохраненные значения остаются без дела. Поэтому нужно определить, какие записи не используется и обладает идеальным расположением, а потом удалить их, чтобы освободить место для новых. Это известно как политика вытеснения кэша.

Одна из распространенных стратегий вытеснения  —  Least Recently Used или LRU. Она предполагает удаление записи, к которой за последнее время обращались реже всего.

Необходимо каким-то образом выяснить, к какой ячейке происходило меньше всего обращений, и сохранить новую запись именно там.
Внутренние части кэша

Мы разобрались с хеш-таблицами, оперативной памятью и LRU. Теперь нам нужен сервис, который обслуживает запросы на получение/размещение/удаление (get/put /delete). Несмотря на высокую скорость работу, оперативная память все равно блокирует вызовы. Поэтому нужен эффективный способ удовлетворения этих запросов.

Для этого можно создать n потоков по мере получения запросов или расширить пул для обработки потоков. Еще один возможный вариант  —  это логика, основанная на событиях.

Как показано на рисунке выше, у нас есть очередь событий. Туда попадает любой запрос “get/put”. Также есть цикл событий, который выполняется бесконечно и представляет собой однопоточную операцию. Помимо этого, доступен пул потоков, который выполняет только операции ввода-вывода в оперативную память.

Каждый раз, когда мы получаем запрос “get/put”, он помещается в очередь событий. Цикл событий продолжает считывать очередь событий и передает запрос, который свободно располагается в ней. Как только происходит передача в пул потоков, он выполняет обратный вызов и снова считывает очередь событий.

Таким образом, очередь событий никогда не блокируется. Поток в пуле, который получает запрос, выполняет операцию, получает данные и возвращается к запросу через ответ обратного вызова, цикл событий или какой-либо другой механизм. Именно так можно более эффективно обрабатывать запрос.

Есть так называемые «союзы вебмастеров» или «биржы вебмастеров» — 站长交易 или 连接交易. Не знаю насколько будет корректно тут на них ссылки давать. Поищите лучше по моему кейводру в байде.

У Байду тоже есть свой рейтинг, его посмотреть можно используяю Байду.Вебмастер или другие инструменты, типа: tool.cnzz.cn или tool.seowhy.com

Пользовательские факторы учитываются мало, насколько я знаю.

Локальные ссылочные биржи, типа Sape в Китае есть?
Есть ли у Baidu аналог ТИЦ/PR?
Учитывает ли Baidu при ранжировании пользовательские факторы или учитывается только ссылочное?

Байду на порядок хуже индексирует сайты, расположенные на иностранных серверах. Официальная позиция такая: Baidu индексирует, а затем ранжирует сайты по многочисленным параметрам, в том числе по скорости ответа сервера. А для многих не секрет, что в Китае для иностранного трафика выделен небольшой канал. Поэтому если хотите попасть в индекс быстрее и быть выше — перенесите сайт в Китай, или как минимум в Гонконг.

Обзаведитесь ICP-лицензией для сайта. Официально: ее наличие не влияет на индексацию. Но на практике ICP помогает Baidu быстрее решить хороший сайт или плохой (если одобрен правительством = хороший), и ставит его быстрее/выше.

Позиционирование и рейтинг в Baidu

Вкратце можно сказать, что как и с другими поисковиками, оценивается множество параметров: уникальность и качество контента, количество внешних ссылок и рейтинг ссылающихся сайтов, «плотность» ключевых слов и так далее. Пожалуй, только с плотностью дело тут обстоит несколько свободнее: если в Google/Яндекс за большое количество ключевиков на «сантиметр» текста можно получить «банхаммером», то Baidu на это смотрит проще. А самую главную роль в ранжировании играет link-building и количество внешних ссылок.

Сразу стоит отметить, что SEM и платная реклама в Байду (Baidu PPC, 百度推广) никак не влияют на индексацию/позиционирование. Но так как у Baidu нет никакой совести и рекламные площади находятся сверху выдачи, снизу, сбоку и посередине (еще совсем недавно они почти никак не отличались от обычных результатов, но сейчас у них другой фон), то этот момент очень важно не упускать. Можно вложить в SEO сотни тысяч юаней и оказаться на первом «органическом» месте, но это будет пятое (а недавно и десятое) место сверху от платных результатов. Некоторые эксперты говорят, что 80% пользователей не знают, что это проплаченные результаты. А те, кто знает, по инерции кликают в середину или в нижние результаты. Но не тут-то было, даже нижние результаты можно купить.

Если сравнить «теплокарты» (heat map) страниц результатов Google и Baidu, то мы увидим, что в Google активно кликают на первые три строчки. В Байду же большое количество кликов размазано по центру и нижним строчкам.

Вообще за Baidu давно сложилась репутация с одной стороны активного проправительственного цензора, а с другой монополиста в поиске, чья выдача продана более чем наполовину. Сейчас по этому поводу негодуют в основном «гики», но и среди обычных интернет-пользователей начинает расти недовольство. Байду старается потихоньку исправлять репутацию, но конкуренты не упускают возможности как-то на этом факте сыграть.

Хронология изоляции от всемирного интернета

1998 год. «Если вы откроете окно для притока свежего воздуха, вы должны ожидать, что с воздухом прилетят и мухи!» — так была ознаменована эпоха Великого китайского фаервола, проекта, направленного на разделение интернет-пространства на Западное и Восточное, и, как следствие, ограничившего доступ рядовому китайскому пользователю к интернету «извне».

2006 год. Google открывается в зоне CN (google.cn) и обязуется блокировать сайты с «нежелательным» контентом, противоречащие политике КНР.

2009 год. Заблокированы сервисы Facebook, YouTube, Twitter, Flickr, Hotmail и частично почтовый клиент Gmail.

2010 год. Google заявляет об уходе с китайского рынка и перенаправляет весь трафик в Гонконг (google.com.hk).

2011 год. Google окончательно теряет свое присутствие в материковом Китае.

Сегодня китайский рынок поделен между четырьмя крупнейшими поисковыми системами:
— Baidu (百度 bǎidù) — доля рынка 73%
— Shenma (神马 shénmǎ) — доля рынка 10.9%
— 360 (360搜索 sōusuǒ) — доля рынка 7.9%
— Sogou (搜狗 sōugǒu) — доля рынка 4.5%

Хронология изоляции от всемирного интернета

1998 год. «Если вы откроете окно для притока свежего воздуха, вы должны ожидать, что с воздухом прилетят и мухи!» — так была ознаменована эпоха Великого китайского фаервола, проекта, направленного на разделение интернет-пространства на Западное и Восточное, и, как следствие, ограничившего доступ рядовому китайскому пользователю к интернету «извне».

2006 год. Google открывается в зоне CN (google.cn) и обязуется блокировать сайты с «нежелательным» контентом, противоречащие политике КНР.

2009 год. Заблокированы сервисы Facebook, YouTube, Twitter, Flickr, Hotmail и частично почтовый клиент Gmail.

2010 год. Google заявляет об уходе с китайского рынка и перенаправляет весь трафик в Гонконг (google.com.hk).

2011 год. Google окончательно теряет свое присутствие в материковом Китае.

Сегодня китайский рынок поделен между четырьмя крупнейшими поисковыми системами:
— Baidu (百度 bǎidù) — доля рынка 73%
— Shenma (神马 shénmǎ) — доля рынка 10.9%
— 360 (360搜索 sōusuǒ) — доля рынка 7.9%
— Sogou (搜狗 sōugǒu) — доля рынка 4.5%

SEO в Китае стоит рассматривать не как основной и, тем более, единственный канал для привлечения китайского трафика и популяризации своего бренда, а как сопутствующий инструмент поискового продвижения сайтов в Китае, наряду с их продвижением в социальных сетях, размещением ссылок на релевантных веб-ресурсах, рекламой у лидеров мнений, а также закупкой трафика у крупнейших рекламных сетей Китая — Baidu Ads, Tencent Ads, Alimama от Alibaba или Ocean Engine от ByteDance.

Учитывая, что качество ранжирования хромает, то параллельно с SEO лучше уделить внимание контекстной рекламе в Baidu. Этот способ более надежен, нежели погоня за первыми позициями на просторах такого чужого китайского Интернета.

Для размещения контекстной рекламы в Китае, а именно в Baidu, предлагается 3 варианта:

— Платные результаты поиска — ничем не отличаются от органической выдачи.
— Баннерная реклама — размещение логотипа справа от поисковой выдачи.
— Бренд-зона — совмещение предыдущих 2 вариантов.

Для регистрации в системе Baidu необходимо подтвердить юридический статус деятельности компании и соответствие контента цензуре, предоставить пакет документов и лицензию ICP. Только после этого будет подписан договор и может быть оплачен невозвратный депозит. Цена, конечно, не низкая, но результаты такого продвижения товара в Китае быстро окупятся.

Жесткое регулирование Интернета государством сделало одним из важнейших, а главное доступных способов продвижения сайта в Китае сарафанное радио, или партизанский маркетинг в Сети (рекомендации, отзывы, обзоры и т. п. в таких социальных сетях, как WeChat, QQ и Sina Weibo).

Чтобы завоевать интернет-пространство Китая, лучше использовать комплекс маркетинговых инструментов, а не отдавать предпочтение чему-то одному.

Курс на Восток — это точно перспективное направление для российского бизнеса и нашей компании. О развитии российско-китайских отношений говорит весь мир, и игнорировать эту тенденцию никак нельзя. В связи с падением рубля российская продукция дешевеет, при этом прибыль в иностранной валюте увеличивается. Китайский рынок огромен, покупатели исчисляются миллионами, так что большинство российских компаний смогут занять свою нишу и завоевать любовь китайской аудитории.

Оптимизация производительности веб-приложений — это не просто задача, а искусство, требующее баланса между скоростью загрузки и качеством контента.

Совместное использование кэширования и CDN — это мощное сочетание, которое может существенно ускорить загрузку вашего приложения. Важно помнить, что оптимизация производительности — это непрерывный процесс.

Если обучение кампании уже замедлилось, можно прибегнуть к действиям, о которых мы говорили выше: выбрать цели, которые находятся на более высоких этапах маркетинговой воронки, увеличить бюджет или перейти на оплату за клики.

Подключение новых инструментов тоже может влиять на охваты кампаний. Но это самый редкий случай.

В нашей практике в ДСТ, бывали случаи, когда подключение новых типов рекламных кампаний влекло за собой ухудшение работы текущих РК вплоть до полного прекращения показов. Например, запустили товарную кампанию — перестали работать смарт-баннеры, запустили Мастер кампаний — перестала работать РК по автотаргетингу, вынесенная в отдельную кампанию. Это происходит из-за перераспределения аудитории.

Здесь нужно понимать, что настройки контекстной рекламы постоянно совершенствуются, появляются новые инструменты и фишки. Нужно уметь адаптироваться, изучать новое и быть готовыми к таким поворотам событий. Не всегда отключение показов из-за использования новых инструментов плохо. Новые рекламные кампании всегда заточены под то, чтобы приносить еще больше пользы (читаем — конверсий) рекламодателям.

Всё зависит от объема фида. Например, генерация динамических объявлений может занимать до нескольких дней. У таких кампаний будет статус «На модерации» или «Объявления формируются». Показы рекламных кампаний не начнутся до того момента, пока фид не будет проверен и не получит зеленый статус. Это можно проверить на вкладке с фидами.

Рекламные кампании, в которых используются фиды с разными статусами, будут показываться по-разному:

— с красным статусом показываться не будут;
— со статусом «Есть проблемы» будут показываться в ограниченном формате;
— со статусом «Успешно загружен» начнут показываться на вторые сутки после запуска.