Вы имеете в виду, организовать маршрутизацию по BGP не только на overlay, но и на underlay? Мы посчитали, что для сети из 7 пар лифов (на самом деле 8, т. к. присутствует ещё одна пара border leaves) это некоторый overkill.
Что до OSPF vs IS-IS — для сети такого размера это действительно значения не имеет, но у нас был не самый положительный опыт с OSPF в предыдущей нашей сети, и мы хотели попробовать что-то новое.

Оборудование, работающее полностью автономно, без связки с вендором (через патчи, обновления, лицензии, или просто напрямую), в XXI веке или не производится, или неконкурентоспособно. При формировании политик ИБ компании это обстоятельство надо учитывать.

Проект был инициирован около года назад, завершен в феврале. Тогда «последние события» даже на горизонте не просматривались. Подобные риски есть всегда, здесь мы «в одной лодке» с нашими заказчиками.

Такое впечатление, что в комментариях собрались опытные разработчики в возрасте 40+, у которых «в анамнезе» — десятки сделанных и десятки заваленных проектов. Им, конечно же, ещё на старте очевидно, как пойдёт проект, как его делать, какой код и каким образом писать, и т. п. Но такие звери давно занесены в красную книгу, и стоят дорого.
А для того чтобы сделать что-то силами вчерашних студентов, у которых жизненный опыт получен на лабораторных работах и во вконтактике, предложенные методы могут оказаться рабочими.

Вольно цитирую супругу, она ПМ в разработке: «Конечно, я сама никогда не определю, за сколько времени можно запрограммировать ту или иную фичу. Но я знаю всех своих разработчиков, и знаю, что от каждого ожидать. Паша оценивает срок относительно точно, а то, что оценил Юра, всегда нужно умножать на два».

Кажется, вы в одном шаге от изобретения велосипеда капчи. Кстати, гугловая её реализация (та самая, где «поставьте галочку, если вы не робот») ни разу не тривиальна.

Мышь удобна, если нужно позиционироваться по «визуальным» объектам (например, работу в графическом редакторе без неё представить вообще невозможно).
Если нужно позиционироваться по «абстрактным» объектам (идентификаторам, скобкам, обозначающим начало/конец блока, именам файлов) — удобнее «горячие клавиши» или даже текстовые поля ввода с подсказками.
С некоторых пор понял для себя, что при работе в той же Windows гораздо проще вызывать программы/открывать документы не блуждая по менюшкам/иконкам, а нажать кнопку с окошками (попадаем в поле Search programs and files) и ввести несколько букв интересующей нас сущности (имени программы или документа).
Аналог в Mac — Spotlight (Ctrl+Space), аналог в vim — просто слэш.

Интерфейс vim (вернее, его предшественника vi) спроектировали люди, набирающие текст на клавиатуре десятью пальцами, для других таких же.
И спроектировали достаточно удачно. Действительно, работая с vi/vim, можно не убирать руки из исходного положения, по минимуму использовать различные комбинации Ctrl/Alt, быстро перемещаться к нужному файлу/месту в файле (без всяких Home/End, скроллбаров, мыши) и т. п. Многим это всё достаточно важно.
Ну и ещё одна приятная особенность vim — он нормально относится к файлам большого размера. Для написания кода это не имеет значения, а для обработки каких-нибудь логов — очень даже. Поиск в файле в миллион строк занимает у vim на среднем компьютере не больше 1–2 секунд.

Вы затронули достаточно важную и сложную тему — что такое «работать больше»?
Больше часов пялиться в монитор? Нет.
Выдавать больше строк кода? Тоже нет (гуглим по словосочетанию «индусский код»)
Закрывать больше багов? Ближе, но тоже нет, далеко не все программисты занимаются техподдержкой.
Генерировать больше «единиц смысла» (идей, законченных алгоритмов, библиотек)? Наверное да, но мне не встречались компании, где это умеют адекватно измерять.
Опять упираемся в проблему контроля — не умеют компании адекватно измерять и контролировать эффективность сотрудников. Отсюда и страх отпустить их от глаз начальника.

Да-да, по ссылке текст древний, но актуальный и смешной. Тем не менее, не надо недооценивать а) менеджеров (плохой менеджер добавляет всем работы, а хороший — заботится о минимизации лишнего кодонаписания) и б) «митинги» (иногда надо всё же собраться и договориться, кто, что и как делает — при наличии хорошего менеджера способствует минимизации лишней деятельности).
Полагаю, что оптимальный режим для «просто программиста» (не тимлидера) — 3–4 дня в неделю дома, за написанием кода, а 1 день в неделю можно и в офисе — пообщаться с коллегами, обсудить результаты, спланировать следующее погружение в код.
Для работодателя это недёшево: нужно и рабочее место в офисе, и удалённый доступ, и хорошие ноутбуки сотрудникам. Но — так наиболее эффективно.

Между шагами 3 и 4 — если есть возможность, попросить коллег прочитать и высказать ценные замечания. Нет возможности привлечь коллег — выдать жене, детям, бабушке, кому угодно, главное, чтобы это были не вы сами, а сторонний человек. Ибо правильно в статье написано, «глаз замыливается».
Если читатель не разбирается в предмете — тем лучше. Если, прочитав текст, он поймёт хотя бы что-нибудь, это хороший текст.

Опять же, в администрении всё-таки чаще применяется Bourne Shell (при всей его дубовости это однозначное must know для эксплуатационщика).

Достоинство у него ровно одно — в любой юникс-подобной операционке он есть «из коробки». Никакой алгоритм, подразумевающий работу с данными, организованными более сложно, чем последовательность строк, на нём реализовать невозможно, просто нет соответствующих средств.

С моей точки зрения Python не имеет права на существование, как и Perl, и Ruby, и вообще любой интерпретируемый (и тем более командно-скриптовой)
язык, имеющий претензии на роль языка общего назначения.

А, собственно, почему? Даже спрошу иначе — а где, по вашему, проходит граница между компилируемым и интерпретируемым (Java какая?), а также командно-скриптовым и «не-скриптовым» языками (php какой)?

Тут ведь как — если у вас в руках молоток, любая проблема будет казаться гвоздём.
Автор явно написал — ему нужно было «одинаково под Windows и Mac OS X». И какие есть возможности под Windows? Баша «из коробки» там нет, PowerShell — это свой отдельный мир, можно ещё cygwin поставить (большой, тяжёлый, со своими проблемами). Python в данном случае не худший выбор.

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

Несколько минут тупил, пытаясь понять логику работы «всего в целом». Понял следующее:
1. Периодически запускаем скрипт, который скачивает фрагмент данных из Интернета.
2. Параллельно с п. 1 на этом же хосте запускаем tshark для определения количества ошибок/аномалий tcp.
3. Выводим эти данные на графики посредством Cacti.
Вижу один минус — сайт в п. 1 всякий раз один и тот же. Можно сделать несколько разных, но сути не меняет — нерепрезентативно.
Я бы, наверное, вместо скрипта из п. 1 оборудовал зеркальный порт для всего трафика нашей сети и периодически снимал бы с него данные тем же tshark-ом. Дальше — как в статье.
И вопросы: на картинках реальные графики? Какие выводы можно из них делать (типа, какие значения должны быть в нормальной ситуации, а когда уже пора чинить сеть)?

Интересная разработка, у вас получилось очень «по-сишному». Есть в этом языке какая-то суровая красота.
Ну и пару слов в защиту Си по поводу «двадцать первому веку кроссплатформенный ассемблер не нужен» — кроссплатформенных ассемблеров не бывает, это противоречит самому определению ассемблера. Си — это язык, оперирующий основными конструкциями, присутствующими на аппаратном уровне в большинстве современных компьютерных платформ, но скрывающий детали реализации. Именно поэтому он очень хорош для написания ПО встроенных систем, драйверов устройств, некоторых модулей операционных систем, и реальной замены ему в этих задачах — нет (ну или можно на C++ писать как на чистом С, что то же самое).

ГОСТ-ы следует применять творчески, сообразно с обстоятельствами. А для того чтобы уверенно это делать — нужно представлять, что в них написано. Возьмём документ 34.601-90, он самый короткий из перечисленных.
Что плохого в том, что он требует написания концепции? Да ничего плохого в этом нет, наоборот хорошо. Даже для маленького сайта, разрабатываемого стартапом из трёх человек — соберитесь в кафе, договоритесь между собой, напишите на салфетке, что сайт должен делать то-то для тех-то, писать мы его будем, условно, на python+django, размещать на хостинге с использованием контейнерной виртуализации. Назовите этот документ концепцией, и дальше ей следуйте. Это убережёт от массы лишних движений и потенциальных переделок.
И будет у вас документация (сюрприз!) — в точном соответствии с ГОСТ-ом, но в объеме, потребном именно для этого небольшого проекта. Вырастет проект — на определённом этапе его доработки придёте к необходимости ТЗ. Опять же, не надо писать все разделы — напишите только нужные. ГОСТ 34.602-89 это явно разрешает.

Есть ли перспективы добавления возможности покупки билетов Октябрьской железной дороги? (МТПК, Ласточки)?

Спасибо за обзор. Так все же — составили ли вы мнение о «соотношении цена/качество/удобство»? Я так понял, что по удобству явный аутсайдер — Panasonic. А как с остальными моделями и параметрами?