Чуть дополню, нужно для модной точной паузы в миллисекундах. Прерывания времени в DOS щёлкали каждые 55мс, но разработчики Турбо Паскаля решили помочь программистам и реализовали возможность паузы с точностью до 1мс. Достигалось это как раз тем, что при инициализации запускался цикл и выяснялось, сколько итераций происходило за 55мс. Соответственно, во время паузы крутился цикл с нужным количеством итераций.
Патчили CRT обычно убиванием этой проверки, т.е. побочный эффект от этого — спячка становилась опять дискретной.
Ээх… думал будет рассказано, какие есть техники, чтобы после перезагрузки сервера не надо было танцевать с бубном, чтобы его завести. Особенно актуально для Windows, которая любит ставить апдейты и перегружаться.
Можно поднимать его — отличная физическая нагрузка, можно сесть в него и продолжать работать — смена обстановки поможет расслабиться. Можно взять весло и пойти разгребать снег. Опять же, можно дать весло девушке и сделать скульптуру. Можно в каяке хранить запас алкоголя на новый год (ну или просто прятать от девушки). Да можно просто бросить его в комнате и ходить запинаться об него.
Отличная вещь, в общем.
ничего не гарантирует ) сбои могут быть и одновременные.
Допустимый риск. в RAID тоже два диска могут одновременно выйти из строя, но в целом на 1-ом рейде вполне живут.
только если байтики целиком с избыточностью в сеть передавать. И пока они бегут туда-сюда по каналам связи все ок. ))))
Я имел в виду, что на другом компьютере хранить в памяти всё, так что там диск не тратить. Но поскольку идея бредовая можно и в pingfs хранить.
Т.е. основная моя идея этой всей хрени: минимальные записи на диск, путём резервирования внешним кешем, который для простоты представляет из себя компьютер.
creker вам ответил уже, могу только добавить, что использование батарейки давно практикуется для RAID-контроллеров, которым выгодно кешировать, но страшно за целостность.
Ещё в порядке бреда могу ещё одну идею накидать, что можно делать: не писать данные на диск, а закидывать их на другой компьютер (в другом физическом месте) по сети. В результате сбои не будут одновременно и можно будет восстановить данные. Байтики по сети не изнашиваются, так что может хорошо продлить срок службы. :)
Недостаток — данные долго хранятся в памяти и при отключении питания может потеряться много данных.
Это как раз фатальный недостаток. Если мы считаем, что можем хранить данные в памяти и записывать только по настроению, то нам не нужны такие заморочки с файловой системой. Мы можем реально буферизировать кучу операций и потом аккуратно скопом в нужном порядке записывать.
Но файловая система по-позможности должна писать максимально быстро на диск. Потеря данных на кеше очень неприятная для серьёзных систем. Да и для несерьёзных, тоже.
Я перебрал много чего, что есть в обычных магазинах, и в качестве базового соуса (которого можно лить не жалея и ни о чём не думая) остановился как раз на Срираче (стоит дешёво, банка большая, найти несложно). Причём больше нравится вьетнамская из перекрёстка, есть ещё тайская в глобусе, считается лучше, но чуть меньше нравится.А от Aroy-D показалась каким-то ужасом.
По поводу сохранения данных в файл — не подскажу. Официальной возможности не нашёл, хотя не очень сильно и искал. Возможно, есть варианты с экспортом в Google Fit, а оттуда уже достать их. Когда вытягивал данные с Xiaomi Band, было какое-то костыльное решение, но я вытянул, посмотрел на результаты и больше не возвращался.
Вот как раз на первых фотографиях явно виден след от самого браслета, поэтому и предположил, что человек затянул его. В качестве других вариантов, могу предоложить, что браслет был поддельным и с острыми гранями. В центре как раз расположены датчики, т.е. раздражение и было максимально в центре. Ну а дальше просто рана пошла заживать таким страшным образом.
Могу предположить, что человек затянул браслет до упора, а потом вспотел хорошо. И получил не ожог, а раздражение, из-за того что натёр себе руку.
У меня 5-ый бенд, который круглосуточно меряет пульс, ничего не обнаружил у себя на руке. И сомневаюсь, что от такого фонарика можно что-то получить.
Ну нееет… Это так не работает. Если человек в состоянии написать нормальный генератор псевдослучайных чисел, ему вся ваша статья как бы очевидна будет. А если не в состоянии — то возьмёт ваш пример, и будет использовать там, где вы не планировали.
Вы в ответе за тех, кого приручили. Было бесчисленное количество ошибок, связанное с тем, что люди делали какой-то функционал для базовых сценариев, а все их использовали для других. Поэтому как раз в .NET и заюзали для этого не самый быстрый, но зато достаточно «случайный» метод Фиббоначи с запаздыванием. Чтобы как раз, кому надо быстроту, мог использовать и ЛКГ, а кому пофиг на всё — не ловил бы проблем из-за некачественной базовой реализации.
Я правильно понимаю, что борясь с особенностями реализации рандома в Unity вы заиспользовали самый тупейший из существующих генераторов, у которых случайности не случайны и призываете им пользоваться?
private double InternalSample()
{
var ret = _next * ModulusReciprocal;
_next = _next * Multiplier % Modulus;
return ret;
}
Прочитал статью, увидел Тинькофф в качестве клиента, взял первую попавшуюся карту и и приложение Тинькова. Спустя 3 минуты мне надоедло прыгать с камерой. И рамка на месте. Так что, похоже, реклама разбилась о суровую действительность.
Он по-другому работает. Таска сама проверяет, что её попросили сдохнуть и делает всё для этого, а это насильное убийство. Нужно обычно как средство последнего шанса, но бывают ситуации, когда очень нужно.
При компиляции ворнинг будет, но изначально вопрос был в том — что просто поставили новый фреймворк и взяли старый код. Тут, похоже, будет очень неприятно.
Похоже, всё-таки не всё будет гладко.
Вот сейчас выяснил, что сломали Thread.Abort
Т.е. код начнёт эпично валиться в непредсказуемых местах. И вот сколько таких мест может быть?
Это я понимаю, но вопросы были в следующем:
1. Будет ли прирост производительности просто от подсовывания нового рантайма
2. Не вылезут ли проблемы из-за того, что совместимость именно что декларируется. Т.е. могут взять метод и убрать у него реализацию (типа у нас новые правила) или изменить реализацию, что приведёт к косякам. А то у нас был весёлый пример с использованием рантайма 2.2 при разработке на 2.1. Несколько недель поиска проблемы.
А что будет, если таргет будет старый (netstandard2.0, например), а рантайм новый? Плюшки по производительности будут? Или всё-таки IL-код оптимизируется ещё новым тулчейном?
Ну или совсем гулять — новым тулчейном компилять под netstandard2.0 и запускать на новом рантайме.
На всякий случай, отвечу на вопрос зачем: если не надо новых фич, то в целом повышать версию выглядит бессмысленно, бывает легаси и прочие замороженные проекты, которые нет смысла переводить на новый фреймворк, а зависимости свежие использовать хочется.
С учётом того, что шкала децибелл уже логарифмическая, добавлять к этому ещё нелинейные палки — это уже какая-то вторая производная. :)
Но палки да, рисуют от балды все.
Иногда бывает относительно абстрактный маппинг, иногда бывают языки со слабой типизацией. И после таких утверждений, что нет разницы, true или «true» люди с фамилией Null или номерным знаком NULL начинают испытывать проблемы. А щас погуглил, есть ещё люди с фамилией True :)
С проблемами типов при сериализации я встречался в JS, Python, .NET, когда умный парсер подставляет самый подходящий тип, а потом начинает ломаться. В .NET был, кстати, самый забавный случай, когда он строку, похожую на дату считал датой и портил её. И это функционал по умолчанию.
Не все и не всегда делают маппинг json/xml => объект. Бывают абстрактные десериализации, в абстрактный объект, бывает миграция версий, особенно для конфигов, когда хочется оставить поддержку старой версии. И всё может замечательно стрелять.
Можно придумать такой пример (стырил из nginx):
мы пишем прокси, и у нас в конфиге есть параметр proxy_redirect, который может принимать значения: true — делать редирект, переписывая хост автоматически. Нужно большинству пользователей. false — не делать, или строка, которая говорит, на какой хост редиректить. Мы не различаем false и «false» и всё работает до тех пор, когда у кого-то не оказался хост с названием false. Может даже как-то заработает, но могут появиться спец.эффекты.
Решение: две настройки, или воспользоваться типизацией.
Важно. Мне это в JSON тоже очень не нравится. Раньше была идея писать /Date(timestamp)/ — но тоже костыль и не прижилось.
Вообще сериализация и десериализация подразумевает сохранение значений в текстовой или бинарной форме. Любое примитивное значение так или иначе мепится в строку.
Вот вообще не так для бинарной формы. Посмотрите хоть на Message Pack.
То, что вам в JS оставили boolean и еще пару примитивных типов, и на базе которых склепали JSON, совсем не значит, что в нормальных ЯП нет других примитивных (и кастомных) типов, которые тоже надо как-то мэппить.
Есть другие типы, да. Но практически во всех языках есть понятия числа/строки/массива/словаря и это разумная и понятная база.
Патчили CRT обычно убиванием этой проверки, т.е. побочный эффект от этого — спячка становилась опять дискретной.
Отличная вещь, в общем.
Допустимый риск. в RAID тоже два диска могут одновременно выйти из строя, но в целом на 1-ом рейде вполне живут.
Я имел в виду, что на другом компьютере хранить в памяти всё, так что там диск не тратить. Но поскольку идея бредовая можно и в pingfs хранить.
Т.е. основная моя идея этой всей хрени: минимальные записи на диск, путём резервирования внешним кешем, который для простоты представляет из себя компьютер.
Ещё в порядке бреда могу ещё одну идею накидать, что можно делать: не писать данные на диск, а закидывать их на другой компьютер (в другом физическом месте) по сети. В результате сбои не будут одновременно и можно будет восстановить данные. Байтики по сети не изнашиваются, так что может хорошо продлить срок службы. :)
Это как раз фатальный недостаток. Если мы считаем, что можем хранить данные в памяти и записывать только по настроению, то нам не нужны такие заморочки с файловой системой. Мы можем реально буферизировать кучу операций и потом аккуратно скопом в нужном порядке записывать.
Но файловая система по-позможности должна писать максимально быстро на диск. Потеря данных на кеше очень неприятная для серьёзных систем. Да и для несерьёзных, тоже.
Вот как раз на первых фотографиях явно виден след от самого браслета, поэтому и предположил, что человек затянул его. В качестве других вариантов, могу предоложить, что браслет был поддельным и с острыми гранями. В центре как раз расположены датчики, т.е. раздражение и было максимально в центре. Ну а дальше просто рана пошла заживать таким страшным образом.
У меня 5-ый бенд, который круглосуточно меряет пульс, ничего не обнаружил у себя на руке. И сомневаюсь, что от такого фонарика можно что-то получить.
Вы в ответе за тех, кого приручили. Было бесчисленное количество ошибок, связанное с тем, что люди делали какой-то функционал для базовых сценариев, а все их использовали для других. Поэтому как раз в .NET и заюзали для этого не самый быстрый, но зато достаточно «случайный» метод Фиббоначи с запаздыванием. Чтобы как раз, кому надо быстроту, мог использовать и ЛКГ, а кому пофиг на всё — не ловил бы проблем из-за некачественной базовой реализации.
При компиляции ворнинг будет, но изначально вопрос был в том — что просто поставили новый фреймворк и взяли старый код. Тут, похоже, будет очень неприятно.
Вот сейчас выяснил, что сломали Thread.Abort
Т.е. код начнёт эпично валиться в непредсказуемых местах. И вот сколько таких мест может быть?
1. Будет ли прирост производительности просто от подсовывания нового рантайма
2. Не вылезут ли проблемы из-за того, что совместимость именно что декларируется. Т.е. могут взять метод и убрать у него реализацию (типа у нас новые правила) или изменить реализацию, что приведёт к косякам. А то у нас был весёлый пример с использованием рантайма 2.2 при разработке на 2.1. Несколько недель поиска проблемы.
Ну или совсем гулять — новым тулчейном компилять под netstandard2.0 и запускать на новом рантайме.
На всякий случай, отвечу на вопрос зачем: если не надо новых фич, то в целом повышать версию выглядит бессмысленно, бывает легаси и прочие замороженные проекты, которые нет смысла переводить на новый фреймворк, а зависимости свежие использовать хочется.
Но палки да, рисуют от балды все.
С проблемами типов при сериализации я встречался в JS, Python, .NET, когда умный парсер подставляет самый подходящий тип, а потом начинает ломаться. В .NET был, кстати, самый забавный случай, когда он строку, похожую на дату считал датой и портил её. И это функционал по умолчанию.
Не все и не всегда делают маппинг json/xml => объект. Бывают абстрактные десериализации, в абстрактный объект, бывает миграция версий, особенно для конфигов, когда хочется оставить поддержку старой версии. И всё может замечательно стрелять.
Можно придумать такой пример (стырил из nginx):
мы пишем прокси, и у нас в конфиге есть параметр proxy_redirect, который может принимать значения: true — делать редирект, переписывая хост автоматически. Нужно большинству пользователей. false — не делать, или строка, которая говорит, на какой хост редиректить. Мы не различаем false и «false» и всё работает до тех пор, когда у кого-то не оказался хост с названием false. Может даже как-то заработает, но могут появиться спец.эффекты.
Решение: две настройки, или воспользоваться типизацией.
Важно. Мне это в JSON тоже очень не нравится. Раньше была идея писать /Date(timestamp)/ — но тоже костыль и не прижилось.
Вот вообще не так для бинарной формы. Посмотрите хоть на Message Pack.
Есть другие типы, да. Но практически во всех языках есть понятия числа/строки/массива/словаря и это разумная и понятная база.