Вашему вниманию представлен обзор статьи AdderNet: действительно ли нам нужно умножение в глубоком обучении?,

Ключевые моменты статьи:

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

По сравнению с умножением сложение намного дешевле и снижает затраты на вычисления.

Это статья CVPR 2020 года с более чем 20 упоминаниями в других источниках. (Sik-Ho Tsang @ Medium)

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

Поскольку это довольно строгий статически компилируемый язык, с первого взгляда может показаться, что Swift мало чего может предложить в плане кастомизации синтаксиса, но на самом деле это далеко не так. Благодаря таким фичам, как настраиваемые и перегруженные операторы, key paths, function/result builders и т. д., у нас есть множество возможностей для настройки синтаксиса Swift под конкретные сценарии использования.

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

В данной статье будет рассмотрено понятие сокета в операционной системе Linux: основные структуры данных, как они работают и можно ли управлять состоянием сокета с помощью приложения. В качестве практики будут рассмотрены инструменты netcat и socat.

День ото дня мы приближаемся к Agile-трансформации. Одна из самых важных целей для нас – увеличить velocity команд на X %. Слышали об этом? Слова Марка Андрессена о том, что «программное обеспечение пожирает мир», становятся отличительной чертой отраслей, которые раньше были менее автоматизированными.

Компания, занимающаяся разработкой Agile-продуктов, опросила более 18 000 клиентов и специалистов по разработке программного обеспечения.

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

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

С момента своего создания JavaScript всегда был ориентирован на создание инновационного пользовательского опыта (UX - User Experience). Он позволяет разработчикам создавать максимально интуитивно понятный и удобный UX под конкретную задачу.

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

Эта проблема не нова: она очень похожа на состояние Symfony в PHP до появления Symfony Flex. Нам нужен эквивалент Symfony Flex для JavaScript - инструмент способный создавать прекрасный пользовательский опыт так же быстро, как теперь мы можем настроить HTTP-клиент, почтовую программу или панель администрирования.

Периодически мои подписчики задают мне вопросы о том, как проводить микроархитектурный анализ в Windows? Если честно, это никогда не представляло для меня какой-то особой проблемы. Угадайте почему? Потому что я работаю в Intel и, конечно же, у меня есть лицензия для использования Intel® VTune™ Amplifier. Поэтому я не могу полностью прочувствовать боль людей, которые заняты работой, связанной с производительностью в Windows, и не имеют доступа к Vtune или AMD CodeAnalyst. Поскольку это не было для меня проблемой, я ничего не предпринимал для ее решения. Наконец, недавно я просматривал блог Бартека посвященный кодингу и наткнулся на статью «Любопытный случай с производительностью бранчинга». Мне это показалось случаем, который можно легко проверить, просто запустив perf stat, если бы мы работали в Linux. Но поскольку мы работаем в Windows… все не так просто.

В этой статье я хочу представить один из способов сбора PMU-счетчиков без Intel® VTune™ Amplifier. Почти всю необходимую информацию я взял из блога Брюса Доусона. Он написал статью, которую я хочу расширить и сделать ее более пошаговой. Т.е., все лавры здесь принадлежит Брюсу, потому что не я автор этой работы. Если вы хотите поэкспериментировать сами, я предлагаю вам сначала воспроизвести пример, описанный в статье Брюса (вот ссылка на github с исходниками и скриптами).

Однако не воспринимайте все, что написано в моей статье, за чистую монету. Я не Windows-разработчик и не трачу много времени на анализ производительности в Windows. Это всего лишь один из способов сбора PMU-счетчиков — могут быть и другие, более простые и надежные. В конце концов, вы всегда можете приобрести Intel® VTune™ Amplifier, который, кстати, может быть довольно дорогим. Но сразу хочу сказать, что, если вы собираетесь проводить серьезный анализ производительности и тюнинг в Windows, реальных альтернатив Vtune нет (и это не реклама).

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

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