Из всего выше прочитанного по диагонали, сделал вывод, что использвание Calculate Linux, испортило в Вас когда то правильно зародившегося Linux-оида. И тут Вы решили, вспомнить, что такое хорошо... Но зря... Зло сдлало своё дело уже.... Очень жаль Вас. Хотелось бы, чтоб Вы реабилитировались. Но тут наверное только LFS уже.... )))))))
Запись коннекта просто прекрасна. Растрогала до глубины души. В ней прекрасно всё. А сколько воспоминаний… Это не просто набор звуков, это магия, что открывала нам портал в сеть и эллюзию безграничных возможностей. Порой по тональности можно было понять, «на скольки» удастся завязаться модему, да на соседской тел. линии, по ночам (днём просто нихрена не работало), а своя линия просто отсутствовала. Эх…
Интересно, но маловато. (
В частности не раскрыт вопрос документирования опто-волконной сети. Понятно, что вопрос сугубо индивидуальный, но как вариант интересно было б. А вообще и отдельной темой можно, да и не только волоконной сети.
С переводом магистральной сети на оптический кабель, дистанционное питание сняли. До этого, на участках сети, магистраль которых, построена на коаксиальном кабеле, местами использовалось дистанционное питание.
p.s. Времена DOCSIS, 540-го кабеля и прочих прелестей )))
Про ядро совсем мало, а по заголовку думается, что сейчас распишут и процессы его загрузки.
Не systemd единым живёт мир Linux. (p.s. да… да… Знаю его тычут всюду, но всё же).
Прекрасно это всё. Только до краха сервера или винтов на нём. Как я понял, бэкапы складываются там же, да небось ещё и на том же винте? Если это так, то всё плохо.
из замечаний:
1. Нет бэкапа на альтернативный носитель. В идеале, второй винт + облако.
2. Бэкапы никак не контролируются. Т.е. они только создаются, а подчищать кто будет?
Дожились, уже BGP на raspberry pi тулим или это raspberry pi разжилось… В любом случае прикольно )
Что касается идеи, лично мне понравилась. Решение не универсальное, и будет иметь часть ограничений, но всё же не стандартный подход — отлично.
Что касается лицензирования. Как я понял в этом варианте можно получить FW, и отдать на forwarding-plane уже агрегированные маршруты. Быть может есть какие то L3 в forwarding-plane, кто позволит за не дорого иметь несколько тыс. маршрутов полученных по bgp. Вот в это и упираться, а с балансировкой нескольких каналов, можно решить меньшей/большей маской отправляемой на forwarding-plane.
Из всего выше прочитанного по диагонали, сделал вывод, что использвание Calculate Linux, испортило в Вас когда то правильно зародившегося Linux-оида. И тут Вы решили, вспомнить, что такое хорошо... Но зря... Зло сдлало своё дело уже.... Очень жаль Вас. Хотелось бы, чтоб Вы реабилитировались. Но тут наверное только LFS уже.... )))))))
В частности не раскрыт вопрос документирования опто-волконной сети. Понятно, что вопрос сугубо индивидуальный, но как вариант интересно было б. А вообще и отдельной темой можно, да и не только волоконной сети.
p.s. Времена DOCSIS, 540-го кабеля и прочих прелестей )))
В целом понял, но боюсь что не до конца. Если не сложно растолкуйте на пальцах )
P.s. Обожаю такие изобретения. Это вам не на Али светодиоды покупать. )))))
Не systemd единым живёт мир Linux. (p.s. да… да… Знаю его тычут всюду, но всё же).
похоже вот!
по мотивам коментариев
Анализ протоколов вышестоящих уровней. У них же там DPI используется…
Как бы не ping-ом ))))
Понравилось изложение. Спасибо.
" Считаю, что это не всегда полезно, но всё-равно стоит «значит», что такое «уровень 4». " Может быть не «значит», а знать?
из замечаний:
1. Нет бэкапа на альтернативный носитель. В идеале, второй винт + облако.
2. Бэкапы никак не контролируются. Т.е. они только создаются, а подчищать кто будет?
Что касается идеи, лично мне понравилась. Решение не универсальное, и будет иметь часть ограничений, но всё же не стандартный подход — отлично.
Что касается лицензирования. Как я понял в этом варианте можно получить FW, и отдать на forwarding-plane уже агрегированные маршруты. Быть может есть какие то L3 в forwarding-plane, кто позволит за не дорого иметь несколько тыс. маршрутов полученных по bgp. Вот в это и упираться, а с балансировкой нескольких каналов, можно решить меньшей/большей маской отправляемой на forwarding-plane.