Месяц назад я попытался сосчитать, сколько разных инструкций поддерживается современными процессорами, и насчитал 945 в Ice Lake. Комментаторы затронули интересный вопрос: какая часть всего этого разнообразия реально используется компиляторами? Например, некто Pepijn de Vos в 2016 подсчитал, сколько разных инструкций задействовано в бинарниках у него в /usr/bin, и насчитал 411 — т.е. примерно треть всех инструкций x86_64, существовавших на тот момент, не использовались ни в одной из стандартных программ в его ОС. Другая любопытная его находка — что код для x86_64 на треть состоит из инструкций mov. (В общем-то известно, что одних инструкций mov достаточно, чтобы написать любую программу.)

Я решил развить исследование de Vos, взяв в качестве «эталонного кода» компилятор LLVM/Clang. У него сразу несколько преимуществ перед содержимым /usr/bin неназванной версии неназванной ОС:

1. С ним удобно работать: это один огромный бинарник, по размеру сопоставимый со всем содержимым /usr/bin среднестатистического линукса;
2. Он позволяет сравнить разные ISA: на releases.llvm.org/download.html доступны официальные бинарники для x86, ARM, SPARC, MIPS и PowerPC;
3. Он позволяет отследить исторические тренды: официальные бинарники доступны для всех релизов начиная с 2003;
4. Наконец, в исследовании компиляторов логично использовать компилятор и в качестве подопытного объекта :-)

Начну со статистики по мартовскому релизу LLVM 10.0:
В прошлом топике комментаторы упомянули, что самый компактный код у них получается для SPARC. Здесь же видим, что бинарник для AArch64 оказывается на треть меньше что по размеру, что по общему числу инструкций.

А вот распределение по числу инструкций:

2,4 ГГц — это плохо. 5 ГГц — это хорошо. 6 ГГц — это ещё лучше, но послезавтра. Все это знают, кого я тут учу, в самом деле. Всё это хорошо, только делать-то что, когда ты такой, как умный, открываешь какой-нибудь Wi-Fi Explorer, а там сатанизм и этажерки, как на скриншоте?



Шаг первый — поплакать. Шаг второй — нырнуть под кат. Вопрос простой, а ответ — нет.

Среди всего многообразия задач Computer Vision есть одна, которая стоит особняком. К ней обычно стараются лишний раз не притрагиваться. И, если не дай бог работает, — не ворошить.
У неё нет общего решения. Практически для каждого применения существующие алгоритмы надо тюнинговать, переобучать, или судорожно копаться в куче матриц и дебрях логики.

Статья о том как делать трекинг. Где он используется, какие есть разновидности. Как сделать стабильное решение.

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

• обеспечивать отказоустойчивость и избыточность;
• легко масштабироваться;
• просто и быстро решать задачу добавления и блокировки пользователей VPN;
• балансировать нагрузку между входными нодами;
• одинаково хорошо работать для клиентов на GNU/Linux, Mac OS X и Windows;
• поддерживать клиентов, которые находятся за NAT.

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

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

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

В этой статье расказано о преимуществах защищённого прокси перед VPN и предложены различные реализации, готовые к использованию.

Практически каждая коммерческая компания стремится к увеличению своей прибыли, один из способов ее увеличения – увеличение доходов при неизменности расходов или меньшем их росте в абсолютном значении. Для увеличения доходов авиакомпания может создавать новые направления, новые продукты (к примеру, сувенирная продукция или магазин беспошлинной торговли на борту самолета), дополнительные услуги (страховки, платный багаж и так далее), а также управлять ценой авиабилета для увеличения доходов.

wkhtmltopdf — это один из самых мощных инструментов для генерации PDF. Он позволяет использовать в генерируемом документе все возможности HTML и CSS. «Под капотом» у него движок WebKit, так что результат почти в точности соответствует выводу «Print to PDF», встроенному в Chrome. Судя по вопросам на Stack Overflow, wkhtmltopdf используется для генерации карт, графиков, бухгалтерских отчётов, подарочных сертификатов, и практически любого другого контента, который в конечном счёте должен оказаться распечатанным на бумаге.

Мой давний заказчик с помощью wkhtmltopdf генерирует PDF-инвойсы в своём веб-магазине. При печати в «шапке» инвойса должен отображаться чёрно-белый логотип, тогда как на сайте используется цветной. Очевидное решение — подменить изображение в CSS @media print { ... } Но тут обнаружилась проблема: если изображение не используется вне @media print, то оно не загружается и при печати (этот баг можно заметить и в окне Print Preview самого Chrome).

В 2017 году мы с семьёй переехали в Иннополис.

За 3 года жизни эйфория прошла и сформировалось какое-то устойчивое мнение об этом городе.

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

Меня никто не просил писать эту статью и тем более не платил за неё. В общем, это не заказная «приезжайте к нам, у нас тут классно». Пишу всё так, как вижу своими глазами.

Я несколько раз начинал читать статьи из серии «Введение в функциональное программирование», «Введение в Теорию Категорий» и даже «Введение в Лямбда Исчисление». Причем и на русском, и на английском. Каждый раз впечатление было очень сходным: во-первых, много новых непонятных слов; во-вторых, много новых определений, которые возникают из ниоткуда; в-третьих, совершенно непонятно, как это использовать.

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

Попытки использовать как-то в работе изученные концепции разбивались о полное непонимание, как применить полученное глубокое знание. Ведь, напомню, что парадигму ФП (где-то удобнее, где-то не очень, но) можно использовать практически в любом ЯП, совсем необязательно для этого изучать условный Хаскель.

На Хабре есть не только айтишники. Тут и электрики, и схемотехники, и химики, и маркетологи и кого только нет. И возможность переезда в другую страну в качестве специалиста широкого профиля интересна и им тоже. В довесок к истории Дудя и аналогичным статьям я хочу рассказать свою историю про переезд в США, на противоположный от Калифорнии берег с противоположной от IT профессии. Про жизнь, траты, поиск и смены работы и перспективы. Мне 36, я по образованию биотехнолог, семья — два человека, английский язык — так себе. Живу в Северной Каролине почти два года.

Поскольку написанного вышло много, вот короткая версия. При переезде практически гарантировано снижение социального статуса. Прожить можно на $1500. Средняя зарплата «неайтишника» $30к-50к в год. Средняя стоимость дома $200к. Получить медицинскую страховку бесплатно можно. Много плюшек от государства. Поиск нормальной работы очень нетривиален. Язык сам не учится, но есть бесплатные курсы. Жить комфортно. Наше образование никому не нужно. Очень многие мечтают о карьере в IT.

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

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

• всем кандидатам задавать одинаковые вопросы,
• вопросы должны быть такие, чтобы на них ответил и junior, и senior, но по разному,
• после трёх вопросов должен быть понятен уровень кандидата.

И вот такие три вопроса для Java-разработчиков у меня получились.

Я уволился из Яндекс.Маркета, отработав там почти 15 месяцев. Сегодня я хочу поделиться своим взглядом на работу в Яндекс.Маркете и рассказать о причинах ухода.

Disclaimer: эта статья бесполезна для тех, кто работает или работал в Маркете; она предназначена в первую очередь для тех, кто лишь планирует туда пойти. А ещё Яндекс.Маркет – это не Яндекс, но очень близко. Поэтому всё, о чём я буду говорить, в первую очередь относится к Маркету, но значительная часть из этого точно так же может быть применена к большому Яндексу.

Я ни в коем случае не претендую на объективность, это моё личное мнение.

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

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

Я провёл один из самых длительных своих тестов, занявший четыре месяца: измерил, как меняются характеристики светодиодных ламп через 500 и 1000 часов работы.

Я — инженер. Во-первых, по образу мышления, во-вторых, после выпуска из МГТУ им. Н.Э.Баумана, эта фраза стала мантрой. Я живу с постоянной потребностью изобретать и творить. Плюс в том, что работа в удовольствие и это плодотворно. Минус — из-за этого когнитивного смещения инженер в вакууме рискует вложить много ресурсов в продукт, который оказывается нужен только в его фантазиях.

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

Этой весной мы уже обсудили некоторые вводные темы, например, как проверить скорость ваших дисков и что такое RAID. Во второй из них мы даже пообещали продолжить изучение производительности различных многодисковых топологий в ZFS. Это файловая система следующего поколения, которая сейчас внедряется повсюду: от Apple до Ubuntu.

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

• Если что, я не имею к этой игре никакого отношения.

Например, игра с картинки выше не использовала floating-point числа, так как не все телефоны их поддерживали. "3д" и физика — полностью самописные на fixed-point вычислениях поверх целых чисел. Но мне кажется, перечисление особенностей одного приложения будет не сильно информативным. Для полноты картины я немного затрону возможности телефонов, j2me платформу и заодно сравню это с современной разработкой под Android.

Кроме того, j2me — это полноценная java старой версии (кажется, 1.3), я дописал некоторые недостающие классы и смог запустить .jar файлик с игрой на своём PC. Скриншот выше — оттуда. Не скажу, что от этого есть какая-то польза — просто API для j2me было очень простым и мне захотелось попробовать.

Долгое время Rust позиционировался исключительно как язык для системного программирования. Попытки использовать Rust для высокоуровневых прикладных задач зачастую вызывали усмешку у значительной части сообщества: зачем использовать инструмент в том качестве, на которое он не рассчитан? Какая польза от возни с типами и анализатором заимствований (borrow checker), если есть Python и Java со сборкой мусора? Но другая часть сообщества всегда видела потенциал Rust именно как языка прикладного, и даже находила его удобным в использовании для быстрого прототипирования — во многом благодаря его особенностям, а не вопреки им.

На прошлой неделе Microsoft выпустила пакетный менеджер WinGet в рамках анонсов на конференции Build 2020. Многие посчитали это ещё одним доказательством сближения Microsoft с движением Open Source. Но только не канадский разработчик Кейван Бейги (Keivan Beigi), автор свободного менеджера пакетов AppGet. Сейчас он силится понять, что произошло за последние 12 месяцев, в течение которых он общался с представителями Microsoft.

В любом случае, теперь Кейван прекращает разработку AppGet. Клиентские и серверные службы переходят в режим технического обслуживания немедленно до 1 августа 2020 года, после чего будут закрыты навсегда.

Привет, Хабр!

В нашем Tinkoff Security Operation Center мы регулярно занимаемся разбором техник, применяемых во вредоносном ПО и атаках, и недавно нам попался один интересный файл, о котором хотелось бы рассказать.

Меня давно занимала мысль как в Linux-е запускать программы на Java без вспомогательных Bash скриптов. Я не видел приемлемого решения, если не считать способ «bash script payload», когда в конец скрипта помещается бинарный файл.

Но на прошлой неделе случайно наткнулся на модуль ядра binfmt_misc, с помощью которого можно перехватить исполнение файла по его magic number. Для этого через update-binfmts добавляется собственный обработчик для получения имени исполняемого файла и аргументов пользователя.