Я давно понял что ошибочно максимум логики переносить в базу данных, гемора много, требует больше ресурсов, памяти, процессора, дороже софт... только ради того, чтобы удовлетворить ощущение красоты разработчикам.
Базы данных это хранение и контроль целостности с транзакциями, все остальное лучше делать на стороне. Проще быстрее удобнее даже вытягивать данные из базы в оперативную память и там делать часть или всю аналитику с вычислениями.
а сразу свой запрос строить не получится?
я в mysql вообще сложную логикую не использовал, сейчас погуглил, способ обхода ограничения есть - создаешь хранимую процедуру, затем создаешь тригер (на обновление используемых данных или фиктивные) и в нем вызываешь свою процедуру, таким образом у тебя будет поле, в котором всегда будут вычисленные данные по формуле в поле
но мне кажется таким извращением лучше не заниматься, и вычислять на бакэнде, тем более у тебя вычисление цены явно однократное, история то не меняется?
'другая машина' в этой же локальной сети? пробовал тот же тест запускать с этой же машины?
что за железо то? типовой десктоп даст ~7к-10к rps
hello world действительно только выводит текст, ни к какой базе не подключается?
Ratenti, screen позволяет контролировать stdin и stdout приложения напрямую с клавиатуры, а с nohup придется перенаправлять вывод и химичить с пайпами.. но да nohup тоже решение.
Тут sdX имя устройства исходного диска, смотреть список lsblk
1024k это размер блока копируемых данные, не обязательно, но по умолчанию он по 512 байт читает
accountnujen, любые манипуляции с дисоком, с которого восстанавливаешь данные, если тебе эти данные важны, не рекомендуются! делать нужно только с их копией, чтобы по ошибке не потерять свой последний шанс на их восстановление
кстати, это может быть решением, можно установить windows в виртуалке, затем установить вручную драйвера (из inf файлов), подходящие для вашей материнки (хоть какие то), и уже после этого попробовать запустить эту установку на физической машине.
Я не автор поста но у меня вопрос, а на сколько дешевле реализовать вариант 'соединяют в цепочку'? 10G
Или это тупо дороже потому что нет адекватного железа для этого?
А вариант выбирать текущую stable версию и своевременно обновлять, но фишки использовать условно 'прошлогодние' плюс как договоришься?
Если работаешь в команде, то выбор той или иной фишки нужно будет оговаривать предварительно.
Таким образом, и гнаться за самым соком не понадобится, и как минимум проект будет будет заранее проверяться на прочность новой версией.
Заморозка технологий имеет смысл только если связанные вещи это требуют, например используемые библиотеки, но в случае языка это менее выражено. Грубо говоря, если вы используете библиотеку, которая 'не собирается' в новой версии Rust, тогда вы либо ее переписываете либо остаетесь на последней поддерживаемой ею версии.
Есть еще метод, он решает проблему, когда случайно размещенные объекты размещаются очень неэффективно и наступает момент когда поставить объект еще есть куда но случайным способом искать место долго.
Нужно при коллизии, запускать алгоритм расталкивания (все объекты, которые под коллизией друг с другом, начинают двигаться в сторону от их центра (если с двумя и более объект пересекается, то вектора направлений складываются для каждого, т.е. если сталкиваются машины A,B,C то для машины A складывать вектор движения из машин A-B и A-C), вычислять вектор движения для каждого, делать какой-то минимальный шаг (подбирать экспериментально, так как маленький шаг - долго, а большой шаг - будет большое расстояние между объектами), и повторять процесс в цикле до тех пор, пока не останется пересечений.
Проблема явно не с флешкой, ведь запуск с нее прошел успешно.
Мне известна только одна маловероятная ситуация, когда вина в способе настройки флешки, это запуск в режиме efi или mbr legacy, например без efi и нулевой драйверов диск не виден (что для старого 32 ноута маловероятно, там очевидно mbr).
Для начала нужен любой livecd образ linux (q4os основе на debian), и загрузившись в нем, изучите доступность дисков
У меня вопрос, а зачем делать resize под разные экраны, если тот же самый resize делает само устройство?
Заранее готовить изображения нужно если ты их специально делаешь попиксельно готовыми к определенному экрану, как минимум проверить глазами на наличие артефактов... иначе, выдавай наибольшего размера изображение и пусть устройство его отображает само, даже 10-летней давности железки с этим справляются без проблем.
Базы данных это хранение и контроль целостности с транзакциями, все остальное лучше делать на стороне. Проще быстрее удобнее даже вытягивать данные из базы в оперативную память и там делать часть или всю аналитику с вычислениями.