В руководство по языку Си добавлена статья про параллельные вычисления с помощью библиотеки OpenMP
https://metanit.com/c/tutorial/11.6.php
#c_ansi

Вкратце история развития Unix-подобных систем #unix #linux #macos

Исследователи из компании Cybernews обнаружили утечку логинов и паролей от 16 миллиардов аккаунтов в различных популярных сервисах.
Слитый архив включает в себя данные учетных записей от Apple, Google, GitHub, Telegram, а также социальных сетей, VPN-сервисов и государственных платформ. Большинство этих наборов логинов и паролей являются новыми и ранее не публиковались.
Все базы данных находились в открытом доступе лишь короткое время, при этом один набор данных с более чем 455 млн записей был, судя по названию, связан с Россией.
По этой причине эксперты по кибербезопасности советуют пользователям немедленно сменить пароли для всех онлайн-аккаунтов, использовать менеджеры паролей и по возможности активировать многофакторную аутентификацию
https://cybernews.com/security/billions-credentials-exposed-infostealers-data-leak/

Шаблоны развёртывания приложения

Шаблоны развёртывания приложения (описание к предыдущему посту)

Шаблоны развертывания представляют автоматизированные методы внедрения новых функций в приложение. Выбранный способ развёртывания позволяет сократить время простоя, развертывать дополнительную функциональность, протестировать новые функции с небольшой группой пользователей, прежде чем сделать их доступными для широкой публики.
Существуют различные варианты развертывания:

𝟭. 𝗖𝗮𝗻𝗮𝗿𝘆 𝗿𝗲𝗹𝗲𝗮𝘀𝗲 (Канареечный релиз )
𝗖𝗮𝗻𝗮𝗿𝘆 𝗿𝗲𝗹𝗲𝗮𝘀𝗲 — это метод выявления потенциальных проблем до того, как они затронут всех потребителей. Перед тем как сделать новую функцию доступной для всех, мы планируем показать ее избранной группе пользователей. В подобном релизе мы отслеживаем результат после того, как функция становится доступной. Если в релизе есть проблемы, мы их устраняем. Как только стабильность релиза будет установлена, он переносится в фактическую производственную среду.

𝟮. 𝗕𝗹𝘂𝗲/𝗴𝗿𝗲𝗲𝗻 𝗱𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 (Синяя-зелёная схема развёртывания)
Здесь мы одновременно используем две похожие среды, минимизируя риски и время простоя. Эти среды называются синей и зелёной. Только одна среда активна в любой момент времени. В реализации сине-зелёного метода используется маршрутизатор или балансировщик нагрузки для контроля трафика. Синяя-зелёная схема развёртывания также предоставляет быстрый способ отката. Если что-то пойдёт не так в зелёной среде, мы переключаем маршрутизатор обратно на синюю среду.

𝟯. 𝗙𝗲𝗮𝘁𝘂𝗿𝗲 𝘁𝗼𝗴𝗴𝗹𝗲𝘀 (Управление функциями)
Здесь мы можем включить/выключить отдельные функции во время выполнения. Мы можем выпустить новое программное обеспечение, не подвергая наших пользователей другим совершенно новым или изменённым возможностям. Когда мы создаём новую функциональность, мы можем использовать переключение функций для обеспечения непрерывных выпусков путём разделения выпуска и развёртывания.

𝟰. 𝗔/𝗕-тестирование
Две версии приложения сравниваются с помощью A/B-тестирования, чтобы определить, какая из них работает лучше. В A/B тестировании мы случайным образом представляем пользователям две или более версий страницы. Затем мы используем статистический анализ, чтобы выяснить, какой вариант эффективнее достигает поставленных целей.

𝟱. Скрытый (Темный) запуск («Dark Launch»)
При «темном запуске» мы представляем новую функцию избранной группе пользователей, а не широкой публике. Эти пользователи не знают, что помогают нам тестировать функционал. Мы даже не указываем им на новый функционал. По этой причине он называется «темным запуском». Пользователей знакомят с программой, чтобы мы могли получить обратную связь и проверить ее эффективность.

Краткий совет по Linux:

Команда diff — полезный инструмент для поиска различий между файлами в терминале Linux. Однако icdiff предлагает еще лучшее сравнение бок о бок с цветным выводом.

$ icdiff config-1 config-2

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

В .NET 10, который выйдет в ноябре этого года, значительно оптимизируют работу с небольшими массивами. Так, если JIT может определить, что локальный массив достаточно мал и не выйдет за пределы области
видимости метода, то для этого массива выделяется место в стеке, а не в куче. Благодаря этому уменьшается потребляемая память и время на ее выделение.
#dotnet #csharp

Сгенерированный ИИ код в некоторых организациях составляет более половины кода, но большая часть этого попадает в производство практически без надзора.
Согласно отчету Cloudsmith Artifact Management Report 2025, «ИИ теперь пишет код в масштабах». Из тех разработчиков, которые используют ИИ, 42 процента заявили, что по крайней мере половина их кода сгенерирована ИИ.

Причем для 16,6% большую часть кода написал ИИ, а 3,6 процента заявили, что весь их код был сгенерирован машиной.
В отчете не указано, сколько разработчиков используют ИИ для генерации кода.

Но составители отчета предупреждают: «Хотя LLM повышают производительность, быстро генерируя код, они могут непреднамеренно вносить риски, рекомендуя несуществующие или вредоносные пакеты».

И разработчики прекрасно это осознают. На вопрос, усугубит ли ИИ угрозы вредоносного ПО с открытым исходным кодом (например, тайпосквоттинг, путаница с зависимостями), 79,2% считают, что ИИ увеличитколичество вредоносного ПО в средах, а 30% заявили, что это значительно увеличит подверженность вредоносному ПО.

Только 13% считают, что ИИ «предотвратит или уменьшит угрозы». А 40% заявили, что генерация кода является сферой, в которой ввод ИИ представлял наибольший риск.

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

https://devclass.com/2025/06/19/ai-is-generating-code-at-scale-but-human-scale-code-review-cant-keep-up/

AI Vs Machine Learning Vs Deep Learning Vs Generative AI

AI Vs Machine Learning Vs Deep Learning Vs Generative AI

1 — Artificial Intelligence (AI) / Искусственный Интеллект (ИИ)
Это общее направление исследований, целью которого является создание машин или систем, способных выполнять задачи, традиционно требующие человеческого интеллекта, такие как рассуждение, обучение, решение проблем и понимание языка. ИИ включает различные субдисциплины, включая Машинное Обучение, Обработку Естественных Языков (NLP), Робототехнику и Компьютерное Зрение.

2 — Machine Learning (ML) / Машинное Обучение
Является подразделением ИИ, сосредоточенным на разработке алгоритмов, позволяющих компьютерам учиться и принимать решения на основе данных. Вместо прямого программирования каждой отдельной задачи системы МО улучшают свою производительность, обрабатывая большие объемы данных. Примеры практического применения включают обнаружение спама, рекомендательные системы и аналитику прогнозирования.

3 — Deep Learning / Глубокое Обучение
Это специализированная область внутри Машинного Обучения, использующая искусственные нейронные сети с несколькими слоями для моделирования сложных закономерностей в данных. Нейронные сети представляют собой вычислительные модели, вдохновленные сетью нервных клеток мозга человека. Глубокие нейронные сети способны автоматически выявлять необходимые представления для последующего распознавания. Применение включает распознавание изображений и речи, обработку естественных языков и автономные транспортные средства.

4 — Generative AI / Генеративный ИИ
Относится к системам ИИ, способным создавать новый контент, такой как тексты, изображения, музыку или код, похожий на исходные данные, на которых они были обучены. Эти системы основаны на архитектуре трансформеров.
Известные генеративные модели включают GPT для генерации текста и DALL-E для создания изображений.

Обсуждая, как ИИ влияет на рабочие места, в частности, на «белых воротничков», аналитик рисков Ян Бреммер упомянул, как быстро технология обогнала традиционную траекторию карьеры программистов — настолько, что люди, которые раньше занимали прибыльную должность разработчика программного обеспечения, «теперь продают свою плазму, чтобы свести концы с концами».

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

В своем последнем отчёте о рынке труда Федеральный резерв Нью-Йорка обнаружил, что среди недавних выпускников колледжей, которые специализировались на информатике или компьютерной инженерии, теперь более высокий уровень безработицы, чем среди тех, кто изучал журналистику, политологию и даже английский язык.

В целом, по данным Федерального резервного банка Нью-Йорка, специалисты по компьютерным наукам оказались на седьмом месте по уровню безработицы — 6,1%, а специалисты по компьютерной инженерии — на третьем (7,5%). При этом средний уровень безработицы среди всех выпускников составляет 5,8%.
https://futurism.com/risk-expert-learn-to-code-face-tattoo

Как работает шардинг базы данных #database

Базовые 6 протоколов API (описание)

1 REST (Representational State Transfer / Передача состояния представления)
↳ Бестелесный протокол API, основанный на ресурсах, использующий стандартные методы HTTP
↳ Лучше всего подходит для: операций CRUD в веб-приложениях и мобильных приложениях
↳ Риск: избыточная выборка или недостаточная выборка данных из-за фиксированных конечных точек

2 gRPC (Google Remote Procedure Call / Удаленный вызов процедур Google)
↳ Высокопроизводительный контрактный протокол, использующий двоичный формат передачи данных
↳ Лучше всего подходит для: внутренней коммуникации микросервисов
↳ Риск: ограниченная поддержка браузерами

3 GraphQL
↳ Язык запросов API, позволяющий клиентам запрашивать конкретные данные
↳ Лучше всего подходит для: приложений с акцентом на фронтенде, имеющих сложные потребности в извлечении данных и требования к быстрому отклику
↳ Риск: проблемы производительности из-за чрезмерно гибких запросов

4 SOAP (Simple Object Access Protocol / Простой протокол доступа к объектам)
↳ Протокол обмена сообщениями, использующий спецификации XML с жесткими стандартами безопасности
↳ Лучше всего подходит для: корпоративных приложений, которым необходима высокая безопасность
↳ Риск: многословность и сложность из-за спецификаций XML

5 WebSocket
↳ Двунаправленный протокол реального времени поверх постоянного соединения TCP
↳ Лучше всего подходит для: приложений реального времени, таких как чаты или обновления спортивных новостей
↳ Риск: дополнительная логика обработки состояний соединений и повторных подключений

6 MQTT (Message Queuing Telemetry Transport / Транспорт сообщений очередей телеметрии)
↳ Легковесный протокол публикации-подписки
↳ Лучше всего подходит для: устройств интернета вещей (IoT) и датчиков
↳ Риск: сложные запросы и большие объемы данных могут плохо обрабатываться

Состоялась встреча Билла Гейтса и Линуса Торвальдса на совместном ужине, организованным Марком Руссиновичем
Лет 20-25 назад, особенно после того, как тогдашний СЕО Microsoft Стив Балмер назвал Linux «раковой опухолью», такое казалось невозможным.

Алгоритмическая сложность различных базовых структур данных