Adamos

Насколько будет все стабильно через Wi-fi?

Стабильность и WiFi вещь не совместимая.
Нужна стабильность -только провода.

Ну и скорость низкая.
FullHD может потянет - но если повезет, не повезет, значит не потянет. В любом случае зависит не от вас, а от соседей.
А скажем с файловой шарой работать вообще невозможно - качать файл со своей шары будете в лучшем случае со скоростью 4-5Мб/с, ну это несерьезно.

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

Сам класс в .h, а его описание в .cpp.

Чтобы тебя правильно понимали, сперва нужно понять общую терминологию, а далее - этой терминологией нужно корректно пользоваться.
У нас есть два строгих термина: Declaration (объявление) и Definition (определение).
Замечу одну важную вещь - для определения характерно ODR (правило однократного определения), но пока на это можно не отвлекаться, потом надо будет.

А потом к основному main.cpp подключаю просто файл .h

А для чего ты это делаешь? Какую цель ты преследуешь, когда сперва объявляешь свой тип в отдельном файле, а потом говоришь препроцессору включить этот файл в тело исходного кода?
Один раз я уже отвечал на подобный вопрос, повторю только место, где начинается важная сейчас информация: "С точки зрения компилятора есть только один формат файла - формат исходного кода, который ему и надо обработать".

Компилятору известно только понятие Translation Unit. Он ничего не понимает во всех этих .h/.inl/.inc/.c/.cpp/...
Для правильной сборки кода ты должен рассказать компилятору о том, как из всей понятной только тебе бурды собрать вожделенный для него модуль трансляции, в котором будет весь исчерпывающий код для завершения компиляции.

Тебе незачем лепить файлы только ради объявлений и определений. Все равно для компилятора это будет собрано в один файл. А такие системы сборки, как FastBuild или IncrediBuild и вовсе весть проект вгоняют в один файл и только потом кормят этим файлом компилятор.

Получается какой-то костыль.

И это ошибочный вывод. Вот теперь давай разбираться в ODR.
One Definition Rule гарантирует нам детерминизм любого используемого в коде типа, любой функции, любой переменной в рамках одной области видимости (но не в разных).
Это правило позволяет сказать, что свойства программы однозначно определены до процесса трансляции и не изменяются после него.

Любой мелкий проект ты всегда можешь написать в одном файле на 2 килостроки. Это не страшно.
Когда у тебя более-менее большой проект, один файл у тебя уже не получится.
Появляется необходимость заниматься архитектурой кода: выводить сущности, связывать их, получать зависимости. Помимо архитектуры кода, появляется необходимость наладить грамотное разделение кода на файлы. А файлы нужно грамотно компоновать вместе. Появляется необходимость в макроархитектуре проекта.
Тут на помощь и приходят устоявшиеся правила разделения кода по типам файлов.

В таких условиях очень важно соблюдать ODR и крайне важно понимать смысл таких ключевых слов, как static и inline.
А помимо ODR тут еще встает вопрос избыточной компиляции кода - когда ненужные объявления все равно включаются в исходный код и впустую тратят процессорное время на свою трансляцию. В этом случае становится важно не включать лишние объявления или ненужные определения в заголовочные файлы.

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

Многие ЦМС у себя реализуют паттерн MVC, но в усложненно-испорченных вариантах со своими особенностями.

Чтобы быстро разобраться что и как — нужно бы изучить ООП и MVC в частности, и с этим базовым знанием уже разобраться, как он реализован в том или ином движке — тогда разбор идет как по маслу.

Но если есть глобальная цель — изучить программирование, то стоит после изучения — изучать фреймворки

Чтобы быстро вникнуть надо нормально знать php.*
И тогда можно использовать что угодно.

* кроме битрикса, туда вникнуть нельзя никак даже теоретически, там полная каша.

советы по сетевому администрированию больших групп ПК

это AD или управление конфигурациями (chef, puppet, ansible)

все данные.

какие данные?
если нужна доступность - то это snmp, если логи какие то, то например syslog.

ПО которое будет стоять у меня в офисе

а это уже бэкэнд (но забирать то информацию нужно чем то, см. выше). тут тоже есть разные штуки для разных целей. для snmp - zabbix, prtg, nagios. для логов - siem'ы, splunk и аналоги

P.S: В гугле и сам поискать могу :)

но не поискали.

правильно заданный вопрос - половина ответа.

Также появилась проблема, похожая на печально известный баг #12309 - при передачи файлов на флешку начинает дичайше тормозить компьютер, курсор перемещается отрывисто, и т.п.
Вот, например, сегодня, совершив 3-4 попытки, файлы все таки удалились. Начал скидывать на флешку файл в 1.5 гига, начал тормозить компьютер, в итоге все скинулось.

Есть еще несколько странностей при передаче данных. Скидывая, к примеру, 5 файлов в 575 МБ, прогресс в статус-баре быстро доходит до 570 МБ, зависает на некоторое время, отвисает, затем опять быстро доходит до 1140 МБ (как будто, загрузив уже два файла), зависает, и т.д.

Это долбанутость системы ввода/вывода Linux. Когда программа пишет какие-либо данные на диск, на самом деле они пишутся в память, а непосредственная запись происходит при достижении этим буфером размера, заданного параметром sysctl vm.dirty_ratio, который задаётся в процентах от объёма доступной ( MemFree + Cached) оперативной памяти(на самом деле может быть раньше, но об этом ниже). На современных системах порой получается дохрена (в вашем случае ≈ 570 Мб) и в момент записи устройство начинает офигивать от внезапно свалившегося потока данных на запись ( сколько там скорость записи у вашей флешки? 15-30 Мб/с в лучшем случае? ), а вообще все процессы, использующие какой-либо диск, наглухо блокируются до освобождения буфера. Если таких процессов много, то все ядра процессора повисают в iowait и система начинает заметно лагать.

Чтобы как-то жить с этой фигнёй, надо настроить размеры буферов таким образом, чтобы процесс сброса не вызывал блокировку на длительное время. Например:
sysctl vm.dirty_bytes=10485760
sysctl vm.dirty_background_bytes=2621440

vm.dirty_bytes - аналогично vm.dirty_ratio, но в байтах, а не процентах от сферического коня в вакууме. Если задано vm.dirty_bytes, то vm.dirty_ratio обнуляется и не учитывается.

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

Это слишком низкие значения, но вашу проблему должны решить полностью. Поиграйте с циферками, чтобы подобрать значения, при которых данные не будут писаться слишком часто и система не будет подвисать при копировании на медленные устройства. Сохранить их между перезагрузками можно через /etc/sysctl.conf.

Затем, извлек и вставил обратно флешку, и она перестала читаться, ссылается на Input/Output error.

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

PS Указанные параметры достаточно подробно описаны в документации

PPS мог что-то напутать в деталях, так как время уже позднее, но параметры точно те.

SELECT * 
  FROM `table` AS `t1`
  JOIN `table` AS `t2` ON `t1`.`user_id` < `t2`.`user_id` 
    AND `t1`.`date_start` <= `t2`.`date_end` AND `t2`.`date_start` <= `t1`.`date_end`

Учить и понимать по-порядку:
1. Транзисторы и их применение - советский научно-познавательный фильм
Хороший обучающий ролик ещё времён СССР про работу транзисторов на русском: здесь
2. Двоичная система счисления
3. Битовые операции
4. Диодно-транзисторная логика

Наглядно:
Как-то так )


Это реализация реплики на Unity вот с этого механического (видео):

Я не думаю, что возможно тут в двух словах что-то написать. Если интересует тема подробно, то есть хорошая книга "Код: Тайный язык информатики" Charles Petzold. Почитайте её.