rPman

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

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

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

p.s. сеть у малинки только через usb которое не шустрое, вас устроит в лучшем случае 20мбит?

C вероятностью 99.(9)% ваш .m3u8 это набор статический файлов-кусочков видео (откройте этот файл в текстовом редакторе это простой плейлист текстовый), загрузите их на свой сервер разом и создайте свой .m3u8 со своим url.

Если же содержимое стрима динамическое то уже сложнее. гуглить m3u8 stream proxy, есть опенсорс мини проекты для этого.

Такое можно сделать только индексом unique. При добавлении неуникальной записи будет выдавать ошибку.

Иначе вам придется вручную делать то же самое что он, гораздо менее эффективно по скорости и затратам ресурсов.

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

Судя по всему вы очень узкий специалист,.. если вариант с нанять знающего не катит, копайте сами.
Настоятельно советую выкинуть на помойку ms access и больше не вспоминайте это, когда то эта среда была одним из лидеров, но сейчас безнадежно устарела. В принципе можно использовать само хранилище mdb по назначению, без UI, но сейчас есть более удобный и быстрый инструмент sqlite

Общепринятые практики, которые можно использовать в вашем случае:
* 'разделяйте и властвуйте'
Отделите хранение данных от интерфейса работы с ней, это решит много проблем, уменьшит возможное количество ошибок и облегчит поддержку системы, так как для нее вам не потребуется на столько узкий специалист.

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

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

* задайтесь вопросом что есть надежность и безопасность, эти понятия очень много в себя включают

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

У вас два пути для решения этой проблемы
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