rPman

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

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

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

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

Если вам нужна скорость, то уходите от постоянного переподключения к сервисам.

Конечно, современные веб-сервера и браузер умеют переиспользовать подключение для http rest, но это стоит перепроверить в вашем случае. Если идут постоянные переподключения то высокие пинги могут превратить работу вашего сервиса в лагучую дрянь (один https добавит пару туда-сюда отправлений).

websocket изначально по определению однократно открывает подключение а затем использование открытого канала возможно в обе стороны (с http rest только в одну и с оговорками в сторону клиента, читай не эффективно).

А еще вопрос, как у вас организован код обработки http rest. Если это старый классический подход, когда на каждый запрос запускается php скрипт это это еще и высоченная нагрузка на сервер, переделывайте (а точнее убирайте эту фигню и оставьте websocket), так как разница подходов дает ускорение на пару тройку порядков (это не шутка и не преувеличение).

у http rest только одно достоинство - почти бесплатная горизонтальная масштабируемость на сервере.

Если windows то вы можете даже на том же javascript написать приложение (.net) с формочками и кнопочками, скомпилировать штатным компилятором, который идет с операционной системой (точнее это .net framework но он у всех 100% есть так как его таскают с собой даже драйвера)

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\jsc.exe - это компилятор
Почитайте пример https://www.phpied.com/make-your-javascript-a-wind... (почти первая же ссылка из гугла).
Недостаток, по умолчанию пути не прописаны и они зависят от версии установленного framework, информации о котором нет в переменных окружения и вытаскивать их либо поиском либо анализом реестра (майкрософт не умеет делать правильные и удобные окружения, никак, никогда)

К сожалению красиво примеров именно для javascript не найти но если воспользоваться visual studio и посмотреть примеры javascript windows form то можно написать что угодно.

Итоговый exe получится несколько килобайт, и при этом почти кроссплатформенный (с помощью mono можно запустить на linux)

Если железо одинаковое а игры работают по разному - смотрите, а установили вы ли все необходимые драйвера?

Для изучения WEB вам нужно начинать с HTML.

Затем изучение разделяется на минимум три направления - бакэнд (то что крутится на сервере), фронтэнд (то что работает у клиента в браузере) и верстка (изучение HTML и CSS чтобы страница в браузере, причем на всех, включая мобильные и десктопные разных ОС, выглядела как хочется а не как получится). Бакэнд и фронтэнд фактически преследуют одну цель - формировать HTML (в т.ч. динамически изменяемый от действий пользователя).

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

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

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

Julija Perfilova, Intel Neural Compute Stick это не компьютер общего назначения а сопроцессор, для ускорения вычислений нейронных сетей (причем когда я про такие читал, так и не понял зачем это покупать, если можно собрать на itx платформе на штатных комплектующих железо БОЛЬШЕЙ мощности.. да, возможно это компактнее, но смысла заморачиваться за такие копеечные мощности я не вижу), вам не подойдет никак.

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

Готовых реализаций МОЩНЫХ компьютеров в формате usb stick НЕТ. В формате книжка - есть средней мощности готовые и вы можете самостоятельно собрать (или заказать сборку),.. в формате небольшой чемоданчик (вес несколько килограмм) можно собрать очень мощное железо. Смотрите на itx или microatx формфакторы материнских плат.

С некоторыми оговорками, можно попытаться собрать компактное железо на базе топовых смартфонов, если победить штатную систему контроля температуры и дообавить свое кустарное охлаждение. Но будет проблема с софтом, так как android или тем более macos платформы плохо поддаются установке десктопных OS.

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

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

Альтернатива - таскать алюминевый радиатор, чтобы оценить вес - берите обычные батареи центрального отопления, 1 секция ~ 100 ват отводимого тепла, вам надо порядка 400-500ват без видеокарты и до киловата, с ней.

p.p.s. только сейчас задался вопросом, а зачем вам МОЩНЫЙ компьютер для видеомонтажа?

Если на аккаунте были покупки (например google play или подписки youtube) с вашей банковской карты с фио то шансы есть, пишите в поддержку.

Иначе никак

Нейронные сети - это просто алгоритмы, самая ресурсоемкая часть в процессе но не самая главная.

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

Вторая проблема нейронных сетей - они не дешевые, точнее собственно процесс обучения, для интересных а не простых академических задач типа 2+2=4, требует вычислительные ресурсы, причем много от слова много денег.

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

Может лучше использовать кеш браузера? Это логично и всяко удобнее чем ханить такие данные в отдельном хранилище, следить за их форматом и т.п.

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

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

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

На странице форма с поиском отправляет запрос (на выбор http rest get или post либо лучше используя websocket, почему - ниже) на сервер.

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

Если пришло сообщение, клиент его выводит.
---

Для работы websocket на сервере нужна его поддержка, обычно отдельный бакэнд выступающй в виде websocket сервера и обрабатывающий запросы. Есть плагины к веб-серверам, конвертирующие это в привычный http rest стиль, но это изврат.

Когда то давно, когда websocket не был стандартом, самым простым способом слушать события с сервера был запрос на сервер и ответ в виде javascript с вызовом функции, которая собственно и есть событие (т.е. запрос на страницу подключался простым тегом < script >), сервер ничего не отправляет в канал запроса (или просто пробел по 1 в минуту чтобы по таймауту не закрылся) пока не появится необходимость. Правда клиент должен отслеживать ошибки что бы повторять запрос.

Звалось это long poolling

Внутри виртуалок нет особой необходимости создавать LVM, в 99% ситуаций возможностей снапшотов виртуальной машины хватает за глаза.

По поводу увеличения места, практически все VM поддерживают динамически расширяемые контейнеры, т.е. файл с контейнером будет занимать ровно столько места, сколько реально используется (обратно не уменьшается, только увеличение), соответственно создавайте виртуальную машину с терабайтовым диском, а внутри контролируйте лимитами или заранее созданной маленькой файловой системой, простейший ext3 умеет на лету увеличивать размер, заполняя больше места (только место с конца тома).

Мое ИМХО, если цель сэкономить (т.е. для маленьких организаций на 5 человек все плюшки домен контроллера и собственно сервера windows не обязательны и даже избыточны), причем МНОГО, то вместо терминального сервера соорудите машину с десктопной ОС (т.е. буквально windows 7/8/10) и подсистемой от ibik aster, когда к одной машине физически подключаются несколько клавиатур, мышек и мониторов (можно найти видеокарты с подключением до 6 мониторов, переходниками или подбирать по типу коннектора заранее либо несколько видеокарт, хоть через рейзеры) и работают независимо напрямую, без медленного сетевого терминала.

Мониторы можно выносить на заметно большое расстояние (10-20 метров почти без проблем), с USB сложнее, после 5 метров начинаются проблемы (например с флешками - но так ли это нужно, понадобится - человек встанет и подойдет к машине), клавиатуры можно заранее планировать беспроводные - добавят еще 5-10 метров.

В крайнем случае тут же можно настроить каждую консоль через VNC/anydesk/teamviewer по вкусу и предпочтениям.

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

Скорее всего это сугубо индивидуально под конкретное железо и драйвера, установленные в системе.

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

Если нет.
В браузере то у вас все работает? Подключайтесь к скайпу используя web.skype.com

p.s. использовать windows серверную систему как рабочее место напрямую уже давно не подразумевается, в других местах тоже будут мега глюки, да те же драйвера к видеокарте

Если ваш проект - веб-приложение, то браузеры предоставляют все необходимые технологии для этого - например на базе webrtc есть куча opensource приложений. Посмотрите talky.io например.

На самом деле прямые соединения клиент-клиент не всегда возможны, особенно в России, когда провайдеры ломают интернет по приказу идиотов с выше, и не только.. а значит промежуточный сервер вам так или иначе понадобится. Читайте про webrtc, stun сервера и прочее.

Если приложение не веб, то у вас появляется больше способов, например обеспечение подключения на основе своих wifi точек доступа (практически все современные смартфоны и планшетники могут работать точкой доступа) или даже bluetooth/nfc (слабоваты для видео но могут использоваться для собственно организации соединения чтобы договориться кто к кому подключается).

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