Сколько помню, он всегда из коробки работал. Другое дело, что у альсы обычно фиксированная задержка (latency), на встроенном звуке порядка 20-25 мс, а у пульсы она динамическая, вплоть до 0.5 мс. Но там хватает своих проблем, например, если ядро не PREEMPT, даже со всеми реалтаймовыми и высокоприоритетными хаками пульса порой скипает, т.е. буфер опустошается, и слышен щелчок. При этом пульса начинает адаптироваться и увеличивать внутренние вотермарки и минимальную задержку. Если проц был сильно нагружен, то задержка может прыгнуть очень высоко, вплоть до 100-160 мс, и что интересно, механизмов автоматического её снижения, а также задания отличного от 0.5 мс минимума в коде нет, я смотрел (можно задать фиксированную задержку, как в альсе, но динамическая всегда начинается от 0.5). Задержка сбросится только после перезапуска демона.
Я чисто из-за этих трюков собираю собственное ядро с CONFIG_PREEMPT и таймером 1000 Гц, потому что в дебиане 100 Гц без преемптивности. Раньше долго сидел на альсе, но пульса в итоге пролезла везде и победила, да и стримить с ней куда проще, чем городить лупбэки.
Там ещё учитывается «возраст» монет, т.е. насколько давно была проведена транзакция, которая используется в качестве входа в данную. Я думаю, с ростом курса биткоина комиссия будет пропорционально снижаться, формулу расчёта уже неоднократно меняли с учётом реального использования. Так что когда-то станет достаточно выгодно слить эти старые и мелкие монеты воедино, да и не такие уж мелкие они могут быть в тот момент.
Пожалуй, реально утерянными можно считать монеты, переведённые на явно искусственный адрес, типа 1AAAAAAAA...AAA26 какой-нибудь, последние разряды — контрольная сумма, их можно подобрать, но если вся остальная часть слишком «красивая», вряд ли существует известный ключ, дающий такой хэш. Таким путём, например, сжигали «премайн» на некоторых криптовалютах, чтобы вернуть доверие людей. Просто отсылали на хэш, который считается от публично доступных данных типа первой страницы «Войны и мира». Подобрать публичный ключ совсем другой длины (целая страница слишком большая, чтобы использоваться в качестве ключа), дающий такой же хэш, да ещё и приватный для него, не представляется возможным, так что с близкой к 100% вероятностью монеты уже не вернуть.
Так что тут даже не так важны типы процессоров. Разве что найдутся скрытые доселе закономерности в ключах или хэшах, например, из-за уязвимостей ГСЧ, ECDSA или SHA-256. Но я сомневаюсь, что они будут фатальными, т.е. сократят время на подбор на десятки порядков (хотя ECDSA тут первый кандидат, т.к. его стойкость математически не доказана, но это характерно для NP-задач). А если алгоритм ослабнет лишь в несколько раз, технически нет проблем перейти на новый алгоритм шифрования/хэширования с сохранением обратной совместимости. Люди просто создадут новые адреса и переведут деньги на них.
Но если в транзакциях разглашать публичный ключ адреса только при исходящей операции и использовать адрес лишь однократно, то ECDSA перестаёт быть потенциальным вектором атаки, остаётся лишь SHA-256, который куда более прост для анализа.
Я думаю, в случае Meson этот подход не имеет смысла, т.к. у него, в отличие от Maven, нет единого репозитория зависимостей и индекса с версиями, поэтому найти «последнюю» версию на основе предложенной неточной не получится. Нужно указывать прямую ссылку на архив или коммит. В случае с git, возможно, прокатит резолв по тегам, но не факт, что будет работать стабильно — теги все оформляют по-разному.
Я имел ввиду локальный кеш, т.е. репозитории втягиваются в подпапки какой-то папки в домашнем каталоге пользователя. Если репозиторий уже есть — его никто не тянет повторно.
Можно завести issue, но что-то мне подсказывает, что в реалиях C++ это создаст больше проблем, чем решит, могу быть неправ. Часто используемые библиотеки и репозитории вообще имеет смысл захостить локально в организации или на своём сервере, а там уже время доступа не будет особой роли играть.
Разве Meson не умеет писать lock-файл с конкретными версиями зависимостей? Этот подход как раз и придумали чтобы иметь мягкое задание версий зависимостей и при этом воспроизводимые билды.
Можете раскрыть, что подразумевается под мягким заданием версий и lock-файлами?
Похоже на то, как делает Maven, который я очень люблю и уважаю за практически беспроблемную сборку с нуля, в том числе на пустых новых системах, где есть только JDK и собственно мавен. Сам скачает, сам скомпилит, главное, чтобы сеть работала и всё было в актуальном состоянии. Увы, для C++ такой подход не работает по фундаментальным причинам. В Java байткод запускается на любой платформе, чем язык и ценен, а у C++ имеется большой набор факторов несовместимостей: версия компилятора, его разновидность (Clang/G++/Borland/...), версия стандарта языка (98, 11, 14, 17), способ связи с внешними зависимостями (статическая линковка, динамическая, рантаймовая через dlopen/LoadLibrary/...) и, возможно, другие. Всё это порождает несовместимые ABI, число комбинаций которых быстро выходит из-под контроля. В Google давно поняли эти нюансы и сделали свой инструмент Bazel, который собирает абсолютно все библиотеки с нуля, так что получается предсказуемый и стабильный билд, но он как-то не очень популярен за пределами гугла, и с зависимостями у него тоже не всё гладко. В этом аспекте бинарный сетевой кэш Conan не выглядит сильно привлекательным — помимо и так немалого числа проблем при сборке проекта добавятся ещё и потенциальные нюансы собранных мейнтейнерами библиотек. Лучше уж всё качать в исходниках и собирать на локальной машине (я знаю, что Conan так может, но это не дефолтное поведение).
Это к тому, что общий кэш и общие результаты компиляции, при всей их удобности, не всегда лучшее решение, особенно, в больших проектах. Инвалидация кэша — одна из сложнейших задач, как известно, так что не факт, что сэкономленное на сборке время пойдёт действительно в плюс, когда проект перестанет собираться из-за обновления компилятора. Транзитивные зависимости — тоже головная боль, ведь в этом случае одна библиотека может оказаться двух разных версий по двум путям зависимостей. Maven в этом случае предпочитает более новую автоматически, но если таких случаев много, за всеми не уследишь, и это может ВНЕЗАПНО породить проблемы на ровном месте (обновил библиотеку, а по её пятому колену зависимостей какая-то библиотека обновила свою зависимость, которая перекрыла такую же у другой, и всё превратилось в кашу).
В Meson с этим строго: все зависимости, включая транзитивные, должны явно прописываться в корневом проекте, это гарантирует, что всё будет собрано однократно и иметь одну версию. Подход не без явных минусов, но гарантии такого рода на деле важнее неудобств при обновлении библиотек.
Автосборка и выдача результатов как раз имеется в Meson, хотя и не стандартизована — subproject экспортирует две переменные, обычно inc и lib, которые достаточно добавить в проект верхнего уровня. Система добавит нужные флаги для инклудов и линковки с учётом всех путей до субпроекта, это реально удобно и работает! Вообще, меня Meson подкупил именно системой Wrap, которая сколь проста, столь и эффективна, хотя можно спорить, должна ли система сборки иметь управление зависимостями. Но сделали хорошо и надёжно, почему бы и нет.
Судя по доке, врапперы нельзя накладывать на репозитории исходников, только на архивы.
Да:
Note that in this case you cannot specify an extra patch file to use. The git repo must contain all necessary Meson build definitions.
Но нет большой проблемы организовать свой форк на том же гитхабе (или сервере организации), где сразу держать meson.build и обновлять его по мере необходимости при изменениях в апстриме, а во wrap-файл писать нужный коммит.
В этом плане хорошо сделали в Meson, он поддерживает как архивы исходников, так и коммит из git + дополнительно наложение патчей. К сожалению, патчи нужны практически всегда, т.к. зависимостью может быть только такой же Meson-проект. С другой стороны, скрипты для сборки намного проще и нагляднее, чем у CMake, так что портировать несложные библиотеки можно быстро.
А у Conan, вроде, всё есть тоже, вот из примера в документации:
О, спасибо, вот эту информацию я как-то и не мог найти. В частности, чем же отличается preemptive kernel от обычного, вроде, везде уже в современных ОС многозадачность не кооперативная. А preemptive я лично собираю, потому что без него в PulseAudio появляются ощутимые скипы, теперь понятно, откуда это всё. Хотя линукс без патчей и не является ОСРВ, эти концепции подходят.
Я правильно понимаю, что при таймере с частотой 1000 Гц потоку гарантируется максимум в 1 мс времени каждую секунду, но если он в состоянии S, то переключение, фактически, произойдёт намного быстрее, и неиспользованное время достанется другим потокам, выполняющим код? Ну это при условии, что у всех потоков равный приоритет, конечно. А при неравных кто-то, у кого приоритет выше, может получить заведомо больше одного тика?
Вообще, я думал, таймер и квант выполнения не связаны и отличаются на порядки. Например, в Debian ядро собирают с таймером 100 Гц, неужели там настолько крупные кванты, по 10 мс?
Какие-то узлы всё равно должны быть первыми, когда клиент запускается первый раз и вообще никого не знает. В DHT точно так же, например, часто в качестве бутстрап-ноды используется router.utorrent.com и router.bittorrent.com. Конечно, если спецслужбы контролируют большинство этих нод, можно «заманить» новых клиентов в подконтрольный им кластер, но вообще это маловероятно. Скорее всего, бутстрап-адреса раскиданы по всему миру, и клиент выбирает из них несколько случайных, чтобы снизить вероятность описанной ситуации.
Есть список захардкоженных узлов (раньше для сбора этих узлов применялся IRC-канал, теперь же там DNS-имена), к которым подключается новый узел, в протоколе определены сообщения типа «запросить другие известные узлы», и те захардкоженные (бутстрап-ноды) сообщают запросившему случайно выбранные адреса из известных им (т.е. адреса других к ним когда-либо подключавшихся). Обычно принимается модель «малого мира», когда каждый узел подключен к небольшому числу других, 8-20 примерно, но в целом получается достижимость от любого узла к любому через цепочку. Это позволяет оптимизировать трафик и, наверно, уменьшить вероятность кластеризации. Трафик оптимизируется, т.к. если узел получает уже пересланное им сообщение (через кольцо других узлов), он его снова не будет перепосылать, и если бы он был связан с большим числом узлов, такое «эхо» было бы намного сильнее.
Далее, когда блок намайнен, майнер его просто посылает подключенным к нему узлам, если не ошибаюсь, даже не всем сразу, а 3-4 случайно выбранным из них. Они рассылают своим «соседям» и т.д., в итоге, вся сеть получает новые данные через некоторое время. Но не принимайте мои слова на веру, я давно это всё читал и мог некоторые вещи забыть или исказить. Вообще, с удовольствием бы почитал про низкоуровневую архитектуру крупных P2P-сетей и как там решаются разного рода проблемы. Например, мне совсем неочевидно, как можно гарантировать полную связность, т.е. отсутствие обособленных островков, ни один из пиров в которых не соединён с остальной частью сети. Скорее всего, это объясняется через вероятности, но оно не очевидно.
Да, это удобнее. Но модальные режимы всё равно не выглядят для меня привлекательными, т.к. не вижу задач, где требовалась бы именно набивка больших объёмов текста с максимальной скоростью.
У меня так мизинец не выгибается, чтобы до [ достать, я обычно «х» жму безымянным, смещая руку. А в описанном сценарии проблема именно с промахами, так что тут можно ещё сильнее усугубить. А Esc всегда в углу клавиатуры.
Нет, я использую только его, но для мелких вещей типа правки конфигов. Другие редакторы просто ещё хуже, а тут хотя бы можно строку удалить быстро. В IDE, конечно, ещё быстрее (Ctrl-D вместо Esc,d,d), но для конфигов запускать её — оверкилл.
Для меня режимы — это главный минус vim. Печатаю я, конечно, вслепую и давно, но иногда всё же промахиваюсь. При наборе текста это не проблема, удалил символ, написал новый. Но когда в виме я в нормальном режиме, начинается то самое «пищит и портит». Остаётся судорожно жать Esc несколько раз, чтобы точно там не набилось невидимых команд в буфер.
С UB бывают всякие «весёлые» эффекты. Например, null reference может быть одновременно == 0 и != 0, может быть равна другой такой же ссылке или не равна, в зависимости от версии компилятора и флагов оптимизации: пришлось рефакторить всю систему обработки ошибок. Простое правило: если вы полагаетесь на UB, вы добавляете в код немного святого рандома. Каждый компилятор вправе превратить этот код во что угодно, и он превратит. Garbage in => garbage out.
Сколько помню, он всегда из коробки работал. Другое дело, что у альсы обычно фиксированная задержка (latency), на встроенном звуке порядка 20-25 мс, а у пульсы она динамическая, вплоть до 0.5 мс. Но там хватает своих проблем, например, если ядро не PREEMPT, даже со всеми реалтаймовыми и высокоприоритетными хаками пульса порой скипает, т.е. буфер опустошается, и слышен щелчок. При этом пульса начинает адаптироваться и увеличивать внутренние вотермарки и минимальную задержку. Если проц был сильно нагружен, то задержка может прыгнуть очень высоко, вплоть до 100-160 мс, и что интересно, механизмов автоматического её снижения, а также задания отличного от 0.5 мс минимума в коде нет, я смотрел (можно задать фиксированную задержку, как в альсе, но динамическая всегда начинается от 0.5). Задержка сбросится только после перезапуска демона.
Я чисто из-за этих трюков собираю собственное ядро с CONFIG_PREEMPT и таймером 1000 Гц, потому что в дебиане 100 Гц без преемптивности. Раньше долго сидел на альсе, но пульса в итоге пролезла везде и победила, да и стримить с ней куда проще, чем городить лупбэки.
Там ещё учитывается «возраст» монет, т.е. насколько давно была проведена транзакция, которая используется в качестве входа в данную. Я думаю, с ростом курса биткоина комиссия будет пропорционально снижаться, формулу расчёта уже неоднократно меняли с учётом реального использования. Так что когда-то станет достаточно выгодно слить эти старые и мелкие монеты воедино, да и не такие уж мелкие они могут быть в тот момент.
Пожалуй, реально утерянными можно считать монеты, переведённые на явно искусственный адрес, типа 1AAAAAAAA...AAA26 какой-нибудь, последние разряды — контрольная сумма, их можно подобрать, но если вся остальная часть слишком «красивая», вряд ли существует известный ключ, дающий такой хэш. Таким путём, например, сжигали «премайн» на некоторых криптовалютах, чтобы вернуть доверие людей. Просто отсылали на хэш, который считается от публично доступных данных типа первой страницы «Войны и мира». Подобрать публичный ключ совсем другой длины (целая страница слишком большая, чтобы использоваться в качестве ключа), дающий такой же хэш, да ещё и приватный для него, не представляется возможным, так что с близкой к 100% вероятностью монеты уже не вернуть.
Так что тут даже не так важны типы процессоров. Разве что найдутся скрытые доселе закономерности в ключах или хэшах, например, из-за уязвимостей ГСЧ, ECDSA или SHA-256. Но я сомневаюсь, что они будут фатальными, т.е. сократят время на подбор на десятки порядков (хотя ECDSA тут первый кандидат, т.к. его стойкость математически не доказана, но это характерно для NP-задач). А если алгоритм ослабнет лишь в несколько раз, технически нет проблем перейти на новый алгоритм шифрования/хэширования с сохранением обратной совместимости. Люди просто создадут новые адреса и переведут деньги на них.
Но если в транзакциях разглашать публичный ключ адреса только при исходящей операции и использовать адрес лишь однократно, то ECDSA перестаёт быть потенциальным вектором атаки, остаётся лишь SHA-256, который куда более прост для анализа.
Я думаю, в случае Meson этот подход не имеет смысла, т.к. у него, в отличие от Maven, нет единого репозитория зависимостей и индекса с версиями, поэтому найти «последнюю» версию на основе предложенной неточной не получится. Нужно указывать прямую ссылку на архив или коммит. В случае с git, возможно, прокатит резолв по тегам, но не факт, что будет работать стабильно — теги все оформляют по-разному.
Можно завести issue, но что-то мне подсказывает, что в реалиях C++ это создаст больше проблем, чем решит, могу быть неправ. Часто используемые библиотеки и репозитории вообще имеет смысл захостить локально в организации или на своём сервере, а там уже время доступа не будет особой роли играть.
Можете раскрыть, что подразумевается под мягким заданием версий и lock-файлами?
Похоже на то, как делает Maven, который я очень люблю и уважаю за практически беспроблемную сборку с нуля, в том числе на пустых новых системах, где есть только JDK и собственно мавен. Сам скачает, сам скомпилит, главное, чтобы сеть работала и всё было в актуальном состоянии. Увы, для C++ такой подход не работает по фундаментальным причинам. В Java байткод запускается на любой платформе, чем язык и ценен, а у C++ имеется большой набор факторов несовместимостей: версия компилятора, его разновидность (Clang/G++/Borland/...), версия стандарта языка (98, 11, 14, 17), способ связи с внешними зависимостями (статическая линковка, динамическая, рантаймовая через dlopen/LoadLibrary/...) и, возможно, другие. Всё это порождает несовместимые ABI, число комбинаций которых быстро выходит из-под контроля. В Google давно поняли эти нюансы и сделали свой инструмент Bazel, который собирает абсолютно все библиотеки с нуля, так что получается предсказуемый и стабильный билд, но он как-то не очень популярен за пределами гугла, и с зависимостями у него тоже не всё гладко. В этом аспекте бинарный сетевой кэш Conan не выглядит сильно привлекательным — помимо и так немалого числа проблем при сборке проекта добавятся ещё и потенциальные нюансы собранных мейнтейнерами библиотек. Лучше уж всё качать в исходниках и собирать на локальной машине (я знаю, что Conan так может, но это не дефолтное поведение).
Это к тому, что общий кэш и общие результаты компиляции, при всей их удобности, не всегда лучшее решение, особенно, в больших проектах. Инвалидация кэша — одна из сложнейших задач, как известно, так что не факт, что сэкономленное на сборке время пойдёт действительно в плюс, когда проект перестанет собираться из-за обновления компилятора. Транзитивные зависимости — тоже головная боль, ведь в этом случае одна библиотека может оказаться двух разных версий по двум путям зависимостей. Maven в этом случае предпочитает более новую автоматически, но если таких случаев много, за всеми не уследишь, и это может ВНЕЗАПНО породить проблемы на ровном месте (обновил библиотеку, а по её пятому колену зависимостей какая-то библиотека обновила свою зависимость, которая перекрыла такую же у другой, и всё превратилось в кашу).
В Meson с этим строго: все зависимости, включая транзитивные, должны явно прописываться в корневом проекте, это гарантирует, что всё будет собрано однократно и иметь одну версию. Подход не без явных минусов, но гарантии такого рода на деле важнее неудобств при обновлении библиотек.
Автосборка и выдача результатов как раз имеется в Meson, хотя и не стандартизована — subproject экспортирует две переменные, обычно inc и lib, которые достаточно добавить в проект верхнего уровня. Система добавит нужные флаги для инклудов и линковки с учётом всех путей до субпроекта, это реально удобно и работает! Вообще, меня Meson подкупил именно системой Wrap, которая сколь проста, столь и эффективна, хотя можно спорить, должна ли система сборки иметь управление зависимостями. Но сделали хорошо и надёжно, почему бы и нет.
Да:
Но нет большой проблемы организовать свой форк на том же гитхабе (или сервере организации), где сразу держать meson.build и обновлять его по мере необходимости при изменениях в апстриме, а во wrap-файл писать нужный коммит.
В этом плане хорошо сделали в Meson, он поддерживает как архивы исходников, так и коммит из git + дополнительно наложение патчей. К сожалению, патчи нужны практически всегда, т.к. зависимостью может быть только такой же Meson-проект. С другой стороны, скрипты для сборки намного проще и нагляднее, чем у CMake, так что портировать несложные библиотеки можно быстро.
А у Conan, вроде, всё есть тоже, вот из примера в документации:
О, спасибо, вот эту информацию я как-то и не мог найти. В частности, чем же отличается preemptive kernel от обычного, вроде, везде уже в современных ОС многозадачность не кооперативная. А preemptive я лично собираю, потому что без него в PulseAudio появляются ощутимые скипы, теперь понятно, откуда это всё. Хотя линукс без патчей и не является ОСРВ, эти концепции подходят.
Я правильно понимаю, что при таймере с частотой 1000 Гц потоку гарантируется максимум в 1 мс времени каждую секунду, но если он в состоянии S, то переключение, фактически, произойдёт намного быстрее, и неиспользованное время достанется другим потокам, выполняющим код? Ну это при условии, что у всех потоков равный приоритет, конечно. А при неравных кто-то, у кого приоритет выше, может получить заведомо больше одного тика?
Вообще, я думал, таймер и квант выполнения не связаны и отличаются на порядки. Например, в Debian ядро собирают с таймером 100 Гц, неужели там настолько крупные кванты, по 10 мс?
Какие-то узлы всё равно должны быть первыми, когда клиент запускается первый раз и вообще никого не знает. В DHT точно так же, например, часто в качестве бутстрап-ноды используется router.utorrent.com и router.bittorrent.com. Конечно, если спецслужбы контролируют большинство этих нод, можно «заманить» новых клиентов в подконтрольный им кластер, но вообще это маловероятно. Скорее всего, бутстрап-адреса раскиданы по всему миру, и клиент выбирает из них несколько случайных, чтобы снизить вероятность описанной ситуации.
Есть список захардкоженных узлов (раньше для сбора этих узлов применялся IRC-канал, теперь же там DNS-имена), к которым подключается новый узел, в протоколе определены сообщения типа «запросить другие известные узлы», и те захардкоженные (бутстрап-ноды) сообщают запросившему случайно выбранные адреса из известных им (т.е. адреса других к ним когда-либо подключавшихся). Обычно принимается модель «малого мира», когда каждый узел подключен к небольшому числу других, 8-20 примерно, но в целом получается достижимость от любого узла к любому через цепочку. Это позволяет оптимизировать трафик и, наверно, уменьшить вероятность кластеризации. Трафик оптимизируется, т.к. если узел получает уже пересланное им сообщение (через кольцо других узлов), он его снова не будет перепосылать, и если бы он был связан с большим числом узлов, такое «эхо» было бы намного сильнее.
Далее, когда блок намайнен, майнер его просто посылает подключенным к нему узлам, если не ошибаюсь, даже не всем сразу, а 3-4 случайно выбранным из них. Они рассылают своим «соседям» и т.д., в итоге, вся сеть получает новые данные через некоторое время. Но не принимайте мои слова на веру, я давно это всё читал и мог некоторые вещи забыть или исказить. Вообще, с удовольствием бы почитал про низкоуровневую архитектуру крупных P2P-сетей и как там решаются разного рода проблемы. Например, мне совсем неочевидно, как можно гарантировать полную связность, т.е. отсутствие обособленных островков, ни один из пиров в которых не соединён с остальной частью сети. Скорее всего, это объясняется через вероятности, но оно не очевидно.
Разве? Я думал, там сеть Фейстеля, где выполняется только XOR и сложение по модулю 2³².
Это что-то политическое?
Да, это удобнее. Но модальные режимы всё равно не выглядят для меня привлекательными, т.к. не вижу задач, где требовалась бы именно набивка больших объёмов текста с максимальной скоростью.
На CapsLock лучше переключение раскладки вешать, имхо.
Да, GUI для таких вещей обычно не требуется. Ну и по SSH тоже альтернатив нет.
У меня так мизинец не выгибается, чтобы до [ достать, я обычно «х» жму безымянным, смещая руку. А в описанном сценарии проблема именно с промахами, так что тут можно ещё сильнее усугубить. А Esc всегда в углу клавиатуры.
Нет, я использую только его, но для мелких вещей типа правки конфигов. Другие редакторы просто ещё хуже, а тут хотя бы можно строку удалить быстро. В IDE, конечно, ещё быстрее (Ctrl-D вместо Esc,d,d), но для конфигов запускать её — оверкилл.
Для меня режимы — это главный минус vim. Печатаю я, конечно, вслепую и давно, но иногда всё же промахиваюсь. При наборе текста это не проблема, удалил символ, написал новый. Но когда в виме я в нормальном режиме, начинается то самое «пищит и портит». Остаётся судорожно жать Esc несколько раз, чтобы точно там не набилось невидимых команд в буфер.
С UB бывают всякие «весёлые» эффекты. Например, null reference может быть одновременно == 0 и != 0, может быть равна другой такой же ссылке или не равна, в зависимости от версии компилятора и флагов оптимизации: пришлось рефакторить всю систему обработки ошибок. Простое правило: если вы полагаетесь на UB, вы добавляете в код немного святого рандома. Каждый компилятор вправе превратить этот код во что угодно, и он превратит. Garbage in => garbage out.