RustDesk поддерживает прямое соединение. В локалке работает почти идеально. На голову лучше всего, что пробовал раньше. Да я даже перестал подключать клавиатуру и мониторы к рабочему ноутбуку и работаю через RustDesk с домашнего десктопа. Лаги минимальны. А для доступа извне, у меня свой VPN и тоже без проблем прямым соединением. Так что серверный компонент вообще и не нужен по сути.
Что если ошибка выше? Возможно ошибка уже в базовой концепции (гравитация порождается массами)? Пока что эта концепция столь незыблема, что даже тень сомнения в ней автоматически ставит сомневающегося на уровень плоскоземельщика. Ну да ладно, пусть ищут. Когда-нибудь какой-нибудь гений изобретет антигравитацию и поломает теоретикам всё. Но это не точно.
Я уже HopToDesk снес. Решил на RustDesk остаться. Но в RustDesk такая фича есть. Хотя вот попробовал включить, но он завис и упал. В общем вопрос пока открытый.
Проверил сам. Похоже HopToDesk, это форк RustDesk'а. Они похожи как близнецы и по фичам и визуально. Да они даже конфликтуют. После установки HopToDesk, RustDesk перестал к этой машине подключаться. Всё что сделали разработчики, так это подняли свои сервера и немного подрихтовали интерфейс.
где можно выбрать, какой именно рубль из по разному покрашенных ты собираешься тратить
а это может и нельзя выбрать by design, так сказать. В самом деле, "цвета" ведь могут быть очень разными и вводиться сотнями в день. Зачем об этом рядовому гражданину знать? Удобство пользователя тут совсем не главное.
А я не говорю, что они не хранятся. Я говорю, что, учитывая их объем, искать по ним концы может быть очень затратно. Очень. А если в логах чего-то не будет? Ну мало ли чего в жизни бывает... в конце концов логи - это просто логи, а не основа функционирования системы. Если условный админ Вася что-то напутает и грохнет базу с логами за прошлую неделю, ничего ведь не сломается.
например, копит гражданин на квартиру, а сумма рраз - и сгорела, да? вот только чем теперь застройщику рабочим зарплату платить?
Нет, ну зачем так жестко.
Вообще, сгораемые суммы денег - это же классная опция вывода денежной массы из оборота. Например, будут платить пенсию суммами, сгораемыми через пол года после смерти получателя. Не вступил в наследство - денежка вышла из оборота насовсем.
PS. Нет, я не защищаю это, просто констатирую, что придумать применений этому механизму можно много. Кстати, проскочила новость, что внедрение цифрового рубля перенесли на неопределенный срок. И хорошо.
Насколько я понимаю, ключевое отличие цифрового рубля от обычного безнала в представлении сумм в хранилище. Если мы положим на счет в обычном банке обычный рубль на обычный счет, то там просто увеличится сумма в базе данных. Если мы сделаем 100 транзакций, то 100 раз будет изменено число денег в ячейке памяти базы данных и всё. Отследить, откуда были пополнения и траты нельзя. Эту информацию надо смотреть в логах, а это не всегда возможно да и дорого. А отследить полный путь определенной денежной суммы вообще невозможно (привет криптомиксерам - даже с открытой историей транзакций есть проблемы). Цифровой же рубль предполагает закрепление различных свойств за определенными суммами. Т.е. у вас на счете в ЦБ будет не просто число цифровых рублей, а список объектов вида {свойства, сумма}. А вот это открывает просто бесконечные возможности по контролю и ограничениям. Например, сгораемые суммы, суммы на определенные цели, суммы с историей происхождения и т.п.
Дело не в редкости задачи, а в том, сколько раз в секунду эту задачу приходится выполнять. Конкретно эта задача - определение високосности года - если и требуется где-то, то не чаще одного раза за кадр, что явно недостаточно, чтобы заморачиваться ради сотни тактов.
Сначала я такой: О! Крутая оптимизация. Заберу в свою коллекцию.
А потом задумался. А в какой задаче требуется максимально быстро проверять год на високосность? Думал думал и так и не придумал. Единственное, что приходит в голову - преобразование даты в секунды при обработке каких-то массивов данных. Но всё равно мысль буксует, зачем это надо делать быстро и даже если очень надо, не быстрее ли сделать какой-то lookup в табличку с нужным диапазоном годов и сразу получать готовые вычисления.
Но в целом я одобряю подобные извращения над битовой арифметикой. Как разминка для ума, и, иногда оно бывает очень полезным с практической точки зрения
Это настолько критичный по времени код, что есть смысл проверять указатель перед вызовом free
Это прям какой-то дико извращенный алгоритм должен быть, чтоб вот прям надо много раз (буквально миллиарды) вызывать free и это надо делать быстро. Не. Программисту, который такое напишет, надо дать по рукам и заставить переписать код так, чтобы он вообще аллокации не использовал. Это даст намного больший выигрыш в скорости, нежели эта проверка.
Мои навыки программиста распространяются только на два языка: c++ и java. Я просто не в курсе, как обстоят дела с другими языками, может и ошибусь сейчас. Так вот, мне кажется, что никакой язык, который позволяет программисту писать многопоточный код, не "подложит мьютекс" автоматически. Ну то есть программист в любом случае должен как-то намекнуть компилятору/интерпретатору, что обращение к массиву будет из разных потоков. Повторюсь, возможно ошибаюсь, и такой язык существует. Ну а если нет, то и c++ и java вполне себе умеют "соломки подкладывать".
Мы делали свой прогресс бар (в одной старой игре) относительно честным. Немножко мухлевали в начале (до 15%) и в конце (после 85%). Работало это так: до 15% ползунок идет плавно в течении одной секунды. Далее честная загрузка с отображением реальных 0..100 в 15..85 на экране. Ну и с 85 до 100 тоже плавно за секунду. Даже несмотря на то, что загрузка шла на 2 секунды дольше, чем могла бы, визуально воспринималась бодрее.
Всё просто. Энергия и масса - это одно и то же. Эта формула буквально говорит нам: есть некое явление, которое мы измеряем в килограммах или в джоулях, а для пересчета из килограмм в джоули просто умножьте на константу (c^2)
Правильно ли я понял, что автор библиотеки реализовал виртуальные методы на шаблонах, со своей собственной vtable? И что в итоге получили? Усложнение синтаксиса. Ну да ладно, привыкнуть можно. К генерации столь-же оптимального кода, как сейчас на встроенном vtable тоже есть вопросы. Я бы не стал тут полагаться на магию оптимизатора. А вот умеет ли библиотека (не сильно ковырялся в ней) делать множественное виртуальное наследование? Да, это спорная фича и вызывает у многих вопросы, но в моей практике множественное виртуальное наследование довольно часто оказывается самым удобным, быстрым и красивым решением задачи.
Про virtual не понял. Вы хотите как в java, где все, что не помечено как final или private, по факту virtual? Или вообще vtable выпилить из языка? Если vtable убирать, то я против. Это очень мощная фича языка и я даже не представляю, как писать эффективный код без этого.
У многих компаний регулярные обновления с перестановкой кнопок интерфейса и одной новой фичей — бизнес-модель. Нужно как-то заставлять старых клиентов, которых всё и так устраивает, приносить денежку снова и снова. Да что там говорить, постоянные обновления — это и в реале сейчас тренд. Запланированное устаревание — из той же оперы.
> Одновременно настолько развитая и настолько отстающая по технологиям страна
Забавно, только что прочитал статью о тех, кто тормозит прогресс. А ведь Япония потому и развита, что максимально эффективно использует старые технологии, не отвлекаясь на апгрейды.
RustDesk поддерживает прямое соединение. В локалке работает почти идеально. На голову лучше всего, что пробовал раньше. Да я даже перестал подключать клавиатуру и мониторы к рабочему ноутбуку и работаю через RustDesk с домашнего десктопа. Лаги минимальны. А для доступа извне, у меня свой VPN и тоже без проблем прямым соединением. Так что серверный компонент вообще и не нужен по сути.
Что если ошибка выше? Возможно ошибка уже в базовой концепции (гравитация порождается массами)? Пока что эта концепция столь незыблема, что даже тень сомнения в ней автоматически ставит сомневающегося на уровень плоскоземельщика. Ну да ладно, пусть ищут. Когда-нибудь какой-нибудь гений изобретет антигравитацию и поломает теоретикам всё. Но это не точно.
Я уже HopToDesk снес. Решил на RustDesk остаться. Но в RustDesk такая фича есть. Хотя вот попробовал включить, но он завис и упал. В общем вопрос пока открытый.
Проверил сам. Похоже HopToDesk, это форк RustDesk'а. Они похожи как близнецы и по фичам и визуально. Да они даже конфликтуют. После установки HopToDesk, RustDesk перестал к этой машине подключаться. Всё что сделали разработчики, так это подняли свои сервера и немного подрихтовали интерфейс.
Кто пробовал, напишите, чем оно хуже/лучше RustDesk
а это может и нельзя выбрать by design, так сказать. В самом деле, "цвета" ведь могут быть очень разными и вводиться сотнями в день. Зачем об этом рядовому гражданину знать? Удобство пользователя тут совсем не главное.
А я не говорю, что они не хранятся. Я говорю, что, учитывая их объем, искать по ним концы может быть очень затратно. Очень. А если в логах чего-то не будет? Ну мало ли чего в жизни бывает... в конце концов логи - это просто логи, а не основа функционирования системы. Если условный админ Вася что-то напутает и грохнет базу с логами за прошлую неделю, ничего ведь не сломается.
Нет, ну зачем так жестко.
Вообще, сгораемые суммы денег - это же классная опция вывода денежной массы из оборота. Например, будут платить пенсию суммами, сгораемыми через пол года после смерти получателя. Не вступил в наследство - денежка вышла из оборота насовсем.
PS. Нет, я не защищаю это, просто констатирую, что придумать применений этому механизму можно много. Кстати, проскочила новость, что внедрение цифрового рубля перенесли на неопределенный срок. И хорошо.
Насколько я понимаю, ключевое отличие цифрового рубля от обычного безнала в представлении сумм в хранилище. Если мы положим на счет в обычном банке обычный рубль на обычный счет, то там просто увеличится сумма в базе данных. Если мы сделаем 100 транзакций, то 100 раз будет изменено число денег в ячейке памяти базы данных и всё. Отследить, откуда были пополнения и траты нельзя. Эту информацию надо смотреть в логах, а это не всегда возможно да и дорого. А отследить полный путь определенной денежной суммы вообще невозможно (привет криптомиксерам - даже с открытой историей транзакций есть проблемы). Цифровой же рубль предполагает закрепление различных свойств за определенными суммами. Т.е. у вас на счете в ЦБ будет не просто число цифровых рублей, а список объектов вида {свойства, сумма}. А вот это открывает просто бесконечные возможности по контролю и ограничениям. Например, сгораемые суммы, суммы на определенные цели, суммы с историей происхождения и т.п.
Очевидно для минимизации ошибок и возможности обмана системы.
Дело не в редкости задачи, а в том, сколько раз в секунду эту задачу приходится выполнять. Конкретно эта задача - определение високосности года - если и требуется где-то, то не чаще одного раза за кадр, что явно недостаточно, чтобы заморачиваться ради сотни тактов.
Сначала я такой: О! Крутая оптимизация. Заберу в свою коллекцию.
А потом задумался. А в какой задаче требуется максимально быстро проверять год на високосность? Думал думал и так и не придумал. Единственное, что приходит в голову - преобразование даты в секунды при обработке каких-то массивов данных. Но всё равно мысль буксует, зачем это надо делать быстро и даже если очень надо, не быстрее ли сделать какой-то lookup в табличку с нужным диапазоном годов и сразу получать готовые вычисления.
Но в целом я одобряю подобные извращения над битовой арифметикой. Как разминка для ума, и, иногда оно бывает очень полезным с практической точки зрения
Сложно представить, для чего может потребоваться:
Вызов free с нулевым указателем в 99% случаев
Это настолько критичный по времени код, что есть смысл проверять указатель перед вызовом free
Это прям какой-то дико извращенный алгоритм должен быть, чтоб вот прям надо много раз (буквально миллиарды) вызывать free и это надо делать быстро. Не. Программисту, который такое напишет, надо дать по рукам и заставить переписать код так, чтобы он вообще аллокации не использовал. Это даст намного больший выигрыш в скорости, нежели эта проверка.
Мои навыки программиста распространяются только на два языка: c++ и java. Я просто не в курсе, как обстоят дела с другими языками, может и ошибусь сейчас. Так вот, мне кажется, что никакой язык, который позволяет программисту писать многопоточный код, не "подложит мьютекс" автоматически. Ну то есть программист в любом случае должен как-то намекнуть компилятору/интерпретатору, что обращение к массиву будет из разных потоков. Повторюсь, возможно ошибаюсь, и такой язык существует. Ну а если нет, то и c++ и java вполне себе умеют "соломки подкладывать".
Третий пример не сильно то и про c++. Писать и читать массив из разных потоков одновременно - будет плохо в любом языке.
Мы делали свой прогресс бар (в одной старой игре) относительно честным. Немножко мухлевали в начале (до 15%) и в конце (после 85%). Работало это так: до 15% ползунок идет плавно в течении одной секунды. Далее честная загрузка с отображением реальных 0..100 в 15..85 на экране. Ну и с 85 до 100 тоже плавно за секунду. Даже несмотря на то, что загрузка шла на 2 секунды дольше, чем могла бы, визуально воспринималась бодрее.
Всё просто. Энергия и масса - это одно и то же. Эта формула буквально говорит нам: есть некое явление, которое мы измеряем в килограммах или в джоулях, а для пересчета из килограмм в джоули просто умножьте на константу (c^2)
Правильно ли я понял, что автор библиотеки реализовал виртуальные методы на шаблонах, со своей собственной vtable? И что в итоге получили? Усложнение синтаксиса. Ну да ладно, привыкнуть можно. К генерации столь-же оптимального кода, как сейчас на встроенном vtable тоже есть вопросы. Я бы не стал тут полагаться на магию оптимизатора. А вот умеет ли библиотека (не сильно ковырялся в ней) делать множественное виртуальное наследование? Да, это спорная фича и вызывает у многих вопросы, но в моей практике множественное виртуальное наследование довольно часто оказывается самым удобным, быстрым и красивым решением задачи.
Так что все равно нет.
Про virtual не понял. Вы хотите как в java, где все, что не помечено как final или private, по факту virtual? Или вообще vtable выпилить из языка? Если vtable убирать, то я против. Это очень мощная фича языка и я даже не представляю, как писать эффективный код без этого.
Забавно, только что прочитал статью о тех, кто тормозит прогресс. А ведь Япония потому и развита, что максимально эффективно использует старые технологии, не отвлекаясь на апгрейды.