rPman

в России в последние годы провайдеры активно вмешиваются в трафик пользователя, т.е. не только кривой самодельный DPI но и спам через подмену html (вставка javascript), так что не удивлюсь что все крутые технологии на канальном уровне и выше будут сломаны на самом последнем шаге.

Для начала ответьте на вопрос, хватит ли вам не попиксельного сворачивания а абзацами или словами? например простым скриптом на javascript вы можете рекурсивно пройтись по всем элементам на странице и узнать их координаты (прямоугольник), затем меняете всем позиционирование на абсолютное, по таймеру, меняя эти координаты и размеры.

Если элементы слишком большие, то тут придется проявить смекалку, что делать с картинками, что делать с пустыми блоками, через которые была сделана верстка и т.п. С текстом просто, его можно заменить на серию span по предложениям или словам, а уже эта конструкция разлетится по вашему алгоритму по спирали.

google forms? с интерфейсом, который вы зададите, данные будут только добавляться но не могут быть изменены пользователями

Не надо вам тут нейронные сети и обучение, это как ходить в соседний магазин за хлебом, на вертолете, садясь на него в соседнем городе.

Часы это набор прямых и окружностей, с помощью opencv ищите их (т.е. векторизуйте изображение) затем выбирайте только те отрезки, которые похожи на часы (окружность риски часов, часовая и минутные стрелки, опционально цифры), таким образом вы поймете какие из линий - стрелки, а дальше либо через цифры, либо через ориентацию телефона (если цифр нет) определяйте где верх а где низ.

Не выдавать разным людям один логин и уже на уровне пользователей разруливать (отключать доступ) когда вам необходимо. Эти пользователи даже могут не иметь администраторского доступа, но сразу после логина можно каскадно запускать сессию уже под администратором.

Т.е. user_1 авторизуется, в шедулере стоит скрипт отключения user_2 при логине, и включении при выходе, после входа сразу открывается сессия к пользователю Администратор (или консоли, которой только один пользователь в момент времени может пользоваться), если настроите права, переключение консоли возможно прямо в таскменеджере (закладка - пользователи, правая кнопка - развернуть).

возможно разработчики криптоматор умудрились неправильно работать файлами и глючат с нестандартными символами в именах, например ':'? протестируйте, убрав такие файлы.

https://developers.google.com/docs/api/
вы можете кучу всего прямо из платформы, создав скрипты

Посмотрите уже замороженный проект simplewebrtc (его рекламирует talky.io, простой удобный, полагаю он на нем основан).

Чем вас не устраивают существующие решения? ваша задача озвучена очень простой - чат и сохранение логов. Максимум все ваши проблемы - это решение проблем webrtc, создаваемые провайдерами (чаще мобильными) stun сервера и прочее.

смотрите что вернул GetLastError()
https://docs.microsoft.com/en-us/windows/desktop/d...

Мой небольшой опыт говорит, не выбирайте БОЛЬШОЙ монитор, все равно весь софт рассчитан что на 1080 и 24" (если не 2k или 4k то все по любому масштабируется до 1080). Но если у вас будет НЕСКОЛЬКО мониторов, то ваша жизнь станет на порядок лучше. Это жутко удобно когда приложение и среда разработки во время отладки запускаются на разных мониторах, а если рядом на третьем еще и документация развернута и у вас настроены удобные хоткеи для переключения,.. поверьте, это гораздо удобнее и бюджетнее.

Берите 3 обычных 24" 1080 монитора (можете один взять побольше, 2к или даже 4к, но за последствия пеняйте на себя), и единственные параметры, на которые вы должны смотреть - это матовый экран и не самые ужасные углы обзора (чтобы легким движением изображение не инвертировалось, сидел за таким разок), плюс есть возможность такой монитор безболезненно повернуть на 90 градусов, удобно!

Оба направления верные,.. смешно.

Первое, если ваш проект большой или будет большим, чтобы с ним работало несколько человек, плюс это следование главному принципу - разделяй и властвуй, то максимально разделяйте бакэнд и фронтэнд, через определенную и стандартизированную api прослойку. Весь смысл - сделать разработку этих частей проекта максимально независимыми. Вас не должно волновать, на каком языке сделан бакэнд, какой фреймворк или стандарт использован, где лежат файлы и как они называются и т.п., главное - следование стандарту api их взаимодействия. Т.е. размещайте файлы в отдельных каталогах.
Главный недостаток - удобно такое делать, когда проект уже готов и в нем появляются только редкие допиливания, т.е. стандарт api уже завершен и серьезно (в структурном плане а не конечные его функциональные листья) изменяться уже не будет.
Главное достоинство - вы можете переписывать свой проект (например как один из способов избавиться от технического долга) независимо, т.е отдельно бакэнд, отдельно фронтэнд и в идеале отдельно верстка.

Второе, если ваш проект никогда не выйдет за стадию начинающего, если вам проще плодить технический долг но экономить троекратно на времени разработки, если вы один все делаете и больше никого в проект не ждете, размещайте все рядом, или даже попарно в одном файле, благо php это позволяет (плохая кстати практика, правда если у вас есть промежуточная прослойка, собирающая проект из ваших файлов в эффективный комок статики и кода, то оправдана) - то делайте так. Структурно, это очень удобно работать с логически связными файлами вместе, сразу видно где что не доделано, удобно в интерфейсе в один клик переходить мед уровнями разработки и т.п.

php однопоточный, а достпуные многопоточные сборки - это чтобы плагины работали синхронно, если это им зачем то понадобится.

Соответственно единственный способ запускать что то параллельно и независимо - это запускать php отдельным сервисом и как то с ним из вашего приложения сообщаться (сокеты, пайпы, или любой другой межпроцессорный способ взаимодействия).

Если вам прямо смерть как надо, переписывайте на асинхронную работу свои методы, тогда у вас вообще такой проблемы не возникнет. phpreact смотрите.

Информации мало, но проверьте внимательнее, возможно между запросом и ответом от базы данных стоит еще какой то код, может в нем ошибка?

Я бы добавил отладочную информацию прямо в код где идет ответ от базы данных по условию используемого sql, и пишите в лог дату, параметры запроса и количество записей в результате. По результатам сможете хотя бы гарантировать что это база данных глючит.

Проверьте сетевое соединение до базы данных, особенно если она находится на другом сервере, правда в этом случае у вас должна приходить ошибка, но очень часто бывает программисты ленятся проверять все случаи (типа если предыдущий вызов без ошибок то зачем проверять следующий).

Запустите утилиты проверки целостности базы данных и файловой системы. Банально проверьте работоспособность железа, вдруг у вас оперативная память глючит (правда у вас вылезало бы еще много где косяков) или сбоит контроллер жесткого диска (смотрите логи сервера dmesg хотя бы).

для windows я еще пойму, но зачем ssd кеширование покупать для linux? есть какие то объективные причины и тесты, показывающие что те же bcache/dm-cache/enhanceIO/flashcache хуже? А ведь есть кеширование встроенное в zfs, котрое хоть и не родное для linux но уже работает очень даже ничего

Проведя несколько простых экспериментов, попробуйте определить, как именно браузер сортирует расширения. Это может быть порядок установки, по дате обновления или имени, или идентификатору или еще по какому признаку. Выяснив это вы легко сможете создать расширение, которое с большой вероятностью будет первым (а в вашем контролируемом окружении - с гарантией).

Как только начиналась активность (работа в браузере) доступ к интернету прекращался где-то через 3-5с после чего тоннель падал. С других провайдеров (подключение по кабелю) то же самое, либо вообще не поднимался. Но сегодня попробовал подключиться с мобильного интернета (МТС) и тонель поднялся и работает стабильно

Отправляйте лучи поноса вашим проводным провайдерам, это они.

Если речь о России, это прямое следствие попыток взять под контроль интернет, кривыми руками ломают стандарты, блокируют протоколы и подсети, левой пяткой вмешиваются в содержимое пакетов. Такова наша реальность, изменить которую в лучшем случае можно попытаться только через революцию, что тоже скорее всего не поможет, но боюсь иные способы вылечить больного не сущствуют (они успешно заблокированы и взяты под контроль).

Попробуйте поругаться с проводными провайдерами, сначала просто добравшись до их админа с логами и подробным описанием того что делали, что ожидали и что получили. Возможно они пофиксят баг в самодельном DPI и у вас все заработает.

Мало того, МТС работает скорее всего только потому что каждый провайдер изобретает свой особый путь, и глючит он у каждого по разному. И да, ничто не гарантирует что завтра на МТС VPN тоже не перестанет работать.