Предложены радикальные изменения в работу сети в Linux

XML

Это не круто, ну.

его укусил поттеринг

Зачем это, если есть wicd

ну, может xml - это и не круто, но если это все ведет к более четкой, понятной и удобной структуре, что почему бы и нет?

Olaf работает начальником в Novell

начальником чего? о_О

Зачем это, если есть wicd

Мне стоит напоминать, что wicd не умеет ровным счётом ничего, ни 3G, ни PPP/PPPoE, ни VPN, несколько сетевых интерфейсов контролировать не может, даже управления из консоли - и того нет.

Да и при чём тут устаревшая юзерспейсная приблуда, когда речь о целом стеке?

Потому, что xml неудобно читать - глаза сломаешь. Не для людей оно придумано.

Всяко не сложнее замшелых шелл-скриптов.

предложил сегодня на рассмотрение сообщества Fedora свою давно вынашиваемую идею — полностью переписать userspace стек управления сетью в Linux

знает куда обращатся

Мы будем следить за развитием событий.

Судя по стилю, аффтар новости - рашен федораст.

Да и при чём тут устаревшая юзерспейсная приблуда, когда речь о целом стеке?

О да, СТЕК! Это так круто - делать СТЕК!!11

Что плохого в том, что, вполне возможно, отпадёт необходимость NetworkManager'а(который все почему-то ругают) для нормального человеческого управления сетью?

А при чем тут сетевой стек? Они tcp/ip хотят на XML заменить?

Что плохого в том, что, вполне возможно, отпадёт необходимость NetworkManager'а(который все почему-то ругают) для нормального человеческого управления сетью?

вполне возможно

почему-то ругают

Отличный ответ (это же не вопрос, правда?): «ХЗ что такое этот новый стек, но пусть попробуют». И проблема с этим подходом одна - если его протолкнут в Федору и RHEL, а он окажется таким говном, каким выглядит, это говно останется с нами навсегда.

Хотя, конечно, могло быть и хуже - это управление интегрировали бы в systemd. WAIT OH SHI~

Они tcp/ip хотят на XML заменить?

userspace

А при чем тут сетевой стек?

Сетевой - не причем. Но «стек» - это такой модный термин, которым что только не называют, потому что «стек» - это солидно и ынтерпрайзно, это не какие-то там баш-скрипты, и даже не «демон».

И проблема с этим подходом одна - если его протолкнут в Федору и RHEL, а он окажется таким говном, каким выглядит, это говно останется с нами навсегда.

Если он окажется не таких уж и хорошим, в RHEL он не попадёт.

Хотя, конечно, могло быть и хуже - это управление интегрировали бы в systemd. WAIT OH SHI~

Конечно, ведь конфигурировать соединения посредством правки конфигов и bash-скриптов - это куда более современно и дружественно для пользователя. И, ах да, юниксвейно же.

то что юниксвейно - уже вполне достаточно

и никто не мешает делать GUI-надстройки, самостоятельно дергающие bash-скрипты и редактирующие конфиги

от инженера Red Hat и текущего мэйнтейнера busybox, Denys Vlasenko

Мог бы и на русском написать, вполне возможно что он здесь обитает.

Если он окажется не таких уж и хорошим, в RHEL он не попадёт.

Достаточно, чтобы кто-то в Redhat признал его «достаточно хорошим».

Конечно, ведь конфигурировать соединения посредством правки конфигов и bash-скриптов - это куда более современно и дружественно для пользователя.

Их хотя бы можно поправить. А вот поправить что-то в DBus-демоне уже гораздо сложнее.

И, ах да, юниксвейно же.

Утипути.

> Новая архитектура сетевой подсистемы позволит, как считает Olaf, полностью отказаться как от неподдерживаемой мешанины bash-скриптов (давным-давно устаревших ifup/ifdown и прочего), так и от критикуемого за сложность и такую же неподдерживаемость NetworkManager.

NetworkManager не единственное GUI для настройки сети. Видео. Звук не знаю как добавить, поэтому пишу так. В первом экране - настройка сетевых устройств. «Добавлять» не нужно: новое устройство само добавляется в список, в колонке «IP-адрес» будет написано «Не настроено». Настраиваем - и всё работает. Все доступные настройки, кроме настроек брандмауэра, я показал. Настройки брандмауэра доступны в другой утилите, здесь же только присовение зоны брандмауэра. Ещё в окне настроек есть галочки «Использовать NetworkManager» и «Использовать традиционный ifup». В случае выставления первой галочки все настройки закрашиваются серым и становятся недоступными для настройки, а в системном трее появляется NetworkManager.

> P.S. Olaf работает в Novell, и если вы нашли в его предложении архитектурные проблемы, или у вас есть идеи, как сделать лучше, то присылайте ему ваше резюме.

Да ведь у них и так всё сделано идеально!

GUI-надстройки, самостоятельно дергающие bash-скрипты и редактирующие конфиги

Надеюсь, мне не надо объяснять, почему такая схема убога и несостоятельна?

Их хотя бы можно поправить.

Конечно же можно. Как и init-скрипты. Только что-то никто этим не пользуется, поди переписать эти костыли быстрее, чем разбираться.

А вот поправить что-то в DBus-демоне уже гораздо сложнее.

Он один, а разномастных неподдерживаемых шелл-скриптов от разных авторов - гора.

Я забыл показать окно настройки ADSL-модема! Вот оно: http://img705.imageshack.us/img705/9673/yast230.png.

надо :)

схема правильная, удобная и юниксвейная

схема правильная, удобная и юниксвейная

That's why we can't have nice things.

Их хотя бы можно поправить.

Конечно же можно. Как и init-скрипты. Только что-то никто этим не пользуется

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

А вот поправить что-то в DBus-демоне уже гораздо сложнее.

Он один, а разномастных неподдерживаемых шелл-скриптов от разных авторов - гора.

Не виляй. Скажи прямо: «да, поправить DBus-демон проще», если ты так считаешь. И сразу готовь объяснение, как именно ты будешь править этот демон, когда у тебя «в поле» нарисуется проблема.

> Quick, using any of the existing frameworks, can you tell me how to...

> - ... disable IPv6 on a specific interface?
> - ... set up an interface for DHCPv4 and DHCPv6?

Наверное здесь: http://img443.imageshack.us/img443/3695/yast231.png

> - ... change the firewall rules on your UMTS modem?

http://img715.imageshack.us/img715/6407/yast232.png

Остальное не знаю.

Ну почему эти сторонники XML такие безмозглые?

Зачем писать так:

<interface>
  <name>eth0</name>

  <control>
    <mode>boot</mode>
    <link-detection>
      <timeout>60</timeout>
      <require-link />
    </link-detection>
  </control>

  <ethernet>
    <port-type>tp</port-type>
    <link-speed>1000</link-speed>
    <offload>
      <tso>disable</tso>
    </offload>
  </ethernet>

  <link>
    <mtu>8000</mtu>
    <txqlen>50</txqlen>
  </link>

  <firewall>
    <zone>secure</zone>
  </firewall>

  <ipv4:dhcp>
    <enabled>true</enabled>
    <acquire-timeout>15</acquire-timeout>
  </ipv4:dhcp>
</interface>

когда короче, быстрее для парсинга и читабельнее так:

<interface name='eth0'>
  <control mode='boot' >
    <link-detection timeout='60' require-link />
  </control>

  <ethernet port-type='tp' link-speed='1000'>
    <offload tso='disable' />
  </ethernet>

  <link mtu='8000' txqlen='50' />

  <firewall zone='secure' />

  <ipv4:dhcp enabled='true' acquire-timeout='15' />
</interface>

Кто меня просветит?

Olaf Kirch, участник коммьюнити SUSE, матерый Linux-хакер (с начала 1990х) и автор неоднократно переиздававшихся книг по настройке и администрированию сети в Linux, предложил сегодня на рассмотрение сообщества Fedora свою давно вынашиваемую идею — полностью переписать userspace стек управления сетью в Linux

не нужно.

NetworkManager'а(который все почему-то ругают)

потому-что он частенько глючит, и в отличие от скриптов его хрен починишь.

Например потому-что твой пример не является валидным XML.

Ну почему эти сторонники XML такие безмозглые?

присоединяюсь к вопросу.

Например потому-что твой пример не является валидным XML.

Первый, второй, или оба? И как ты определяешь невалидность без DTD или схемы?

потому-что он частенько глючит

Например?

ты не plm у тебя слишком плохо получается...

При чем тут скрипты? Я про конфиги. Хотя бы раз пробовал править xml руками?

разномастных неподдерживаемых шелл-скриптов от разных авторов - гора.

Гентушнек? Арчевод?

любители xml конфигов заповедуют то, что руками править не придётся, а только специальными одобренными тулзами.

Негоже троллить уважаемый, require-link не является краеугольным камнем обсуждаемого вопроса.

That's why we can't have nice things.

Мы не можем иметь глюкодром вроде windows? Да, это такая потеря %)

повышают читаемость для человека при десятке параметров например в ethernet можно задавать mac длинный, включать/выключать контрольные суммы, offloading тоже tso не ограничивается.

если будет одна большая строка на 500 символов это плохо читается. а так оно очень похоже на обычный конфиг в стиле bind или nginx: section { key=value; } только, есть проверка правильности логики закрытия скобок для вложенных секций.

парсер без атрибутов для embed тоже будет проще.

вы же предлагаете использовать: section { key1=value1;key2=value2;key3=value3;....}

XML, хотя и хуже читаем чем YAML, при хорошей стандартизации отступов, коротких названиях секций и маленьком размере файла вполне удобен.

Для сети больше 40-100 интерфейсов (виртуализация) не предвидится на одном хосте, значит конфигурационный файл будет не очень больших размеров, особенно если будут хорошие значения полей по-умолчанию и будет мало обязательных полей

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

ТС забыл указать источник копипасты.

парсер без атрибутов для embed тоже будет проще.

Не смешите, парсер для полуxml писать кроме вас никто не собирается.

например в ethernet можно задавать mac длинный, включать/выключать контрольные суммы

Так почему нельзя задать это атрибутами?

offloading тоже tso не ограничивается.

Если описание offloading такое сложное, никто не мешает сделать открывающий-закрывающий теги.

В windows настройке сети легко обучить даже макаку

Легкость для макак почему-то не является приоритетом в документе по ссылке.

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

Легкость для макак следствие устоявшегося решения для задачи.

Лёгкость для макаки - это следствие наличия гуя. И всё.

Т.е. если будет единообразный метод настройки, то к нему будет гуйня

...разная для каждого дистра.

А пока в каждом дистре свои извраты.

Так будет всегда.