Василий Банников

Любую: построение сети небольшой компании, производства, завода, жилого дома, бизнес-центра, магазина, деревни/СНТ, да хоть круизного лайнера - чего бы и нет-то?

Тут все ответы одновременно верные, не верные и противоречащие самой задаче.

1. "Ничего не изменилось" противоречит концепции самой задачи: по условиям задачи уже что-то изменилось. Ничего не изменилось в дизайне странице. Изменился объём страницы и увеличилось потребление трафика, а так же объём вычислительных ресурсов необходимых для обработки данной страницы.
   
2. Расходы снизились, т.к. после пересборки и деплоя проекта запустился механизм очистки кэша предыдущей версии проекта и которая занимала больший объём, чем текущая. Расходы увеличились, потому что объём проекта увеличился.
   
3. Скорость - аналогично: проект пересобрался чуток по-другому из-за других хэшей в названиях файлов, которые архиватор пережал чуть более эффективно. Или сжатие страниц не использовалась и скорость отображения страниц замедлилась.
   
4. Износ НЖМД относится к пункту 2, т.к. это часть расходов на обслуживание сервера.
   
5. Электропитание - то же самое: больше байт для обработки - больше затраты на электричество, архиватор сжал эффективнее - меньше байт, меньше затраты.
   
6. Так же и с уязвимостью: дополнительные 43 байта привели к возможности использовать атаку при переполнении буфера в такой странице памяти (ну, условно, конечно). Или наоборот избавили.
   
7. По любому пункту выше (и даже ниже) можно получить как взыскание, так и премию.
   
8. То же самое с выбросами: пользователи получили замедление страницы и со злости очень активно и экспрессивно высказались в адрес владельцев и разработчиков сайта, что привело к более активному дыханию и дополнительным выбросам. Ну или наоборот - пользователи уснули в ожидании загрузки страницы и меньше надышали.
   

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

Василий Банников да ну
это же из windows 95 фунциональность вот:

$shell = New-Object -com shell.application
$rb = $shell.Namespace(10)

проще всего если там уже есть хотя бы 1 файл:

($rb.items() | select-object -first 1).Path
C:\$Recycle.Bin\S-1-5-21-3826591462-1902725790-3394240593-1001\$RXMK2R1

если нет ничего надо что то еще искать как но мне лично чуть некогда

new-item "a.txt"
 $rb.CopyHere("a.txt", 0)

($rb.items()).count
2

new-item "a2.txt"
$rb.CopyHere("a2.txt", 0)
($rb.items()).count

3
если понравилось - решением

На самом деле время пинга складывается из нескольких составляющих. Основные две из них:

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

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

Что самое противное, ни одну из этих составляющих нельзя измерить надёжно. А тебя по большому счёту, интересует только первая из названных составляющих. Даже на время реакции целевого, конечного, узла можно начхать - на TCP/UDP он будет реагировать гораздо шустрее, чем на пинг, а если будет тормозить, то отвечающий софт, а не передача.

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

есть такая штука - typeguard. он сообщает ts'у, что этот объект определенного типа, который указан после is. вот простенький, дальше разберешься, думаю.

function isData(data: any): data is { id: number | string } {
  return data.id !== undefined
}

1) TDP в 2.5W совсем не означает, что он реально жрет 2.5 W, максимальное потребление в стресс тесте может и 12 W быть
2) стекло, блин, прозрачное, вы покрасьте лампочку черной краской, сразу получите схожесть

Это классическая путаница между маркером доступа (Access Token) и маркером идентификации (ID Token), которые являются основой протокола OpenID Connect, используемого в ЕСИА.
"urn:esia:sbj:oid (из ID Token)" - это постоянный и уникальный OID пользователя. Он предназначен для идентификации. А "urn:esia:sbj_id (из Access Token)" - это временный идентификатор сессии. Полагаться на него некорректно, даже если где-то это случайно работает.
Ваш алгоритм должен быть таким:

1. В процессе авторизации запросить и получить от ЕСИА и access_token, и id_token.
   
2. Распарсить id_token (это стандартный JWT).
   
3. Извлечь из него значение поля urn:esia:sbj:oid. Это и будет искомый {oid}.
   
4. Сформировать URL запроса, подставив туда полученный oid.
   
5. Выполнить GET запрос по этому URL, передав access_token в заголовке Authorization: Bearer ... для авторизации на сервере.