Потому что это не ИИ и фантазии у него нет :) Любой из предложенных Dalle вариантов, это поиск в уже известных образах и усреднение с долей рандома (что и создаёт эффект однообразия — «лучшие» варианты будут похожи). Тоесть, строго говоря, именно «креативности» там нет вообще, а весь эффект, это лишь способность «склеить» неподходящие образы каким-то образом и «узнавание» образов. ML в данный момент может стать ассистентом с неплохим кругозором, но не дизайнером.
С ходу много — простой бенч даёт 15 аллокаций на итерацию (извлечение 1 значения) на бесконечный стрим (nats из примера) + 1 map (powers из примера).
При этом если брать пачкой (используя не Head, а Take), то количество аллокаций растёт кратно, что печально.
Но это не выглядит как шоустоппер — сейчас код идеоматичный и простой. Если нужно выжимать из него соки, есть несколько понятных путей: реюз внутренних структур, батчинг при работе с массивом (почти наверняка можно сделать Take(x,10) более экономичной чем Head(x)x10 в близкое к 10 количество раз), пуллинг.
Если не делать return значения скастованого из uintptr то не должно быть проблем, ведь если данные снаружи, то GC их не тронет, а если изнутри, то keepalive (оригинальной структуры, а не новой из uintptr) в пределах блока сработает. С return конечно сложнее.
Да, с этим соглашусь — там таки есть интересная система сдержек и противовесов, замечание про затраты магнатов и их «ставку» тоже очень дельные. Я широко взял когда пытался раскрыть тезис о майнинге на каждом телефоне. На мой взгляд этот поинт я более-менее верно раскрыл :) а вот дальше стал рассуждать чуть поверхностнее чем нужно. Спасибо за замечания.
Если майнинг не вознаграждается → никто этого не будет делать → падает защищённость сети.
Поскольку без большой мощности задействованых ресурсов, появляется возможность относительно скромным ресурсом провести атаку 50%+1.
Если майнинг вознаграждается → появляются «магнаты».
Магнаты концентрируют в своих руках большую часть ресурсов задействованых в сети. В идеале их более чем 1. Чем больше магнатов, тем более защищённая сеть (потому что гипотетически им сложно договориться), но тем дороже стоимость входа в майнинг, на уровень окупаемости (потому что конкурируешь ты с магнатами у которых на порядки больше ресурса и как следствие вероятности выигрыша).
Как защититься и от недостатка ресурсов (чтобы даже малая сеть была защищена от атаки 50%+1 мощности) и от избытка ресурсов собранного в руках магнатов да ещё и одновременно — кажется пока никто так и не придумал и движения в этом направлении не видно, по крайней мере если не копать очень уж глубоко.
Майнинг на телефоне (ну и любом маломощном устройстве) — бессмысленная вещь потому что если он будет без вознаграждения то никто не будет этим заниматься, а если будет вознаграждаться — то появятся фермы у магнатов, которые и будут собирать всё вознаграждения, оставляя индивидуальным пирам крохи вероятностей получения награды. Но даже если гипотетически выключить из цепочки крупных игроков и предположить, что сеть держится на миллиарде примерно одинаковых нод, то вероятность на получение награды для каждого индивидуального устройства — будет смехотворной (несмотря на то что кто-то всё же её конечно получит). Либо, сама награда будет столь ничтожной, что её получение ни на что не повлияет (у нас миллиард нод).
Это если я всё правильно понимаю и не пропустил каких-то радикальных сдвигов парадигм в криптовалютном мире :)
И со своей колокольни плюсую точку зрения amarao, о proof of waste. И именно исходя из этого, таки есть принципиальная необходимость в том, чтобы майнеры обладали огромными ресурсами. Потому что такие майнеры всё равно придут, чтобы собрать большую часть награды, либо сломать сеть тем фактом, что у них куча свободной мощности. И сеть должна включать в себя защиту от таких ситуаций, либо критерий позволяющий оценить защищённость сети.
Ну и если говорить более обобщённо. ИМХО, при наличии доверенных институтов ценность криптографического консенсуса, принято переоценивать, думая, что он магическим образом выключает из цепочки необходимость доверять кому-то. Но этот консенсус, точно так же требует доверия. Хотя-бы к тому факту, что мощность сети, не будет сконцентрированна в одних руках, хотя бы на 50%+1 единицу :) Ну и заодно, к тому, что реализация не была скомпрометирована, потому что абсолютное большинство участников не способны провести достаточно глубокий анализ хотя-бы спецификации протокола на отсутствие бэкдоров. Тоесть вместо условного государства как доверенного агента контролирующего эмиссию, мы получаем как минимум доверие кругу анонимов (о том, что они не являются единым целым или не договариваются) и доверие к авторам спеки по которой работает сеть. Плюс авторы реализаций используемых для непосредственной работы сети. И большая цепочка посредников обслуживающих всё это дело, для среднего пользователя (эта часть отпадает для тех кто держит полноценные ноды самостоятельно и не юзает легковесные кошельки).
Кода становится в 10 раз меньше даже если переписать с PHP на PHP :) Ключевое слово тут «переписать».
А-то отличное сравнение выходит, полностью новая кодовая база против десятилетнего монолита который разрабатывали несколько волн разработчиков.
Да, примерно это и делалось — маунтились кэши в контейнеры.
Из плюсов BuildKit’а — можно явно указать разрешено ли совместное использование и изменение, или нет. Я не рискнул просто маунтить директорию поскольку не уверен в безопасности параллельных сборок в таком случае. С BuildKit можно запускать параллельно, просто результат докачки одного из запусков пропадёт.
Хорошая статья! Делал такое для golang, но столкнулся с тем, что при активной разработке go.mod меняется всё равно не редко (особенно если сервисов много). И тут на помощь пришел BuldKit.
С ним становится ещё проще, поскольку можно указать напрямую какие директории можно шарить между разными запусками даже если поменялось что-то из слоёв. Работает как если бы шареная директория была отдельным volume который подключается на этапе сборки, можно указывать политики разделения этой директории.
Вы по аватарке уже расписали как это человек пишет код, какие выводы он делает из разных ситуаций, какие паттерны и почему он использует. При этом о себе вы видимо совершенно противоположного мнения. Вы не студент, не любите паттерны, при этом знаете что является оверхедом в ситуации вашего оппонента, а что нет (в отличии от него самого). При этом вы не стесняясь перешли на личности. Я удивлён что Fesor продолжил вам отвечать.
Ваше поведение неимоверно смешно, и невероятно глупо, извините…
И вас совершенно не напрягает, что такие рутинные операции приходится гуглить?
В любом наборе компонентов вам придётся что-то гуглить. Это нормально.
И понимаете, я тоже могу разобрать фреймворк и сделать что-то свое, но на всех собеседованиях что я был, меня гоняли по стандартным компонентам.
А меня нет. Меня в большинстве случаев вообще не гоняли по фреймворку, спрашивали более общие вещи.
Но если вы работаете в одиночку или тимлид, то вы правы.
Я работаю в достаточно большой команде. На данный момент, не тимлид.
Только по-моему ваш вариант и является по сути микрофеймворком.
По размеру — да, по определению — нет, микрофреймворк традиционно представляет собой роутер и DI без обвеса. Мой вариант — произвольный набор компонентов. Это не так важно в общем-то. Я к тому, что если понимаешь что делаешь, вообще не важно что используешь. Всегда придётся прикладывать какой-то процент усилий на борьбу с абстракциями окружения. Мне удобно с symfony-like стилем, вам нет — ок. Это холивар, правильного ответа нет)
Вы пишете, что работаете с Syfmony 4 года, но в разделе Symfony-only developer, приводите достаточно простые операции. Я знаю, как делается примерно половина из этого, а вторую половину загуглю за 15 минут. И с чистой симфони я ни разу серьезно не работал, единственный раз, лёжа в больнице от нечего делать написал хелловорд. У меня для вас плохие новости.
Да, симфони как правило сложен. Не трогайте его больше. Он вам не нужен. Вы не испытываете проблем, которые призван решать этот фреймворк.
Одна из таких проблем — отсутствие необходимости во фреймворке. Я могу разобрать симфони, и получить механизм способный решать конкретные задачи лучше чем любой другой фреймворк, и объём написаного кода будет меньше трёх сотен строк. Я выкину ненужный Doctrine, систему контроллеров, ассеты, ацл, и различные консольные приблуды, и буду работать только с тем, что мне нужно. Если что-то мне понадобится, я без проблем верну это, написав ещё 100 строк. И благодаря соглашениям и философии симфони, другой программист пришедший на проект быстро разберется в коде. В отличии от ужасных в этом плане микрофреймворков в которых черт ногу сломит.
Статья выглядит как попытка получить индульгенцию от толпы. Отсутствие конкретных выводов, подтверждает моё предположение :) Я года полтора назад тоже хотел написать такую статью, про то как тяжело жить с непредсказуемым Yii, потом понял, не тяжело. Просто нужно правильно выбирать инструмент для задачи. Статью так и не написал)
Спасибо! Об этом в курсе, пока не успели зарелизить фикс =)
Давайте дальше по багам в личку (а лучше в форму саппорта на сайте), комменты не очень удобны для фиксации багов
Ещё раз спасибо всем неравнодушным, кто отписался о проблемах, мы приняли к сведению и работаем над этим =)
«Это» — что? «Надо» — кому? Я не утверждаю, что Dalle не нужен вовсе чтобы так абстрактно отвечать :)
Потому что это не ИИ и фантазии у него нет :) Любой из предложенных Dalle вариантов, это поиск в уже известных образах и усреднение с долей рандома (что и создаёт эффект однообразия — «лучшие» варианты будут похожи). Тоесть, строго говоря, именно «креативности» там нет вообще, а весь эффект, это лишь способность «склеить» неподходящие образы каким-то образом и «узнавание» образов. ML в данный момент может стать ассистентом с неплохим кругозором, но не дизайнером.
С ходу много — простой бенч даёт 15 аллокаций на итерацию (извлечение 1 значения) на бесконечный стрим (nats из примера) + 1 map (powers из примера).
При этом если брать пачкой (используя не
Head, аTake), то количество аллокаций растёт кратно, что печально.Но это не выглядит как шоустоппер — сейчас код идеоматичный и простой. Если нужно выжимать из него соки, есть несколько понятных путей: реюз внутренних структур, батчинг при работе с массивом (почти наверняка можно сделать
Take(x,10)более экономичной чемHead(x)x10 в близкое к 10 количество раз), пуллинг.Если не делать return значения скастованого из uintptr то не должно быть проблем, ведь если данные снаружи, то GC их не тронет, а если изнутри, то keepalive (оригинальной структуры, а не новой из uintptr) в пределах блока сработает. С return конечно сложнее.
Да, с этим соглашусь — там таки есть интересная система сдержек и противовесов, замечание про затраты магнатов и их «ставку» тоже очень дельные. Я широко взял когда пытался раскрыть тезис о майнинге на каждом телефоне. На мой взгляд этот поинт я более-менее верно раскрыл :) а вот дальше стал рассуждать чуть поверхностнее чем нужно. Спасибо за замечания.
Если майнинг не вознаграждается → никто этого не будет делать → падает защищённость сети.
Поскольку без большой мощности задействованых ресурсов, появляется возможность относительно скромным ресурсом провести атаку 50%+1.
Если майнинг вознаграждается → появляются «магнаты».
Магнаты концентрируют в своих руках большую часть ресурсов задействованых в сети. В идеале их более чем 1. Чем больше магнатов, тем более защищённая сеть (потому что гипотетически им сложно договориться), но тем дороже стоимость входа в майнинг, на уровень окупаемости (потому что конкурируешь ты с магнатами у которых на порядки больше ресурса и как следствие вероятности выигрыша).
Как защититься и от недостатка ресурсов (чтобы даже малая сеть была защищена от атаки 50%+1 мощности) и от избытка ресурсов собранного в руках магнатов да ещё и одновременно — кажется пока никто так и не придумал и движения в этом направлении не видно, по крайней мере если не копать очень уж глубоко.
Майнинг на телефоне (ну и любом маломощном устройстве) — бессмысленная вещь потому что если он будет без вознаграждения то никто не будет этим заниматься, а если будет вознаграждаться — то появятся фермы у магнатов, которые и будут собирать всё вознаграждения, оставляя индивидуальным пирам крохи вероятностей получения награды. Но даже если гипотетически выключить из цепочки крупных игроков и предположить, что сеть держится на миллиарде примерно одинаковых нод, то вероятность на получение награды для каждого индивидуального устройства — будет смехотворной (несмотря на то что кто-то всё же её конечно получит). Либо, сама награда будет столь ничтожной, что её получение ни на что не повлияет (у нас миллиард нод).
Это если я всё правильно понимаю и не пропустил каких-то радикальных сдвигов парадигм в криптовалютном мире :)
И со своей колокольни плюсую точку зрения amarao, о proof of waste. И именно исходя из этого, таки есть принципиальная необходимость в том, чтобы майнеры обладали огромными ресурсами. Потому что такие майнеры всё равно придут, чтобы собрать большую часть награды, либо сломать сеть тем фактом, что у них куча свободной мощности. И сеть должна включать в себя защиту от таких ситуаций, либо критерий позволяющий оценить защищённость сети.
Ну и если говорить более обобщённо. ИМХО, при наличии доверенных институтов ценность криптографического консенсуса, принято переоценивать, думая, что он магическим образом выключает из цепочки необходимость доверять кому-то. Но этот консенсус, точно так же требует доверия. Хотя-бы к тому факту, что мощность сети, не будет сконцентрированна в одних руках, хотя бы на 50%+1 единицу :) Ну и заодно, к тому, что реализация не была скомпрометирована, потому что абсолютное большинство участников не способны провести достаточно глубокий анализ хотя-бы спецификации протокола на отсутствие бэкдоров. Тоесть вместо условного государства как доверенного агента контролирующего эмиссию, мы получаем как минимум доверие кругу анонимов (о том, что они не являются единым целым или не договариваются) и доверие к авторам спеки по которой работает сеть. Плюс авторы реализаций используемых для непосредственной работы сети. И большая цепочка посредников обслуживающих всё это дело, для среднего пользователя (эта часть отпадает для тех кто держит полноценные ноды самостоятельно и не юзает легковесные кошельки).
В СУБД и логгируется наверное :)
Сообщество.
https://trends.google.com/trends/explore?date=all&q=%2Fm%2F05967y,%2Fm%2F09gbxjr,%2Fm%2F05z1_,%2Fm%2F0609p
Кода становится в 10 раз меньше даже если переписать с PHP на PHP :) Ключевое слово тут «переписать».
А-то отличное сравнение выходит, полностью новая кодовая база против десятилетнего монолита который разрабатывали несколько волн разработчиков.
Да, примерно это и делалось — маунтились кэши в контейнеры.
Из плюсов BuildKit’а — можно явно указать разрешено ли совместное использование и изменение, или нет. Я не рискнул просто маунтить директорию поскольку не уверен в безопасности параллельных сборок в таком случае. С BuildKit можно запускать параллельно, просто результат докачки одного из запусков пропадёт.
Хорошая статья! Делал такое для golang, но столкнулся с тем, что при активной разработке
go.modменяется всё равно не редко (особенно если сервисов много). И тут на помощь пришел BuldKit.С ним становится ещё проще, поскольку можно указать напрямую какие директории можно шарить между разными запусками даже если поменялось что-то из слоёв. Работает как если бы шареная директория была отдельным volume который подключается на этапе сборки, можно указывать политики разделения этой директории.
Ваше поведение неимоверно смешно, и невероятно глупо, извините…
В любом наборе компонентов вам придётся что-то гуглить. Это нормально.
А меня нет. Меня в большинстве случаев вообще не гоняли по фреймворку, спрашивали более общие вещи.
Я работаю в достаточно большой команде. На данный момент, не тимлид.
По размеру — да, по определению — нет, микрофреймворк традиционно представляет собой роутер и DI без обвеса. Мой вариант — произвольный набор компонентов. Это не так важно в общем-то. Я к тому, что если понимаешь что делаешь, вообще не важно что используешь. Всегда придётся прикладывать какой-то процент усилий на борьбу с абстракциями окружения. Мне удобно с symfony-like стилем, вам нет — ок. Это холивар, правильного ответа нет)
Да, симфони как правило сложен. Не трогайте его больше. Он вам не нужен. Вы не испытываете проблем, которые призван решать этот фреймворк.
Одна из таких проблем — отсутствие необходимости во фреймворке. Я могу разобрать симфони, и получить механизм способный решать конкретные задачи лучше чем любой другой фреймворк, и объём написаного кода будет меньше трёх сотен строк. Я выкину ненужный Doctrine, систему контроллеров, ассеты, ацл, и различные консольные приблуды, и буду работать только с тем, что мне нужно. Если что-то мне понадобится, я без проблем верну это, написав ещё 100 строк. И благодаря соглашениям и философии симфони, другой программист пришедший на проект быстро разберется в коде. В отличии от ужасных в этом плане микрофреймворков в которых черт ногу сломит.
Статья выглядит как попытка получить индульгенцию от толпы. Отсутствие конкретных выводов, подтверждает моё предположение :) Я года полтора назад тоже хотел написать такую статью, про то как тяжело жить с непредсказуемым Yii, потом понял, не тяжело. Просто нужно правильно выбирать инструмент для задачи. Статью так и не написал)
Ответ на хабре и ответ в саппорте, несколько разные вещи, поэтому и времени на них нужно по разному)) Но и над этим мы тоже работаем)
Давайте дальше по багам в личку (а лучше в форму саппорта на сайте), комменты не очень удобны для фиксации багов
Ещё раз спасибо всем неравнодушным, кто отписался о проблемах, мы приняли к сведению и работаем над этим =)