res2001

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

Для того чтоб глубже понять суть вопроса, можно погуглить про инкапсуляцию и SOLID (в вашем случае, принцип Open/closed).

machine dependent constants - это количество тактов на один цикл алгоритма и тактовая частота процессора.
Предположим, что линейный алгоритм O(n) работает на быстром компьютере и каждый цикл выполняется за 1 наносекунду, то есть общее время будет 1×n. Логарифмический алгоритм O(log n) работает на медленном компьютере и каждый его цикл занимает 100 наносекунд, общее время 100×log(n) Посмотрим, как будет меняться время алгоритма при изменении n.

n    | O(n) | O(log n)
1    |    1 |   100
10   |   10 |   200
100  |  100 |   300
1000 | 1000 |   400

То есть, в интервале от 100 до 1000 есть значение n, после которого логарифмический алгоритм работает быстрее даже на более медленном компьютере.
В общем случае значение n можно получить из равенства a×n = b×log(n)

Влан -- это всего лишь идентификатор в ethernet фрейме. Который может принимать значения от 1 до 4094. Вланы не бывают тегированными или не-тегированными, они по определению тегированные. Бывает тегированным или не-тегированным трафик. Тегированный -- это тот, в ethernet фреймах которого соответствующее поле реально содержит VID -- VLAN ID, т. е. номер влана. Не-тегированный -- соответственно, такой фрейм, где номера влана нет.

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

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

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

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

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

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

IP 192.168.1.1 пингуется из сети 192.168.0.1 -- это понятно, так как адрес принадлежит вашему маршрутизатору. Вы можете ему на интерфейс 8.8.8.8 повесить, и он тоже будет пинговаться, даже при отсутствии интернета -- если между роутером и компом связь есть.

Service tag ставить не надо -- это уже из области Q-in-Q, вложенных вланов (если на пальцах).

Vlan1 -- какой vlad ID имеет?

#include <termios.h>

// хранилище дефолтного состояния
static struct termios stored_termios;

// Отключить эхо-вывод и буферизацию ввода
void set_keypress (void)
{
    tcgetattr(0, & stored_termios);

    struct termios new_termios = stored_termios;
        new_termios.c_lflag &= ~(ECHO | ICANON);
        new_termios.c_cc[VMIN] = 1;  
        new_termios.c_cc[VTIME] = 0; 
 
    tcsetattr(0, TCSANOW, & new_termios);
}
 
// Восстановление дефолтного состояния
void reset_keypress (void) 
{
    tcsetattr(0, TCSANOW, & stored_termios);
}

Есть у меня один зомби-процесс

Где?

user 3954 0.0 0.0 105316 952 pts/0 S+ 05:57 0:00 grep -w Z

Здесь нет ни одного зомби.

А grep в списке процессов ожидаемо есть и по условию "встречается Z" он успешно находит самого себя.

Как распределяется скорость интернета между процессами?

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

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

Приоритеты процессов одинаковы.

Это вы в диспетчере задач посмотрели?
Приоритет процесса определяет сколько ему достанется процессорного времени и ничего более. На передачу по сети он никак не влияет.

и недавно узнал, что html шаблоны можно кодировать в base64 и хранить в бд MySQL

а теперь забудьте.

В здравом уме никто
- не кодирует хтмл в бейз64
- почти никто не хранит шаблоны в БД

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

Есть вычитание близких чисел? Какие-нибудь циклы вроде СЛАУ больших порядков и решения дифуров? Знакопеременные ряды? Если нет, можно писать, что вклад машинной арифметики в точность алгоритма незначителен.
А если есть, нужно исследовать, кто и как может многократно усилить ошибки округления.
Ради эксперимента можно также сравнить результаты во float и double.

Пример алгоритма, который аналитически устойчив, а вычислительно — нет: e^−x «в лоб» при достаточно больших x. Связан он с тем самым вычитанием близких чисел: промежуточные члены ряды могут быть достаточно большие, а в результате выходит 0,0…01.

UPD. Вот такую книжку нашёл: info.alnam.ru/book_clm.php?id=26

write((char*)&vec[0],vec.size()*sizeof(vec[0]));