Не тестировали, но я подозреваю что была бы та же проблема как и котлиновские корутины. А проблема в том что хочется запустить много корутин. Это же легко и просто. Но в какой-то момент у тебя их становится сотни тысяч, и почти все в очереди на выполнение, что особенно неприятно если результат потребуется лишь от нескольких. А времени у тебя с десяток милисекунд.
Бесполезная работа (память, gc, пр.) лишь растет по мере того как переводишь на корутины. В Reactor это не проблема потому что pull модель и может обрабатывать условно бесконечный объем не требуя пропорционального увеличения ресурсов.
Понятно что все это можно оптимизировать, но если начал то мне лично проще делать это на обычной Java Concurrency, со всеми локами, семафорами и пр. Просто потому что предсказуемо работает. Поэтому Loom наверное тоже не вариант.
PS Довольно большая часть оптимизации (кроме переписывания на lock-free) сводится к тому что бы сделать свой backpressure. Больше положил в очередь - медленно, меньше - машина простаивает. Может лучше больше, но потом выкинуть лишнее. И т.д. Надо искать оптимум, и то как потоки с этим всем работают. Kotlin Flow все таки ограничен и неприменим когда у тебя множество входов. Нигде не получилось его применить. Но может для простого случая он и решает backpressure.
Я делал замеры на высокнагруженной системе где на каждый шаг собираются метрики. Код переписанный почти в лоб с реактора на потоки оказался сильно медленней. Потратив в разы больше времени на программирование, чтобы выжать максимум, удалось добиться той-же производительности, по метрикам разница -5%..+5% (на разные этапах). Жалко потерянного времени.
К слову, еще была попытка переписать на корутины Kotlin, это оказался полный провал с проседанием в 7 раз.
Reactor тоже прекрасен. И писать на нем легко и просто. Не задумываясь о потоках, локах и пр., пишешь за час решение задачи которое в императивном стиле писал бы неделю.
На самом деле это как давний вопрос "чем SQL лучше чем FoxPro". Т.е. декларативный vs императивный код.
Reactor это декларативный подход. Пулы это императивный подход. Для разных задач разное подходит. Декларативный же (Reactor) позволяет размышлять в терминах какой результат нужен, для систем с множеством ветвлений/зависимостей результата это помогает. С другой стороны как только вы видите что-то что вы знаете как оптимизировать как процесс выполнения - тут у вас все руки связаны.
Ну и еще в императивном стиле писать просто - любой школьник может. Декларативный же надо долго учить, и все равно есть сотня способов отстрелить себе ногу. Я был фанатом декларативного / rector, но уже устал от простреленных ног.
Недавно нужно было срочно пофиксить сайт на Tailwind. Я обычно не занимаюсь этими вещами, но тут нужный человек отсутствовал. И получилось что задача которая с обычным CSS занимала бы максимум 5 минут, здесь заняла почти два часа.
Под "обычным css" я имею ввиду Bootstrap, MUI и пр. которые построены в декларативном стиле. В этом случае достаточно пометить "это панель", а "это навигация" и дальше все работает, применяя внешний вид который прописан отдельно и для всего приложения вцелом. В случае Tailwind так не получилось, и пришлось индивидуально прописывать как должен блок выглядеть.
Мне кажется удобней указывать "что это" (bootstrap, etc), а не "как это выглядит" (tailwind). Потому что первое лучше вписывается в модель HTML и CSS. Второе может быть удобней для дизайнера который каждый элемент прорисовывает индивидуально. Но я не представляю как поддерживать какой-то большой сайт с таким подходом.
Поправьте меня если я что-то не так понял в Tailwind.
Задача же Merge — кратно увеличить пропускную способность сети, обеспечивая максимально высокий уровень секьюрности
Потому что у вас дальше в "Какие риски нас ждут" идут пункты про то что безопасность упадет, если я правильно понял.
И про "Доступное валидаторство" тоже не сильно понятно, потому что не похоже что 32 ETH это дешевле покупки видеокарты. Что вы в следующем пункте и пишете. Непонятно что вы имеете ввиду, где правда
Я хоть и согласен что Filecoin не работает, но не соглашусь с методом оценки. Потому что если взять примеры традиционных бизнесов то мы видим тоже самое.
Например Amazon, безусловный лидер торговли и централизованного хостинга, их убыток за последний квартал был 2 млрд. долларов. Т.е. Amazon тоже работает в убыток, но никто не говорит что онлайн торговля и централизованный хостинг не работают.
Супруга может получить свою отдельную визу. Точнее статус. Если работодатель найдется.
Важно понимать что тут две части. Есть рабочий статус O1, это самое главное, а есть виза на этот статус. Подать на статус можно и внутри страны, и за пределами. Если за пределами то вам нужно потом и визу проставить. Виза нужна только пограничникам, иначе у них нет оснований вас впустить. Если вы уже внутри страны (по туристической визе влетели, например), то можете и не ставить визу пока не понадобится слетать за пределы США.
Можно еще криптовалюты. Не надо летать за ними.
В Нью-Йорке можно. А в остальных городах вряд ли, это факт
Про деньги не обязательно как у автора. По-идее за визу и адвоката платит работодатель. В статье автор сам себя устроил в свой бизнес. Но вообще это для тех кто устраивается на работу, поэтому деньги вам нужны только на свой личный переезд.
Если этот системник подключен к сети то уже небезопасно, могу взломать извне. Нужно два системника, один онлайн — другой офлайн. Скачивать блоки на сервере "онлайн" и потом флешкой копировать на сервер "офлайн".
Посмотрел private fun encrypting_data():String. Не надо так делать.
Во-первых, вы используете дефолтные настройки AES а для JVM это AES/ECB/NoPadding, что вообще не подходит для чего угодно серьезного. С ECB можно шифровать только в пределах длинны ключа, т.е. приемлемая длинна текста для шифрования это 128 или 256 бит. В зависимости от того какой длинны AES у вас, а вы его тоже не указали
Во-вторых, ключ тоже используете без каких либо настроек. Значит размерность AES у вас возьмется из длинны ключа, и конкретно пароля. И на 256 бит видимо рассчитывать не придется, потому что не будет пользователь вводить пароль из 32 символов.
И в-третих. Не надо напрямую пароль пихать в шифрование. Особенно в данном случае, когда все по умолчанию и без безопасных настроек. Для пароля есть различные KDF, используйте хотя бы стандартный PBKDF2
Я думал вы отвечаете на мой вопрос почему в статье написано что PoS выбирает случайных участников, и PoW, соответсвенно, нет. Но судя по этому ответу вы не спорите с моим вопросом.
Т.е. вы хотите сказать что весь консенсус это кто первый сгенерил блок и поэтому оно случайно? Тогда почему это более случайно чем консенсус по которому выбирается первый кто нашел нужный хэш? PoW по этому критерию еще больше подходит под "случайно выбранный участник сети"
Возвращаясь к PoS. Если лишь случайная нода генерит блок, то как тогда бороться с атаками и форками? Какую ветку выбирать в случае форка? И особенно с учетом что все текущие P2P соединения вашей ноды могут контролироваться злоумышленником?
Proof of Stake (POS) использует случайно выбранных участников сети
Можете что вы имеет ввиду? По-первых "случайных" это не сильно решаемая проблема, вся индустрия криптографии бьется над решением этой проблемы. А во-вторых в PoS, насколько мне известно, все наоборот, и распределение участников строго детерминированно в соответствии с алгоритмом.
Я отношусь нормально к криптовалюте, и как раз заметил что модные шиткоины (или как вы назвали марки) это временное явление.
Ценность не зависит от энергии, proof-of-work ведь не про это. А про надежность (которая включает стоимость отмены транзации, цензуры, влияния на порядок, открытость и пр), и на данный момент PoS не продемонстрировал никаких успехов. Возможно за этим и будущее, но пока устойчивость продемонстрирована только PoW
Устойчивый. Было время в лидерах были модные EOS, TRX, BCH, IOTA, DASH, NEO, QTUM, BTG, LSK, ICX, XEM и пр, теперь далеко не в лидерах. Сейчас вы говорите про модные Solana, Polkadot и Polygon, но вероятность что они останутся активными через 2-3 года очень мала.
Смотрите на устойчивость позиций в периоде больше чем один год, тут Bitcoin лидер с огромным отрывом.
Не тестировали, но я подозреваю что была бы та же проблема как и котлиновские корутины. А проблема в том что хочется запустить много корутин. Это же легко и просто. Но в какой-то момент у тебя их становится сотни тысяч, и почти все в очереди на выполнение, что особенно неприятно если результат потребуется лишь от нескольких. А времени у тебя с десяток милисекунд.
Бесполезная работа (память, gc, пр.) лишь растет по мере того как переводишь на корутины. В Reactor это не проблема потому что pull модель и может обрабатывать условно бесконечный объем не требуя пропорционального увеличения ресурсов.
Понятно что все это можно оптимизировать, но если начал то мне лично проще делать это на обычной Java Concurrency, со всеми локами, семафорами и пр. Просто потому что предсказуемо работает. Поэтому Loom наверное тоже не вариант.
PS Довольно большая часть оптимизации (кроме переписывания на lock-free) сводится к тому что бы сделать свой backpressure. Больше положил в очередь - медленно, меньше - машина простаивает. Может лучше больше, но потом выкинуть лишнее. И т.д. Надо искать оптимум, и то как потоки с этим всем работают. Kotlin Flow все таки ограничен и неприменим когда у тебя множество входов. Нигде не получилось его применить. Но может для простого случая он и решает backpressure.
Код закрыть. Но это в любом случае много кода, и это не про ошибки, а про архитектурные особенности подходов.
Сильно медленней это раза в полтора, но точно уже не помню потому что такой вариант долго не жил в проде.
Я делал замеры на высокнагруженной системе где на каждый шаг собираются метрики. Код переписанный почти в лоб с реактора на потоки оказался сильно медленней. Потратив в разы больше времени на программирование, чтобы выжать максимум, удалось добиться той-же производительности, по метрикам разница -5%..+5% (на разные этапах). Жалко потерянного времени.
К слову, еще была попытка переписать на корутины Kotlin, это оказался полный провал с проседанием в 7 раз.
Reactor тоже прекрасен. И писать на нем легко и просто. Не задумываясь о потоках, локах и пр., пишешь за час решение задачи которое в императивном стиле писал бы неделю.
На самом деле это как давний вопрос "чем SQL лучше чем FoxPro". Т.е. декларативный vs императивный код.
Reactor это декларативный подход. Пулы это императивный подход. Для разных задач разное подходит. Декларативный же (Reactor) позволяет размышлять в терминах какой результат нужен, для систем с множеством ветвлений/зависимостей результата это помогает. С другой стороны как только вы видите что-то что вы знаете как оптимизировать как процесс выполнения - тут у вас все руки связаны.
Ну и еще в императивном стиле писать просто - любой школьник может. Декларативный же надо долго учить, и все равно есть сотня способов отстрелить себе ногу. Я был фанатом декларативного / rector, но уже устал от простреленных ног.
Соглашусь с автором, особенно с первым пунктом.
Недавно нужно было срочно пофиксить сайт на Tailwind. Я обычно не занимаюсь этими вещами, но тут нужный человек отсутствовал. И получилось что задача которая с обычным CSS занимала бы максимум 5 минут, здесь заняла почти два часа.
Под "обычным css" я имею ввиду Bootstrap, MUI и пр. которые построены в декларативном стиле. В этом случае достаточно пометить "это панель", а "это навигация" и дальше все работает, применяя внешний вид который прописан отдельно и для всего приложения вцелом. В случае Tailwind так не получилось, и пришлось индивидуально прописывать как должен блок выглядеть.
Мне кажется удобней указывать "что это" (bootstrap, etc), а не "как это выглядит" (tailwind). Потому что первое лучше вписывается в модель HTML и CSS. Второе может быть удобней для дизайнера который каждый элемент прорисовывает индивидуально. Но я не представляю как поддерживать какой-то большой сайт с таким подходом.
Поправьте меня если я что-то не так понял в Tailwind.
Можете подробней про
Потому что у вас дальше в "Какие риски нас ждут" идут пункты про то что безопасность упадет, если я правильно понял.
И про "Доступное валидаторство" тоже не сильно понятно, потому что не похоже что 32 ETH это дешевле покупки видеокарты. Что вы в следующем пункте и пишете. Непонятно что вы имеете ввиду, где правда
Я хоть и согласен что Filecoin не работает, но не соглашусь с методом оценки. Потому что если взять примеры традиционных бизнесов то мы видим тоже самое.
Например Amazon, безусловный лидер торговли и централизованного хостинга, их убыток за последний квартал был 2 млрд. долларов. Т.е. Amazon тоже работает в убыток, но никто не говорит что онлайн торговля и централизованный хостинг не работают.
Имхо она на порядок проще чем в Европе и России
У вас все шансы
Супруга может получить свою отдельную визу. Точнее статус. Если работодатель найдется.
Важно понимать что тут две части. Есть рабочий статус O1, это самое главное, а есть виза на этот статус. Подать на статус можно и внутри страны, и за пределами. Если за пределами то вам нужно потом и визу проставить. Виза нужна только пограничникам, иначе у них нет оснований вас впустить. Если вы уже внутри страны (по туристической визе влетели, например), то можете и не ставить визу пока не понадобится слетать за пределы США.
Можно еще криптовалюты. Не надо летать за ними.
В Нью-Йорке можно. А в остальных городах вряд ли, это факт
Про деньги не обязательно как у автора. По-идее за визу и адвоката платит работодатель. В статье автор сам себя устроил в свой бизнес. Но вообще это для тех кто устраивается на работу, поэтому деньги вам нужны только на свой личный переезд.
Если этот системник подключен к сети то уже небезопасно, могу взломать извне. Нужно два системника, один онлайн — другой офлайн. Скачивать блоки на сервере "онлайн" и потом флешкой копировать на сервер "офлайн".
А про солнце и погоду?
Посмотрел
private fun encrypting_data():String. Не надо так делать.Во-первых, вы используете дефолтные настройки AES а для JVM это
AES/ECB/NoPadding, что вообще не подходит для чего угодно серьезного. С ECB можно шифровать только в пределах длинны ключа, т.е. приемлемая длинна текста для шифрования это 128 или 256 бит. В зависимости от того какой длинны AES у вас, а вы его тоже не указалиВо-вторых, ключ тоже используете без каких либо настроек. Значит размерность AES у вас возьмется из длинны ключа, и конкретно пароля. И на 256 бит видимо рассчитывать не придется, потому что не будет пользователь вводить пароль из 32 символов.
И в-третих. Не надо напрямую пароль пихать в шифрование. Особенно в данном случае, когда все по умолчанию и без безопасных настроек. Для пароля есть различные KDF, используйте хотя бы стандартный PBKDF2
Я думал вы отвечаете на мой вопрос почему в статье написано что PoS выбирает случайных участников, и PoW, соответсвенно, нет. Но судя по этому ответу вы не спорите с моим вопросом.
Т.е. вы хотите сказать что весь консенсус это кто первый сгенерил блок и поэтому оно случайно? Тогда почему это более случайно чем консенсус по которому выбирается первый кто нашел нужный хэш? PoW по этому критерию еще больше подходит под "случайно выбранный участник сети"
Возвращаясь к PoS. Если лишь случайная нода генерит блок, то как тогда бороться с атаками и форками? Какую ветку выбирать в случае форка? И особенно с учетом что все текущие P2P соединения вашей ноды могут контролироваться злоумышленником?
У вас написано:
Можете что вы имеет ввиду? По-первых "случайных" это не сильно решаемая проблема, вся индустрия криптографии бьется над решением этой проблемы. А во-вторых в PoS, насколько мне известно, все наоборот, и распределение участников строго детерминированно в соответствии с алгоритмом.
Если у вас по делу есть что-то сказать то давайте обсуждать. Если вам лишь карму набить бессмысленными комментариями, то это не ко мне.
Я отношусь нормально к криптовалюте, и как раз заметил что модные шиткоины (или как вы назвали марки) это временное явление.
Ценность не зависит от энергии, proof-of-work ведь не про это. А про надежность (которая включает стоимость отмены транзации, цензуры, влияния на порядок, открытость и пр), и на данный момент PoS не продемонстрировал никаких успехов. Возможно за этим и будущее, но пока устойчивость продемонстрирована только PoW
Скажите как вы это представляете на уровне API децентрализованной биржы?
Устойчивый. Было время в лидерах были модные EOS, TRX, BCH, IOTA, DASH, NEO, QTUM, BTG, LSK, ICX, XEM и пр, теперь далеко не в лидерах. Сейчас вы говорите про модные Solana, Polkadot и Polygon, но вероятность что они останутся активными через 2-3 года очень мала.
Смотрите на устойчивость позиций в периоде больше чем один год, тут Bitcoin лидер с огромным отрывом.