Бакэнд работает по принципу php cgi или php app? т.е. php запускается и завершает свою работу на каждый запрос или постоянно запущенное приложение web сервер?
так это хорошо, еще помогает избегать конфликтов при повторных имен функций
охуенный план
что мешает именам пересечься в пределах одной сессии?
p.s. абсолютно бессмысленная оптимизация, возможна конечно ситуация и у тебя десятки тысяч функций, но это слишком уж странный случай тогда.
еще бывают хитрые контроллеры дисков, могут задействовать оперативную память машины (я такое не видел но это возможно), обычно не встроенное а отдельно покупаемое
Rinkashikikato, как ни странно fat32 будет наиболее эффективно (по скорости) работать как на windows так и на linux, но ограничение в 2гб на файл многих не устраивает
всего 8х8 ячеек? решение с мультиплексором идеально
обычно датчики опрашивают по сетке в данном случае 8х8, по горизонтальным и вертикальным пробегает сигнал переключения (к примеру горизонтальный в 8 раз медленнее вертикального), на пересечении опрашиваемый датчик
кстати а не хватит ли 8+8=16 дорожек ардуинки? ведь можно ее средствами сразу все опрашивать, максимум будет фальшивые срабатывания при одновременных нажатиях на несколько ячеек
с root проблем никаких не будет, откуда бы ты его не взял, за исключением установленных kernel modules и kernel headers, если они не будут соответствовать используемому ядру то многое не будет работать
речь именно о выбранном vmlinuz и initramfs.img и ключами запуска
Единственный способ обеспечить работу в гетерогенной среде (тогда и права можно будет настроить) - это установить сервер (даже если его настроить в виртуалке, был у меня такой случай), но даже в этом случае сетевой доступ невероятно не эффективен (и у майкрософта и у linux), у меня был случай когда обычная дозапись в файл (тысячи iops) локально работала очень быстро, а тот же самый код на такое же железо но на рядом стоящий сервер по nfs - сильно шуршал диском (smb еще хуже)
а ты vmlinuz и initrd изначальный какое взял?
например linux*-kvm (ядро, образ и заголовки), оптимизированы для запуска внутри kvm виртуалки, очень быстро проходят инициализацию, но на реальной машине там практически ничего не будет работать
HighMan, я не знаю что там у автора, скорее всего ему ради образовательных целей.
Но из моего опыта, переход с php (с ним сравним по скорости из интерпретируемых языков только javascript, с оговорками, да, если писать под .net или java виртуальные машины или к примеру go, то будет быстрее, но это языки уровня c++) дал ускорение в обработке текстовых json в 10 раз, а так как текстовых данных в упакованном виде у меня порядка 6 терабайт, ускорение считаю значимым, притом что писать в низкоуровневом стиле не пришлось.
На многих блокчейнах, где используется usdt (наверное все кроме bitcoin omni layer) не получится по простому оплатить комиссию для перевода с этого адреса с другого адреса, т.е. сначала придется как то сделать перевод нужной суммы (или передать 'энергию' как в eos/tron/...) и только потом совершить перевод...
Поэтому разбивать переводы по адресам не имеет никакого смысла, ведь в попытке сэкономить в последствии на затратах на комиссии, адреса эти свяжутся с базовым сервисом.
Обычно адреса привязывают к пользователю, так же можно ограничить использование адреса пользователем каким то лимитом времени, чтобы исключить мертвые души
А на сколько длинные эти строки, сколько строк максимум пропускает бесплатный гугл транслейт?
если что бесплатные переводчики 'очень не очень', поэтому тут либо оплати api (яндексу или гуглу, на выбор, цены там вроде норм, у яндекса от $15 за миллион символов) либо ковыряйся и обходи бесплатные лимиты.
У тебя вопрос получается как автоматизировать процесс да еще и бесплатно?
p.s. у тебя вариант только скачать с торентов какой-нибудь условный 'промпт' и скорми документ ему
я серьезно