Юрий

романтизируете сильно.

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

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

нет

для получения любого цвета достаточно иметь 3 цвета RGB.
поэтому
#617730 = #610000 + #007700 + #000030

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

например старожилы на форумах. или безопасная сделка на биржах.

www.liveinternet.ru/stat/sramo.ru/sum.html

делал тупо на ноде такое.
все *.RU домены (5,5 млн) за несколько суток.

по поводу картинок это действует только для примитивных форматов типа bmp. там реально чтобы получить N пикселей достаточно прочитать 3*N байт. все остальные форматы графики (за редким исключением) сжимают изображение, очень часто даже с потерями (особенно jpeg).

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

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

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

сначала прочтите мой ответ отсюда Что почитать об архитектуре CMS?

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

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

из русских создателей коробочных цмс знаю https://phpixie.com/ можете попробовать с его создателем сконнектится, но в коробочных цмс потребности немного другого порядка.

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

если что - спрашивайте, и конечно же удачи!

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

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

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

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

в файле composer.json надо автолоад прописать.

"autoload": {
        "psr-0": {
            "App": "src/"
        }
    },

и обновить
composer update
все классы в неймспейсе App будут загружаться из папки src.

реально ли вам нужна именно многопоточность?

в большинстве случаев хватает решений на основе event loop например могу порекомендовать reactphp.org работает без доп расширений, реализует асинхронное IO, чего в большинстве случаев достаточно. в других случаях проще запустить несколько отдельных процессов, например вот этим https://symfony.com/doc/current/components/process.html

когда то давным давно тоже делал библиотеку для псевдопотоков.
controll.run(); должен быть в loop.
вы же понимаете что никакой многопоточности в ардуино быть не может. controll.run в каждой итерации loop проверяет все подключенные обработчики/thread и если пришло их время запускает эти функции. никакого волшебства, ровно как и никаких реальных потоков.

если вы не вызываете controll.run в loop то эти обработчики никогда не будут запущены.

также учтите что код в обработчиках не выполняется параллельно!!!
то есть если 2 функции(thread) которые там добавлены выполняются каждая по 1 секунде (например они содержат sleep внутри себя) то они будут выполнены ровно по очереди и вместе будут выполняться 2 секунды, а не 1 секунду как было бы при честной многопоточности.

либо еще вариант делать их запуск по условию

initTime = millis() + 5000;

loop() {
   if (millis() < initTime) {
      controll.run(); 
  }
}

controll.run будет запускаться только первые 5 сек. если вы не хотите получить лишние накладные расходы при обычной работе после запуска.

UPD: читайте как работают EventLoop в любых языках программирования и библиотеках.

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

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

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