inline long int fround(float x)
{
return _mm_cvtss_si32(_mm_load_ss(&x));
}
upd: у вас другая задача: сделать такой float, чтобы при отсечении дробной части всегда получался исходный int. Но да ладно, может кому пригодится функция
Ну хз. У них нет возможности получить клиента под windows без инсталятора. Да и вообще хотели отказатся от поддержки 10-ки (не знаю, отказались или нет, давно забил). Это довольно странно для свободного клиента.
я изучал подробно вопрос (у меня есть самописный shadowsocks сервер и клиент), экспериментируя с разными длинами пакетов. Выяснил, что сервер тупо не получает самый первый пакет. Т.е. решение о блокировке принимается только на основе содержимого пакета, т.е. по сути фильтр детектит белый шум и не пускает его.
не подскажете, как shadowsocks детектится? Там весь траффик с самого первого байта - рандом (первые 32 байта - реальный рандом, а дальше от рандома визуально мало чем отличается). Моё предположение - считают энтропию и если видят рандом - в блок. А может и тупо - неизвестная сигнатура на непойми каком порту за границу - блок.
В Телеграме end-to-end шифрованием защищены только секретные чаты. Все остальное в telegram-е хранится на его серверах в незашифрованном виде – иначе бы вы никогда не получили бы всю историю своих переписок при входе с любого устройства, где установлен Telegram.
Не знаю, сделано ли это в телеге, но историю сообщений таки можно хранить на сервере в зашифрованном виде и получать на нескольких устройствах. Правда этот трюк не сработает для групповых чатов, а для двух собеседников - вполне. Просто, когда клиент отправляет сообщение, он отправляет его в двух экземплярах: зашифровано для собеседника и зашифровано для себя. Впрочем, остается проблема доставки ключа шифрования для нового устройства, когда старые все offline, сводящие на нет эту схему.
RustDesk поддерживает прямое соединение. В локалке работает почти идеально. На голову лучше всего, что пробовал раньше. Да я даже перестал подключать клавиатуру и мониторы к рабочему ноутбуку и работаю через RustDesk с домашнего десктопа. Лаги минимальны. А для доступа извне, у меня свой VPN и тоже без проблем прямым соединением. Так что серверный компонент вообще и не нужен по сути.
Что если ошибка выше? Возможно ошибка уже в базовой концепции (гравитация порождается массами)? Пока что эта концепция столь незыблема, что даже тень сомнения в ней автоматически ставит сомневающегося на уровень плоскоземельщика. Ну да ладно, пусть ищут. Когда-нибудь какой-нибудь гений изобретет антигравитацию и поломает теоретикам всё. Но это не точно.
Я уже HopToDesk снес. Решил на RustDesk остаться. Но в RustDesk такая фича есть. Хотя вот попробовал включить, но он завис и упал. В общем вопрос пока открытый.
Проверил сам. Похоже HopToDesk, это форк RustDesk'а. Они похожи как близнецы и по фичам и визуально. Да они даже конфликтуют. После установки HopToDesk, RustDesk перестал к этой машине подключаться. Всё что сделали разработчики, так это подняли свои сервера и немного подрихтовали интерфейс.
где можно выбрать, какой именно рубль из по разному покрашенных ты собираешься тратить
а это может и нельзя выбрать by design, так сказать. В самом деле, "цвета" ведь могут быть очень разными и вводиться сотнями в день. Зачем об этом рядовому гражданину знать? Удобство пользователя тут совсем не главное.
А я не говорю, что они не хранятся. Я говорю, что, учитывая их объем, искать по ним концы может быть очень затратно. Очень. А если в логах чего-то не будет? Ну мало ли чего в жизни бывает... в конце концов логи - это просто логи, а не основа функционирования системы. Если условный админ Вася что-то напутает и грохнет базу с логами за прошлую неделю, ничего ведь не сломается.
например, копит гражданин на квартиру, а сумма рраз - и сгорела, да? вот только чем теперь застройщику рабочим зарплату платить?
Нет, ну зачем так жестко.
Вообще, сгораемые суммы денег - это же классная опция вывода денежной массы из оборота. Например, будут платить пенсию суммами, сгораемыми через пол года после смерти получателя. Не вступил в наследство - денежка вышла из оборота насовсем.
PS. Нет, я не защищаю это, просто констатирую, что придумать применений этому механизму можно много. Кстати, проскочила новость, что внедрение цифрового рубля перенесли на неопределенный срок. И хорошо.
Насколько я понимаю, ключевое отличие цифрового рубля от обычного безнала в представлении сумм в хранилище. Если мы положим на счет в обычном банке обычный рубль на обычный счет, то там просто увеличится сумма в базе данных. Если мы сделаем 100 транзакций, то 100 раз будет изменено число денег в ячейке памяти базы данных и всё. Отследить, откуда были пополнения и траты нельзя. Эту информацию надо смотреть в логах, а это не всегда возможно да и дорого. А отследить полный путь определенной денежной суммы вообще невозможно (привет криптомиксерам - даже с открытой историей транзакций есть проблемы). Цифровой же рубль предполагает закрепление различных свойств за определенными суммами. Т.е. у вас на счете в ЦБ будет не просто число цифровых рублей, а список объектов вида {свойства, сумма}. А вот это открывает просто бесконечные возможности по контролю и ограничениям. Например, сгораемые суммы, суммы на определенные цели, суммы с историей происхождения и т.п.
Дело не в редкости задачи, а в том, сколько раз в секунду эту задачу приходится выполнять. Конкретно эта задача - определение високосности года - если и требуется где-то, то не чаще одного раза за кадр, что явно недостаточно, чтобы заморачиваться ради сотни тактов.
Сначала я такой: О! Крутая оптимизация. Заберу в свою коллекцию.
А потом задумался. А в какой задаче требуется максимально быстро проверять год на високосность? Думал думал и так и не придумал. Единственное, что приходит в голову - преобразование даты в секунды при обработке каких-то массивов данных. Но всё равно мысль буксует, зачем это надо делать быстро и даже если очень надо, не быстрее ли сделать какой-то lookup в табличку с нужным диапазоном годов и сразу получать готовые вычисления.
Но в целом я одобряю подобные извращения над битовой арифметикой. Как разминка для ума, и, иногда оно бывает очень полезным с практической точки зрения
Это настолько критичный по времени код, что есть смысл проверять указатель перед вызовом free
Это прям какой-то дико извращенный алгоритм должен быть, чтоб вот прям надо много раз (буквально миллиарды) вызывать free и это надо делать быстро. Не. Программисту, который такое напишет, надо дать по рукам и заставить переписать код так, чтобы он вообще аллокации не использовал. Это даст намного больший выигрыш в скорости, нежели эта проверка.
upd: у вас другая задача: сделать такой float, чтобы при отсечении дробной части всегда получался исходный int. Но да ладно, может кому пригодится функция
Ну хз. У них нет возможности получить клиента под windows без инсталятора. Да и вообще хотели отказатся от поддержки 10-ки (не знаю, отказались или нет, давно забил). Это довольно странно для свободного клиента.
ну syn и ack пакеты не отбрасываются, т.е. tcp соединение устанавливается. А вот первый же пакет с данными от клиента не доходит.
Да, соединение есть (в логи пишет, что соединилось), но далее тишина и отвал по таймауту.
я изучал подробно вопрос (у меня есть самописный shadowsocks сервер и клиент), экспериментируя с разными длинами пакетов. Выяснил, что сервер тупо не получает самый первый пакет. Т.е. решение о блокировке принимается только на основе содержимого пакета, т.е. по сути фильтр детектит белый шум и не пускает его.
Вот, кстати, да. Это очень похоже на истинную причину блокировки этого сайта. Его было очень удобно использовать в качестве sni донора.
не подскажете, как shadowsocks детектится? Там весь траффик с самого первого байта - рандом (первые 32 байта - реальный рандом, а дальше от рандома визуально мало чем отличается). Моё предположение - считают энтропию и если видят рандом - в блок. А может и тупо - неизвестная сигнатура на непойми каком порту за границу - блок.
Не знаю, сделано ли это в телеге, но историю сообщений таки можно хранить на сервере в зашифрованном виде и получать на нескольких устройствах. Правда этот трюк не сработает для групповых чатов, а для двух собеседников - вполне. Просто, когда клиент отправляет сообщение, он отправляет его в двух экземплярах: зашифровано для собеседника и зашифровано для себя. Впрочем, остается проблема доставки ключа шифрования для нового устройства, когда старые все offline, сводящие на нет эту схему.
RustDesk поддерживает прямое соединение. В локалке работает почти идеально. На голову лучше всего, что пробовал раньше. Да я даже перестал подключать клавиатуру и мониторы к рабочему ноутбуку и работаю через RustDesk с домашнего десктопа. Лаги минимальны. А для доступа извне, у меня свой VPN и тоже без проблем прямым соединением. Так что серверный компонент вообще и не нужен по сути.
Что если ошибка выше? Возможно ошибка уже в базовой концепции (гравитация порождается массами)? Пока что эта концепция столь незыблема, что даже тень сомнения в ней автоматически ставит сомневающегося на уровень плоскоземельщика. Ну да ладно, пусть ищут. Когда-нибудь какой-нибудь гений изобретет антигравитацию и поломает теоретикам всё. Но это не точно.
Я уже HopToDesk снес. Решил на RustDesk остаться. Но в RustDesk такая фича есть. Хотя вот попробовал включить, но он завис и упал. В общем вопрос пока открытый.
Проверил сам. Похоже HopToDesk, это форк RustDesk'а. Они похожи как близнецы и по фичам и визуально. Да они даже конфликтуют. После установки HopToDesk, RustDesk перестал к этой машине подключаться. Всё что сделали разработчики, так это подняли свои сервера и немного подрихтовали интерфейс.
Кто пробовал, напишите, чем оно хуже/лучше RustDesk
а это может и нельзя выбрать by design, так сказать. В самом деле, "цвета" ведь могут быть очень разными и вводиться сотнями в день. Зачем об этом рядовому гражданину знать? Удобство пользователя тут совсем не главное.
А я не говорю, что они не хранятся. Я говорю, что, учитывая их объем, искать по ним концы может быть очень затратно. Очень. А если в логах чего-то не будет? Ну мало ли чего в жизни бывает... в конце концов логи - это просто логи, а не основа функционирования системы. Если условный админ Вася что-то напутает и грохнет базу с логами за прошлую неделю, ничего ведь не сломается.
Нет, ну зачем так жестко.
Вообще, сгораемые суммы денег - это же классная опция вывода денежной массы из оборота. Например, будут платить пенсию суммами, сгораемыми через пол года после смерти получателя. Не вступил в наследство - денежка вышла из оборота насовсем.
PS. Нет, я не защищаю это, просто констатирую, что придумать применений этому механизму можно много. Кстати, проскочила новость, что внедрение цифрового рубля перенесли на неопределенный срок. И хорошо.
Насколько я понимаю, ключевое отличие цифрового рубля от обычного безнала в представлении сумм в хранилище. Если мы положим на счет в обычном банке обычный рубль на обычный счет, то там просто увеличится сумма в базе данных. Если мы сделаем 100 транзакций, то 100 раз будет изменено число денег в ячейке памяти базы данных и всё. Отследить, откуда были пополнения и траты нельзя. Эту информацию надо смотреть в логах, а это не всегда возможно да и дорого. А отследить полный путь определенной денежной суммы вообще невозможно (привет криптомиксерам - даже с открытой историей транзакций есть проблемы). Цифровой же рубль предполагает закрепление различных свойств за определенными суммами. Т.е. у вас на счете в ЦБ будет не просто число цифровых рублей, а список объектов вида {свойства, сумма}. А вот это открывает просто бесконечные возможности по контролю и ограничениям. Например, сгораемые суммы, суммы на определенные цели, суммы с историей происхождения и т.п.
Очевидно для минимизации ошибок и возможности обмана системы.
Дело не в редкости задачи, а в том, сколько раз в секунду эту задачу приходится выполнять. Конкретно эта задача - определение високосности года - если и требуется где-то, то не чаще одного раза за кадр, что явно недостаточно, чтобы заморачиваться ради сотни тактов.
Сначала я такой: О! Крутая оптимизация. Заберу в свою коллекцию.
А потом задумался. А в какой задаче требуется максимально быстро проверять год на високосность? Думал думал и так и не придумал. Единственное, что приходит в голову - преобразование даты в секунды при обработке каких-то массивов данных. Но всё равно мысль буксует, зачем это надо делать быстро и даже если очень надо, не быстрее ли сделать какой-то lookup в табличку с нужным диапазоном годов и сразу получать готовые вычисления.
Но в целом я одобряю подобные извращения над битовой арифметикой. Как разминка для ума, и, иногда оно бывает очень полезным с практической точки зрения
Сложно представить, для чего может потребоваться:
Вызов free с нулевым указателем в 99% случаев
Это настолько критичный по времени код, что есть смысл проверять указатель перед вызовом free
Это прям какой-то дико извращенный алгоритм должен быть, чтоб вот прям надо много раз (буквально миллиарды) вызывать free и это надо делать быстро. Не. Программисту, который такое напишет, надо дать по рукам и заставить переписать код так, чтобы он вообще аллокации не использовал. Это даст намного больший выигрыш в скорости, нежели эта проверка.