Опубликован roadmap RHEL7

cannot be used to spawn things «at 6 am every monday»

Спасибо, теперь понятно. Действительно, crond не жилец.

Это не очень много, к тому же в данном случае форк особого труда не представляет.

Не сложно, но человек 10 на full time потребуется. Кто будет платить?

Откуда Вы вообще взяли про бинарные конфиги? Я написал, что включение крона в системд выглядит логичным.

и CUDA

Её в RHEL официально нет.

в данном случае форк особого труда не представляет.

Если ты об udev, то форк таки представляет сложность. У форкера должно быть дофига всякого железа и/или доступ к значительной тестовой базе.

Откуда Вы вообще взяли про бинарные конфиги?

Это была шутка.

Я написал, что включение крона в системд выглядит логичным.

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

Кто будет платить?

Космонавт. Он будет вынужден это сделать.

Если ты об udev, то форк таки представляет сложность.

Чем плох udev-181, кроме того, что уже не развивается? Какие проблемы с базой VendorID:DevID? У авторов udev действительно дофига железа? Что мешает кодообмену форка и systemd? Что мешает патчить текущий systemd для сборки и работы отдельного udev?

Опубликован roadmap RHEL7 (комментарий)

Логично не с моей точки зрения, а с точки зрения Поттеринга.

Какие проблемы с базой VendorID:DevID?

База идентификаторов - это не форк.

У авторов udev действительно дофига железа?

У Хартмана? О да. И в качестве тестовой базы - все дистры, использующие udev.

Что мешает кодообмену форка и systemd?

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

это моя интерпретация

Взялся за гуж, давай уж тяни до конца.

Её в RHEL официально нет.

капец редхату

База идентификаторов - это не форк.

Она в общем-то мало роли играет. Я её к слову приплёл.
А что не так с udev-181? Почему нельзя пользоваться ей?

У Хартмана? О да. И в качестве тестовой базы - все дистры, использующие udev.

Он когда-то начинал с нуля. Другие начнут не с нуля хотя бы. Убунту и дебиан это тоже не мало.

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

Мне всё-равно не понятно, что не так с последней версией до объединения, что её обязательно надо переписывать. Она что-то не так делает, что-то важного не умеет?
Какая сейчас версия в 6-том стэйбл и в тестинге?

А что не так с udev-181? Почему нельзя пользоваться ей?

Она не умеет отдельный /usr и новые ядра не факт, что будет долго поддерживать.

Она не умеет отдельный /usr

Да, что-то я это упустил. Но, это можно решить костылями с dbus. Некрасиво, но не смертельно. Либо udev-177 (емнип это последняя без проблем с /usr).

Читать отсюда и далее по списку http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg05287.html

Шикарно. Поттерингу сказали, что dbus это лишняя зависимость для удева. А он ответил, что «а мы его скоро в ядро, и больше вас это беспокоить не будет».

Да, что-то я это упустил. Но, это можно решить костылями с dbus.

А причём тут dbus?

Некрасиво, но не смертельно. Либо udev-177 (емнип это последняя без проблем с /usr).

Оно точно на новых ядрышках заведётся? И как быть с новым софтом, который затребует версию выше?

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

Ясно, т.е. DaaS и не более

Оно точно на новых ядрышках заведётся? И как быть с новым софтом, который затребует версию выше?

С 3.2.x работал. Да и сейчас с 3.4.x требует от меня до 177 сдаунгрейдить.

А причём тут dbus?

Ни при чём, я не туда на зависимости глянул. Но, скостылить всё равно можно. Проблема же в том, что половина udev и большая часть её зависимостей лежит в /usr/lib.

Он когда-то начинал с нуля.

В других условиях и с другой тестовой базой.

Убунту и дебиан это тоже не мало.

Дебиан сам практически ничего не разрабатывает, а Шаттлворт ввязываться не станет.

Мне всё-равно не понятно, что не так с последней версией до объединения, что её обязательно надо переписывать.

Это к Поцерингу, сейчас изменения в udev вносит он и примкнувшие к нему. Эти изменения постепенно будет затруднять обмен кодом для тех, кто решит остаться на udev-181.

С 3.2.x работал. Да и сейчас с 3.4.x требует от меня до 177 сдаунгрейдить.

А как насчёт следующих версий?

Ни при чём, я не туда на зависимости глянул. Но, скостылить всё равно можно. Проблема же в том, что половина udev и большая часть её зависимостей лежит в /usr/lib.

Можно вообще переписать, или devd из фряхи портировать. Только кто будет заниматься этим?

да как раз последний раз ничего страшного не случилось, даже постгресс сам проапдейтился без dump/restore.

Забыли только включить несколько сервисов (а сами они почему-то не включились), так что после ребута по питанию сайт некоторое время не работал.

Вот следующий апдейт с его перездом /bin в /usr чую будет стремным

да, у rhel'а нет проблем с апдейтами :-)

Ну и отлично. Будет наконец нормальный IPC :]

Не будет.

:(

Дебиан сам практически ничего не разрабатывает, а Шаттлворт ввязываться не станет.

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

сейчас изменения в udev вносит он и примкнувшие к нему

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

А как насчёт следующих версий?

Этого я не знаю. На 3.5-rc* пока тоже не сломалось, дальше это уже гадание.

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

Вся надежда на тебя. :) В реальности-то это уже есть и работает здесь и сейчас.

Кстати, кто в курсе, Линус как-нибудь уже комментировал systemd и прочие грядущие нововведения? Зная любовь Линуса к вбросам, он сам на себя не похож - скромно молчит.

Почему тебя печалит что люди могут распоряжаться их капиталом?

Если ты понял — то что тебя останавливает от этого шага?

В чем выражается коммунизм?

• планировщики AutoNuma/SchedNuma;
• zero-copy сетевая инфраструктура;
• поддержка multiqueue сетевыми интерфейсами;
• hot-plug памяти;

Отлично.

• systemd.

Чертовы неофиты.

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

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

это коренное изменение интерфейса всей системы, осталось поменять бесполезный по большому счёту в таких условиях shell на юникс аналог power shell

И ты был неправ. RHEL 7 с systemd выходит в 2013-2014

сдаётся мне, из-за позиции customer-ов, что они до сих пор не слезли с rhel4.

К сожалению, в RHEL 7 будет Gnome Shell.

Это радостное известие.

По поводу udev: он используется в initrd и встраиваемых системах. То есть возможность собрать его отдельно остане6тся пока существует initrd. (В встроенные системы systemd можно пропихнуть, хотя там он явно не нужен). Т.е. форк не потребуется.

udev: он используется в initrd и встраиваемых системах.

Верная предпосылка...

То есть возможность собрать его отдельно остане6тся пока существует initrd.

...но вывод не следует из предпосылки. Поцеринг вполне может сказать «для строенных систем используйте mdev» или «для initrd используйте udev-181» или еще что-то. Он ведь отчитывается перед начальством, а в чем заинтересовано его начальство - ХЗ.

В встроенные системы systemd можно пропихнуть, хотя там он явно не нужен

Производителям встроенных систем тоже нужнеы баззворды. Новая MontaVista уже использует systemd.

«для initrd используйте udev-181»

Использование разных версий udev в initrd и основной системе приведет к куче грабель на ровном месте.

В остальном согласен.

Про MontaVista не знал, спасибо.

на интегрированные до невозможности системы.

Главное чтобы не глючило и было написано нормально. Вопрос в том достаточно ли скиллов у Леннарта для этого.

хорошо спроектированные, простые, с простым и понятным интерфейсом взаимодействия компоненты

вот тут не согласен. Были бы они супер-пупер никто бы и не пилил альтернативы. Как раз интерфейсы взаимодействия это главная беда юникс-софта. Ты же не назовёшь пайпы и файлы устройств в /dev «хорошо спроектированным понятным интерфейсом взаимодействия»? Вот поэтому и придумывают всякие костыли типа dbus итп.

что тебя останавливает от этого шага?

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

«За бесплатно» я и так делаю максимум того что готов делать. Создавать «своё» коммьюнити не вижу смысла, не выгорит.

В каноникле только пеарщеки нужны, так что мимо.

Так что неизвестно еще как они гном3 переделали.

Наверняка цинамон будет по умолчанию

Да 100500 отличий от нормальных других дистров. Мы продлевать подписку на rhel6.2 не будем, убунта справляется не хуже, но хоть не превращается в кусок говна когда rhn не доступен.

А че не дебиан?

Может стоит вместо федоры заюзать центось?

А че не дебиан?

1) пять лет security-обновлений для ubuntu server 12.04 это не хухры-мухры

2) софт местами новее (ядро итп, для меня это имеет значение)

3) обещали офицально портировать новые ядра на lts-релизы раз в год или раз в два года

И новые версии выходят чаще, цикл релизов очень предсказуемый. У debian-а есть backports, но это, имхо, чисто поиграться потому что там версии софта скачат и при апдейтах возникают проблемы (хотя бы конфиги приходится просматривать на предмет того что нового добавили, чего старого убрали).

В остальном по-барабану, я все дистры считаю костыльными и для себя решил не привязываться к чему-то конкретному. Испаганется убунта - буду ставить что-то другое.

Общество дало RH деньги на то, что бы ...

В чистом виде. :)

На самом деле было так: 1. Многие (клиенты) задолбались от глюков и безальтернативности М$ 2. Личные связи топ-менеджеров Красной Шапки сделали своё дело 3. Грамотный руководитель всегда избегает вендор-лок (если есть возможность) 4. Кризисы (начала 2000-х, их середины и т.п.) резко обрезали аппетиты IT отделов крупных компаний 5. Что там еще %)

То есть возможность собрать его отдельно остане6тся пока существует initrd. (В встроенные системы systemd можно пропихнуть, хотя там он явно не нужен). Т.е. форк не потребуется.

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

LOR - аналитик по встрече с ним c вер. 95% попадает в когорту «Ниасиливщих»

Только наметил в своей компании переход с зоопарка дистрибутивов (центось, дебиан, убунту, сусе, редхат, рхел) на рхел, как тут такое...буду теперь экспериментировать с фрибсд и, в случае успеха, переезжать на нее.