pfg21

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

Теоретически, да и практически - делаете образ squashfs, делаете маленький образ initrd.
Загружаетесь с initrd в котором делаете remount рута на образ squashfs.

Почитать можно например здесь - https://magazine.odroid.com/article/using-squashfs...

Когда в корпоративном ЦОДе, где я был руководителем группы сисадминов, возникла такая ситуация, то уважаемый самый старший по возрасту сотрудник предложил простой способ, который в последствии был назван по его имени "методом Фаюршина".
Научно он звучит так:
"Если имеется канал передачи информации, подключенный с одной стороны к известному источнику информации и к неизвестному приемнику информации, с другой стороны, то временное прерывание канала передачи данных позволит идентифицировать неизвестную сторону, так как она обязательно найдет другой канал передачи данных субъекту, временно прервавшему канал связи, и сообщит ему о необходимости восстановления прерванного канала. Причем, чем важнее сторона, которую необходимо идентифицировать, тем быстрее произойдет обратная связь и мощнее сигнал".
Ну а по простому - выдергиваем кабель, ждем возмущений.
Не является рекомендацией, но полезно для изучения :-)

При такой постановке вопроса, очевидно, воткнуть в сервак ещё одну сетевуху, а в неё шнурок второй сети.

Вообще-то компьютерные сети представляют из себя стек протоколов модели ISO OSI, состоящий из разных уровней. Физический -> канальный -> сетевой -> сеансовый -> приложений -> представления. Вроде особо не напутал.
Что имеется ввиду под "физикой", физический уровень? Самый нижний? Так у Олифера нормально все объяснено. Проводные, беспроводные каналы передачи данных. Уровни, кодирование сигналов. Понятно и всеобъемлюще. Не зря стоит у книги гриф "рекомендовано МО РФ".
Кому и когда, реально, по факту, придется работать с физическим уровнем? Единожды, при прокладке Ethernet-кабеля (витой пары Cat UTP-5) - при построении проводной ЛВС (компзал, своя локалка, какая-то фирма и т. п.). Или устанавливать Wi-Fi точку доступа - в случае беспроводной ЛВС. Сейчас еще, интернет ребята приходят проводить. Кабеля тянут. Но там больше нужны строительные навыки (перфоратор и т. п.). Хотя уже полно где все подключено: по пять провайдеров на дом. Кроме новостроек - естетственно. Тут из новинок - оптика (оптоволокно) - своя, отдельная история.
Сами мы, как страна, ничего здесь своего не имеем и не разрабатываем. Увы. Чисто на аппаратном уровне - имеется ввиду. Так что сидеть с осциллографом и изучать сигналы на витой паре с целью их оптимизации и "допиливания" - что-то из области фантастики. Я про работу радиоинженеров.
Сдается мне, что как админы, так и безопасники, в основном, работают с вышележащими уровнями модели OSI. Там, где реально ковырять железки не требуется. Когда, так сказать, этот "фундамент" готов. Настраиваются параметры, все уже чисто за клавиатурой, программно. Глубоко куда-то лезть не надо. Все достаточно понятно. Знаний уровня "академик" не требуется. Так же как и знать наизусть 600 страниц талмуда по TCP/IP от разработчиков этих протоколов. Обычные специалисты знают это поверхностно, только ровно то, что нужно, достаточно для выполнения своих обязанностей, решения поставленной задачи. Не спорю, какие-нибудь гипотетические взломщики, пытаясь найти уязвимости в протоколах, не ленятся штудировать и такое. Все возможно.
В учебных заведениях упор идет на вышележащие уровни: сетевой, сеансовый, представления (приложений). Там присутствуют такие протоколы как: TCP/IP, UDP, FTP, HTTP - самые основные. Сами по себе они мудреные. Но просто почитать, в общем виде (та же википедия) - не помешало бы. Познакомиться, так сказать.
Выше приведены примеры сетей малого масштаба. MAN и LAN. Еще бывают: внутренние сети интернет-провайдеров и корпоративные системы и сети разных компаний. У них своя "кухня". Ну а Интернет - сеть сетей (WAN). Объединение сетей, так сказать. С присутствием некоторых магистральных, трансконтинентальных каналов связи. Проложенных по дну океана между континентами - например. И используемыми совместно разными организациями, странами. У нас, к примеру, магистральный канал связи есть у магистрального оператора связи Ростелекома. Другие провайдеры - организации поменьше масштабом.

Если я где-то приврал, то извиняюсь, старался не особо сочинять. :)
Вот, собственно, и все. Для начала.

Начните с этого: https://ru.wikipedia.org/wiki/Триггер
В качестве первого приближения ваш счётчик можно собрать из двоичного счётчика и двоичного дешифратора - будет работать. https://ru.wikipedia.org/wiki/Счётчик_(электроника)
https://ru.wikipedia.org/wiki/Дешифратор
Нормальная реализация (без оверхеда) должна получиться, IMHO, просто на базе триггеров.

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

Окей, если объяснить на пальцах, то есть два варианта.
1. Собственные знания модели. Большие языковые модели, по сути, умеют только одно: предсказывать следующее слово по набору предыдущих. Почти все остальные задачи сводятся к этому. Так что веса модели - это описание офигительно сложной функции, которая описывает взаимосвязь между предшествующим набором слов и последующим словом. Все "знания" модели, таким образом, сводятся к ответу на вопрос "какое слово будет дальше с наибольшей вероятностью?" Отсюда вытекают и слабые стороны языковых моделей - они не понимают, что пишут, они просто пишут "по аналогии".
2. Retrieval Augmented Generation. Грубо говоря, в распоряжении модели есть база текстов, где каждому фрагменту сопоставлено некоторое описание его смысла. Модель использует такое же представление смысла слов в запросе, чтобы найти подходящие по смыслу фрагменты. Найдя эти фрагменты, модель строит ответ уже на основании фрагментов И запроса. Это не требует переобучения модели для добавления новых знаний, как в первом случае. Но будут проблемы, если фрагменты слишком длинные или их слишком много.

Для того, чтобы просканить интернет, нужно для начала иметь список интернет-сайтов и страниц на них. Это уже огромный объём информации, которую поисковики накапливали годами и поддерживают в актуальном состоянии.

Но даже если такой список есть - по нему ещё надо пройтись. Потратив уйму времени на скачивания этих миллиардов страниц. И возможно в итоге получить 0 результатов. А на следующий запрос начинать скачивать всё то же самое заново повторно.

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

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

Google - это прежде всего инфраструктура, а не софт. Как только сможете позволить себе потратить десятки миллиардов долларов на постройку ЦОДов, можно и персональный Google будет завести.

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

Идет мужик по рынку. Смотрит - яйца продают. У одной бабушки яйца по 300р штука, а у всех остальных - по 10р штука. Он не выдержал, подходит к бабушке, что по 300р продает:
- Бабушка, а у тебя куры какие то особые?
- Нет милок, самые обычные.
- А ты их кормишь как то круто?
- Да нет, как и все...
- Может это яйца какие то особенные?
- Да нет, милок, самые обычные...
- так чего ж так дорого?
- так деньги нужны, милок.

В случае HP - ты еще платишь за имя....

Есть устоявшаяся практика: присваивать номер vlan номеру подсети

Вот честно - слышал, но никогда не мог понять. Как по мне - хрень голимая. Качественное документирование куда как полезнее.

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

понятно ограничение на количество vlan на разном оборудовании

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

Сам учусь по такому направлению
Подробно изучить Python.
SQL основы - желательно потратить недельку - две на изучение(Но в Джанго своя ОРМ, но я считаю что пригодится знать основы)
MySQL/PostgreSQL
Django.
Django Rest FrameWork(Для создания RESTful приложений).
Nginx/Apache
Для фронтенда учу
HTML
CSS
Bootstrap/Tailwind CSS
SASS/SCSS
JavaScipt(Основы)
Какой-то фреймворк для фронта например React/Vue/Angular
Обязательно научиться пользоваться Git.
И ещё было бы хорошо научиться пользоваться Docker.
В целом пока занимаюсь этим.Если что-то не правильно, пожалуйста поправьте, самому будет полезно почитать

JavaScript на Java уже писали много раз. Поищи по ключевым словам Rhino, MVEL.

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