Я сейчас возможно наивную вещь скажу, но если кто-то большой условно плюет на 1-5% пользователей (из условного миллиарда), то это автоматом освобождает нишу для продукта, направленного как раз на это меньшинство.
Лично наблюдал разную цену для таксиста и пассажира — у меня цена со скидкой была 160, таксист в своем приложении видел только полные 180. Так что по крайней мере в Воронеже скидки похоже все-таки за счет Яндекса.
Если автомат классический, на гидротрансформаторе, то побыстрее с места — это заранее (но не слишком) нажать на газ, не отпуская тормоза до момента, когда надо тронуться. По быстрому обогнать на автобане — обычно можно заранее рассчитать момент, когда втопить газ с учётом лага переключения на пониженную в коробке, но если уж совсем никак — в большинстве современных автоматов можно перейти в "ручной" режим и самому заранее выбирать передачу, лага скорее всего не будет (по крайней мере у меня на hyundai нет).
Мм… это же не постфактум надо, а заранее, и с цифрами: "у нас готова черновая спека, но есть шанс, что в ней могут быть серьезные нестыковки. Разработка займет 8 месяцев с учетом возможных рисков, перед началом мы предлагаем потратить еще 2 недели на создание формальной модели, чтобы выявить и исправить эти нестыковки заранее, что позволит разработать конечный продукт за 4 месяца"
Так я и не говорил, что корректная спека не нужна — в обратную сторону как раз все четко, некорректная спека гарантирует некорректную реализацию. Я скорее про то, что TLA дополнение, а не замена тестам. А насчет генерации — вроде слышал, что B-Method может, но сам с этим инструментом не разбирался.
TLA проверяет спецификацию, а не код, что тоже полезно, но корректная спецификация ещё не гарантирует корректной реализации — для этого нужны либо тесты, либо средства, позволяющие генерить код прямо из спеки.
А вы не пробовали измерять производительность файловой системы, размещенной на этом устройстве (например с помощью sysbench)? Возможно я чего-то не понимаю, но у меня при экспериментах с пробрасыванием LVM-тома в виртуалку с virtio получалось следующее:
если мерить с помощью fio непосредственно производительность блочного устройства, то все как в статье — производительность на хосте и внутри виртуалки совпадает
если мерить с помощью sysbench производительность файловой системы (ext4) созданной на этом устройстве, то производительность в виртуалке проседает в 2-3 раза по сравнению с хостом
устройство реально одно и то же, просто по очереди монтировал либо на хосте, либо в виртуалке
тут я подумал — наверное где-то по дороге генерятся лишние IOPS, но если посмотреть на вывод iostat во время теста изнутри виртуалки, то IOPS и bandwidth в гостевой системе и на хосте совпадают, но они существенно ниже, чем когда тест идет непосредственно на хосте
зато во время теста изнутри виртуалки видно довольно большой (~30%) iowait, в это же время на хосте iowait почти нулевой, зато есть заметная нагрузка на проц (~20% system)
В какой-то момент я подумал на слабый проц (Celeron N3160), но на ноуте с Core i7 ситуация практически та же. И вот вопрос — откуда может быть такая просадка при работе с реальной файловой системой, и можно ли с этим что-то сделать, или это вообще нормальная ситуация? Но тогда почему синтетический тест непосредственно блочного устройства показывает практически нативную производительность?
UPD Ну и разумеется параметры у устройства io='native' cache='none' (пробовал еще directsync, но большой разницы не заметил)
К большому сожалению во всех приведенных ссылках в решениях хотя и указано, что суд установил, что были нарушения, но все равно "Предписание о прекращении нарушения законодательства о рекламе не выдавать"
Мне кажется эту картинку ПТ смогла выудить ещё за первый сеанс, сам я смог более менее объективно это понять недели через две-три лечения. Но вот слезть с антидепрессантов получилось только через полгода (кстати, это вроде считается довольно быстро). Я думаю мне очень повезло и с врачом, и с тем, что смог относительно вовремя заставить себя обратиться к специалисту. Сейчас тот период вспоминаю с лёгким содроганием.
Поэтому и прошу объяснить чуть-чуть подробнее, что же это такое, депрессия в Вашем понимании.
Представьте себе, что вы:
почти не можете заставить себя что-то действительно сделать — все силы отнимают сомнения как это делать, нужно ли делать вообще, и вообще космические корабли бороздят просторы большого театра. В мыслях легко зависнуть на десятки минут, раз — и в какой-то момент вы понимаете, что уже час сидите в дУше непонятно зачем
на вопрос "что ты хочешь" отвечаете "чего-нибудь наконец захотеть"
ощущаете огромный груз вины ("я ничего не могу", "я всем доставляю только проблемы")
в связи со всем выше перечисленным подробно и обстоятельно планируете способ надежно уйти из жизни — так, чтобы наверняка, и никто не успел остановить
В тот период по вышеупомянутому тесту набирал почти 30 баллов. Вылез благодаря хорошему психотерапевту.
Но большинство хостеров, предоставляющих небольшие VDS или облака под эти цели, не предоставляют возможность разложиться со своего образа. А ещё же нужен репозиторий для образа.
Это немного не так работает. Большинство облачных провайдеров предоставляют возможность создания снапшотов с виртуалок, и разворачивания новых виртуалок из этих самых снапшотов. Именно это и эксплуатируется пакером — он поднимает виртуалку прямо у вашего облачного провайдера из одного из базовых образов, предоставляемых провайдером, раскатывает туда нужный софт и сохраняет снапшот. Дальше с помощью любого инструмента управления облаком (хоть собственные скрипты, напрямую дергающие REST API, хоть терраформ) из этих снапшотов поднимается нужно количество виртуалок. Загрузка своих образов не нужна. А роль репозитория играет ваш аккаунт у облачного провайдера.
Да, стейтфул — это боль. Еще бОльшая боль — когда у вас bare metal который тоже как-то надо менеджить. В целом именно поэтому AWS и ему подобные успешно предлагают сервисы типа RDS — "мы вам настроим и будем поддерживать stateful сервис, а вы нам просто денежку платите".
Насчет дороговизны IaC на старте — не совсем согласен. Как только у вас появляется хотя бы два окружения (прод и стейджинг), то еще вопрос, что дороже — описать это как IaC, или руками поддерживать одинаковость этих окружений, и периодически при дебаге втыкаться в то, что окружения все-таки разные.
Хм, а как же packer, terraform и вроде как тенденция к переходу на "иммутабельную" инфраструктуру по возможности? Деплой виртуалок из готовых образов ведь быстрее и надёжнее, чем каждый раз раскатывать конфиг ансиблом на чистой системе, плюс повторяемость..
ССО через гугл — ну да, это удобно, но в этом случае ваша цифровая identity принадлежит гуглу, а не вам, со всеми вытекающими проблемами (от банального сбора информации о том, какими сервисами вы пользуетесь до проблем типа "кажется ваш аккаунт взломали, пока не подтвердите, что вы это вы — никуда не залогинетесь"). Существует мнение, что это неправильно, и что можно сделать лучше — даже термин придумали, для этого "лучше" — Self-Sovereign Identity. То, что предлагает автор статьи очень близко к идеям SSI.
Я сейчас возможно наивную вещь скажу, но если кто-то большой условно плюет на 1-5% пользователей (из условного миллиарда), то это автоматом освобождает нишу для продукта, направленного как раз на это меньшинство.
Лично наблюдал разную цену для таксиста и пассажира — у меня цена со скидкой была 160, таксист в своем приложении видел только полные 180. Так что по крайней мере в Воронеже скидки похоже все-таки за счет Яндекса.
Если автомат классический, на гидротрансформаторе, то побыстрее с места — это заранее (но не слишком) нажать на газ, не отпуская тормоза до момента, когда надо тронуться. По быстрому обогнать на автобане — обычно можно заранее рассчитать момент, когда втопить газ с учётом лага переключения на пониженную в коробке, но если уж совсем никак — в большинстве современных автоматов можно перейти в "ручной" режим и самому заранее выбирать передачу, лага скорее всего не будет (по крайней мере у меня на hyundai нет).
Мм… это же не постфактум надо, а заранее, и с цифрами: "у нас готова черновая спека, но есть шанс, что в ней могут быть серьезные нестыковки. Разработка займет 8 месяцев с учетом возможных рисков, перед началом мы предлагаем потратить еще 2 недели на создание формальной модели, чтобы выявить и исправить эти нестыковки заранее, что позволит разработать конечный продукт за 4 месяца"
Так я и не говорил, что корректная спека не нужна — в обратную сторону как раз все четко, некорректная спека гарантирует некорректную реализацию. Я скорее про то, что TLA дополнение, а не замена тестам. А насчет генерации — вроде слышал, что B-Method может, но сам с этим инструментом не разбирался.
TLA проверяет спецификацию, а не код, что тоже полезно, но корректная спецификация ещё не гарантирует корректной реализации — для этого нужны либо тесты, либо средства, позволяющие генерить код прямо из спеки.
Меня похожий вопрос интересовал, когда я решил попробовать ангуляр — ng init генерит не меньше кода, чем куб
А вы не пробовали измерять производительность файловой системы, размещенной на этом устройстве (например с помощью sysbench)? Возможно я чего-то не понимаю, но у меня при экспериментах с пробрасыванием LVM-тома в виртуалку с virtio получалось следующее:
В какой-то момент я подумал на слабый проц (Celeron N3160), но на ноуте с Core i7 ситуация практически та же. И вот вопрос — откуда может быть такая просадка при работе с реальной файловой системой, и можно ли с этим что-то сделать, или это вообще нормальная ситуация? Но тогда почему синтетический тест непосредственно блочного устройства показывает практически нативную производительность?
UPD Ну и разумеется параметры у устройства io='native' cache='none' (пробовал еще directsync, но большой разницы не заметил)
К большому сожалению во всех приведенных ссылках в решениях хотя и указано, что суд установил, что были нарушения, но все равно "Предписание о прекращении нарушения законодательства о рекламе не выдавать"
Бывают
Мне кажется эту картинку ПТ смогла выудить ещё за первый сеанс, сам я смог более менее объективно это понять недели через две-три лечения. Но вот слезть с антидепрессантов получилось только через полгода (кстати, это вроде считается довольно быстро). Я думаю мне очень повезло и с врачом, и с тем, что смог относительно вовремя заставить себя обратиться к специалисту. Сейчас тот период вспоминаю с лёгким содроганием.
Найти хорошего психотерапевта в частной клинике с положительными отзывами и с опытом работы в государственном учреждении соответствующего профиля.
Представьте себе, что вы:
В тот период по вышеупомянутому тесту набирал почти 30 баллов. Вылез благодаря хорошему психотерапевту.
О, им уже отличный merge request подкатили… https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/34037/diffs
Охотно верю (сам с таким в проде не сталкивался — используем только AWS). Но подозреваю, что руками это всё поддерживать не менее больно.
Это немного не так работает. Большинство облачных провайдеров предоставляют возможность создания снапшотов с виртуалок, и разворачивания новых виртуалок из этих самых снапшотов. Именно это и эксплуатируется пакером — он поднимает виртуалку прямо у вашего облачного провайдера из одного из базовых образов, предоставляемых провайдером, раскатывает туда нужный софт и сохраняет снапшот. Дальше с помощью любого инструмента управления облаком (хоть собственные скрипты, напрямую дергающие REST API, хоть терраформ) из этих снапшотов поднимается нужно количество виртуалок. Загрузка своих образов не нужна. А роль репозитория играет ваш аккаунт у облачного провайдера.
Да, стейтфул — это боль. Еще бОльшая боль — когда у вас bare metal который тоже как-то надо менеджить. В целом именно поэтому AWS и ему подобные успешно предлагают сервисы типа RDS — "мы вам настроим и будем поддерживать stateful сервис, а вы нам просто денежку платите".
Насчет дороговизны IaC на старте — не совсем согласен. Как только у вас появляется хотя бы два окружения (прод и стейджинг), то еще вопрос, что дороже — описать это как IaC, или руками поддерживать одинаковость этих окружений, и периодически при дебаге втыкаться в то, что окружения все-таки разные.
Хм, а как же packer, terraform и вроде как тенденция к переходу на "иммутабельную" инфраструктуру по возможности? Деплой виртуалок из готовых образов ведь быстрее и надёжнее, чем каждый раз раскатывать конфиг ансиблом на чистой системе, плюс повторяемость..
Т.е. по вашему модульные тесты не надо называть внятно?
ССО через гугл — ну да, это удобно, но в этом случае ваша цифровая identity принадлежит гуглу, а не вам, со всеми вытекающими проблемами (от банального сбора информации о том, какими сервисами вы пользуетесь до проблем типа "кажется ваш аккаунт взломали, пока не подтвердите, что вы это вы — никуда не залогинетесь"). Существует мнение, что это неправильно, и что можно сделать лучше — даже термин придумали, для этого "лучше" — Self-Sovereign Identity. То, что предлагает автор статьи очень близко к идеям SSI.