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

Для того, чтобы уменьшить размер обновлений, разработчики Android еще в июне 2016 года стали применять алгоритм bsdiff за авторством Колина Персиваля для патча бинарных файлов. Тогда это помогло снизить размер приложений и обновлений к ним, в среднем, на 47% относительно полного APK.

Теперь же команда Android хочет поделиться новым решением, которое позволяет снизить объем обновлений на, в среднем, 65% от первоначального размера. Речь идет о File-by-file patching.

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


Ось Х — дни с момента запуска, ось Y — мультипликатор цены;

Крипто-блогер Вилли Ву недавно опубликовал пост с неплохим анализом 118 различных альткойнов (альткойн — «альтернатива Биткойну», любая криптовалюта кроме биткойна), которым удалось достичь рыночной капитализации в 250 тысяч $ и более и сравнил их графики роста с графиком роста биткойна. График на логарифмической шкале показывает изменение стоимости каждой криптовалюты с момента начала торгов. Биткойн впервые вышел на открытые торги в июле 2010 года на бирже MtGox (светлая ей память). Спустя 1300 дней со старта он торговался по цене в 10 000 раз выше изначальной. Пузырь лопнул вместе с самой MtGox, и только сейчас биткойн снова подбирается к тому же уровню.

Доброго времени суток. В этой статье расскажу о создании системы в которой генетические алгоритмы пишут роботов. В теории эти роботы могли бы торговать на бирже.

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

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

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

Как человеку любознательному, всегда было интересно, можно ли сделать процесс настройки шейпинга для небольших сетей проще? Можно ли хотя бы грубо детектировать важный трафик и отделять его от неважного без DPI и сигнатурного анализа? Можно ли шейпить трафик в любых направлениях без создания псевдо-интерфейсов или добавления модулей в ядро? И вот, после некоторых размышлений и гуглежа, решил написать простой шейпер в userspace. Чтоб попробовать ответить на вопросы экспериментом.

Человек издревле пытался понять устройство окружающего его мира и найти свое место в нем. Упорство и изобретательность его разума в течение тысяч лет приближали человека к объективному пониманию мира вопреки закрепленному культурой субъективному (не редко ложному) восприятию. Одной из первых задач к достижению этих целей является определение масштабов окружающего нас мира.

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

В этой серии из двух статей говорится о том, как структура данных и памяти влияет на производительность. Предлагаются определенные действия для повышения производительности программного обеспечения. Даже простейшие действия, показанные в этих статьях, позволят добиться существенного прироста производительности. Многие статьи, посвященные оптимизации производительности программ, рассматривают распараллеливание нагрузки в следующих областях: распределенная память (например, MPI), общая память или набор команд SIMD (векторизация), но на самом деле распараллеливание необходимо применять во всех трех областях. Эти элементы очень важны, но память также важна, а про нее часто забывают. Изменения архитектуры программ и применение параллельной обработки влияют на память и на производительность.

А не замахнуться ли нам на Эдсгера нашего Дейкстру?

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

В общем случае минимизируемая величина — это необязательно расстояние, — весами ребер графа могут быть стоимости, штрафы, убытки, времена, — любые величины, которые можно складывать. Задача является классической, наиболее простой алгоритм поиска кратчайшего пути дал Э. Дейкстра в 1959 году.

… Молвит он: «Коль жив я буду, чудный остров навещу, у Гвидона погощу».

В царстве Салтана не без изьяна. Принят закон — не лезть за кордон, да тут князь Гвидон.
Опять прислал поклон, да приглашение на угощение,- надо принимать политическое решение.

Дворцовые интриганки, похожие на поганки, встали стеной — «мол, скажи, что больной». Но прослышал Салтан про Гвидонов кальян, про изумрудную белку, да богатырскую стрелку. А главная новинка — молодая жинка. В общем, ехать решено — «Я не был за морем давно».

Было однако одна проблема,- нужен был маршрут или схема. Поскольку никто (кроме Врангеля барона) не знал, как добраться до острова Гвидона. Корабельщики дали карту,- пришлось сесть за парту. Над картой склонился Салтан, — где тут остров Буян? Задача была как будто знакома — проложить путь к острову Гвидона. Но как найти дорогу, когда путей слишком много?

До ночи решал Салтан задачку, в итоге свалился в спячку. Снились ему матрицы и точки, да на болоте кочки. На кочку прыгнул Нео с острова Борнео.
— Если хочешь добраться ко сроку — плыви по максимальному потоку.
— Чего? — Салтан почти проснулся. Но Нео уже в зайца обернулся.

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

Создатель сайта Turing Finance и аналитик хедж-фонда NMRQL Стюарт Рид опубликовал интересный материал на тему анализа возможных рисков использования финансовых моделей. В материале рассматриваются несколько факторов, влияющих на возникновения рисков — то есть вероятности финансовых потерь при использовании модели. Мы представляем вашему вниманию главные моменты этой работы.

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

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

Доброго времени чтения, уважаемые пользователи Хабра! Игра Жизнь предложена Джоном Конвеем в 1970 году, и неоднократно обсуждалась на habrahabr.ru. Основные использованные теги приведены в метках к данной статье.

Предлагается ряд изменений, которые могут привести к новому направлению в развитии.

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

Отныне я не буду больше создавать нативные приложения. Все мои приложения в дальнейшем будут прогрессивными веб-приложениями (PWA, Progressive Web Apps). Это такие приложения, которые предназначены для еще более органичной работы на мобильных устройствах, чем нативные приложения.

Что я имею ввиду под «более органичной работой»? Большая часть веб-траффика исходит от мобильных устройств и пользователи устанавливают в среднем от 0 до 3 новых приложений в месяц. Это означает, что люди не тратят много времени на поиск новых приложений в App store, но они проводят много времени в сети, где могут найти и использовать ваше приложение.

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

Часто при поиске ответа на вопрос, как сделать ту или иную до этого незнакомую вещь, программист знакомится с опытом коллег. И довольно часто у нас, во фронтенд-разработке, можно увидеть советы следующего содержания: мол, просто подключи ту или иную библиотеку, просто поставь тот или иной плагин, просто перепиши проект на Ангуляре (просто_на_Ангуляре ))) ), и не надо забивать себе голову посторонними вещами.

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

Купили ли вы уже себе новый MacBook или MacBook Pro? А может, Google Pixel? Вы находитесь на пороге путаницы, благодаря этим новым портам «USB-C». Этот простецкий на вид порт таит в себе вселенскую путаницу, и благословенная обратная совместимость использует различные кабели для различных задач. Покупателям придётся очень аккуратно выбирать себе кабель!

USB Type-C: порты и протоколы

Порты USB Type-C распространились достаточно широко, Google начал использовать их на своих компьютерах и телефонах Pixel и Nexus, Apple применяет их на 12" MacBook, а теперь ещё и на новых MacBook Pro. Это физическая спецификация для 24-контактного двустороннего штекера и соответствующих кабелей. В этой статье я буду называть этот физический кабель и порт «USB-C», как наиболее часто используемый термин. Google сообщает, что этот порт называют «USB-C» 21 миллион раз, «USB C» 12 миллионов раз, а правильно, «USB Type-C», всего 8,5 миллионов раз.

Впервые вплотную познакомиться с очень старым железом мне довелось около года назад, когда по рабочей необходимости пришлось вытаскивать данные со старого программатора Siemens PG685, работающего под операционной системой CP/M-86 2.1 с MFM HDD и 5,25 FDD 720kb. Данные тогда удалось перенести и считать на современный комп с помощью OmniFlop, но желание поработать с MFM накопителями и по возможности снять посекторную копию HDD c сименса осталось. И вот, совершенно случайно, у товарища по походам был найден уже выброшенный(выставленный в подъезд) дектоскопный 286й с 16битным MFM контроллером и 8битной CGA видеокартой.

Протокол QUIC (название расшифровывается как Quick UDP Internet Connections) — совершенно новый способ передачи информации в интернете, построенный поверх протокола UDP, вместо общепринятого ранее использования TCP. Некоторые люди называют его (в шутку) TCP/2. Переход к UDP — наиболее интересная и мощная особенность протокола, из которой следуют некоторые другие особенности.

Сегодняшний Web построен на протоколе TCP, который был выбран за его надёжность и гарантированность доставки пакетов. Для открытия TCP-соединения используется так называемое «трёхкратное рукопожатие». Это означает дополнительные циклы отправки-приёма сообщений для каждого нового соединения, что увеличивает задержки.


Если вы захотите установить защищённое TLS-соединение, придётся переслать ещё больше пакетов.


Некоторые инновации, вроде TCP Fast Open, улучшат некоторые аспекты ситуации, но эта технология пока не очень широко распространена.

Протокол UDP, с другой стороны, построен на идее «отправить пакет и забыть о нём». Сообщение, отправленное по UDP, будет доставлено получателю (не гарантированно, с некоторой вероятностью успеха). Яркое преимущество здесь в меньшем времени установки соединения, такой же яркий недостаток — негарантированность доставки или порядка прихода пакетов получателю. Это означает, что для обеспечения надёжности придётся построить некоторый механизм поверх UDP, который гарантирует доставку пакетов.

И здесь на сцену выходит QUIC от Google.

Добрый день, дорогие читатели сайта Geektimes! Волею судеб так случилось, что мне в руки попала очень интересная плата — LattePanda.

Что в ней интересного?

Как минимум то, что это x86_64, Windows, совмещенный с Arduino набор (прямо на одной плате) и выходы на массу сенсоров. Чрезвычайно необычное сочетание для современного засилья ARM SoC/Linux/GPIO решений, которые в итоге похожи на клубок проводов, если собрать на них тот же комплект.

Если Windows для вас — дом родной, то вот он, настоящий самородок в мире микрокомпьютеров. Я постараюсь написать то, что мне показалось интересным в этой платформе.

Как устроена загрузка современных ОС? Как при установке системы настроить загрузку посредством UEFI, не утонув в руководствах и ничего не сломав?

Я обещал "самое краткое руководство". Вот оно:

1. Создаём на диске таблицу разделов GPT
2. Создаём FAT32-раздел на пару сотен мегабайт
3. Скачиваем из интернета любой UEFI-загрузчик
   (нам нужен сам загрузчик, это один бинарный файл!)
4. Переименовываем и кладем этот файл на созданный раздел по адресу /EFI/Boot/bootx64.efi
5. Создаём текстовый конфиг, кладем его там, где загрузчик ожидает его увидеть
   (настройка и местоположение конфига зависят от конкретной реализации загрузчика, эта информация доступна в интернете)
6. После перезагрузки видим меню загрузчика
   (Если на диске установлена Windows 8 или 10 — с большой вероятностью это руководство сокращается до пунктов 3 — 5.)

TL;DR не надо прописывать путь к загрузчику в новых загрузочных записях UEFI — надо файл загрузчика расположить по стандартному "пути по-умолчанию", где UEFI его найдет, и вместо загрузочного меню UEFI пользоваться меню загрузчика, которое гораздо проще и безопаснее настраивается