После слияния (https://www.opennet.ru/opennews/art.shtml?num=33526) проектов systemd и udev разработчики дистрибутива Arch Linux приняли решение (http://www.archlinux.org/news/systemd-tools-replaces-udev/) распространять udev не виде отдельного пакета, как сейчас, а в составе нового пакета systemd-tools. Кроме udev в systemd-tools будут включены некоторые другие утилиты, развивающиеся в составе проекта systemd, но которые могут быть использованы в дистрибутивах не перешедших на системный менеджер systemd. Кроме того, создание нового пакета фактически означает добавление компонентов systemd в базовый репозиторий дистрибутива.
При выполнении обновления пользователям Arch Linux не стоит смущаться, что система предложит им заменить udev на systemd-tools. При одновременном обновлении пакета linux возможно будет выведена ошибка в процессе создания initramfs, указывающая на недоступность udev. В этом случае после завершения обновления следует повторно запустить команду 'mkinitcpio -p linux' для того чтобы убедиться, что для установленного ядра Linux создан загрузочный образ.URL: http://www.archlinux.org/news/systemd-tools-replaces-udev/
Новость: https://www.opennet.ru/opennews/art.shtml?num=33993
уже обновили пакеты
Гы наверно кто-то как и я удивился когда пакман предложил заменить и так же в анонсы полез. Но в отличие от меня новость решил накатать по такому поводу.
Я удивился когда у меня libudev был не найден, иксы не запустились и вообще глюки поползли с железом. Хотя на второй раз я вошел в консоль таки и смог дообновиться. Опять яндекс саботировал работу. Пол системы обновил, затер udev, а новый пакет с udev пришел позднее.
Из новостей слышал, что udev поглощен systemd, поэтому удивлен не был. Потом я конечно полез почитать что там пишут на сайте арча ))
Я еще не перезагружал. Комп с Арчем далеко и в случае факапа фиксить некому. На следующей неделе предстоит поучаствовать в этой лотерее имени Леннарта.
Поиск systemd-tools по форумам Арча облегчения не принеc: народ срёт кирпичами по поводу отваливания всего что только можно и тормозов при загрузке; есть и те, у кого система не бутится и не только из-за кривых не обновляющихся зеркал.
Предполагаю, что переход на systemd, который уже очевидно не за горами, будет фееричен и ознаменуется великим исходом арчеводов на Генту, Слаку и Дебиан с Убунтой. Лично я пока закапывать не буду, слишком мне Арч понравился в целом.
Дело привычное как для Gentoo так и для Arch-a. Никто никуда не повалет, если хочет быть на пике развития Linux.
У Арча есть и другие ориентиры, которые рядом с systemd образуют взаимоисключающие параграфы: You've reached the website for Arch Linux, a lightweight and flexible Linux® distribution that tries to Keep It Simple.
Кстати арчевский инит действительно один из самых простых и удобных для администрирования. Пока еще.У ценителей изощренного мазохизма на "пике развития" и тестирования на себе сомнительных экспериментальных разработок есть же специальный дистр для этих благородных целей.
Читаем новость внимательно, udev пеперь в той части в которой его видят разработчики. Новость и речь идет не о пускателе, а о udev.
Читаем и новость и весь тред на который отвечаем тоже читаем, ага.
ненене, когда я писал в основном под системный/пользовательский софт, арч был моим дистром, потому что меня непредсказуемые смены мажорных версий библиотек даже как-то дисциплинировали. Теперь только веб и 90% RoR, сижу под Убунтой на МБП и как Шерлок Холмс, стараюсь не держать в голове степени разрушительности и неосмотрительности авторской команды какого-нибудь Cairo по сравнению с командой какого-нибудь ОpenSSL, потому что своих гемов хватает, отвлекся на 2 недели, а они там все интерфейсы переворочали, завидую обезьянкам Джавистам пишушим как копатели Беломорканала по UML схемам с итерациями в полгода.Удачи короче тестерам эйджа Линукса в виде Арча, потому что даже у Генту можно помаскировать даже на серваках и облаках мажорные апдейты и замутить что-нибудь по хардкору. Но Арч - no way. Разве что нетерпится или поразрабатывать самому чё. Дистр классный но времени всего 24 часа в сутках.
А противоречие-то где?
systemd гораздо проще кучи скриптовых костылей, работающих через пень-колоду.
К тому же он полностью соответствует философии unix-way.
> А противоречие-то где?
> systemd гораздо проще кучи скриптовых костылей, работающих через пень-колоду.
> К тому же он полностью соответствует философии unix-way.Чем проще? Приведи пару примеров.
> Чем проще? Приведи пару примеров.лучше попросить у него обосновать соответствие. хотя если ты хочешь покушать неспешно, как гурман, то тогда можно и так начать.
У гентуводов USE=+systemd уже появился :)
И в каком-же это пакете +systemd?
В портажах таких нет.
Ага, включенного по дефолту пока нету. Но сам флаг уже присутствует.
>На следующей неделе предстоит поучаствовать в этой лотерее имени Леннарта.Ну-с, где там минусы?
"Не было печали, апдейтов накачали." :)
> Я удивился когда у меня libudev был не найден, иксы не запустились
> и вообще глюки поползли с железом.И эти люди наезжают на убунту... :)
> Опять яндекс саботировал работу.Я перешел на французкие зеркала - чего и вам рекомендую, там запаздываение на сутки идет где-то, но зато работает стабильно.
После сегодняшнего полного обновления - ни единого глюка не было.
Я перешел на Дебиан - чего и вам рекомендую, там запаздываение на год идет где-то, но зато работает стабильно.
> но зато работает стабильно.OpenSSL. бу-го-га.
Server = http://ftp.linux.kiev.ua/pub/Linux/ArchLinux/$repo/os/$arch
работает отлично
А кто-то лезет в анонсы ПЕРЕД обновлением, например. А то всякое бывает, знаете ли.
>Кроме udev в systemd-tools будут включены некоторые другие утилиты, развивающиеся в составе проекта systemdЧто за утилиты?
> Что за утилиты?Например:
systemd-delta - программа, показывающая разницу между дефолтными и админовскими конфигами юнитов
systemd-tmpfiles - демон создания/очистки временных файлов и каталогов
systemd-detect-virt - утилита, определяющая технологию виртуализации, под которой запущена система
udevadm - программа для управления systemd-udevd.
Странно, что туда не вынесли systemd-cgtop и systemd-analyze.Вообще, имхо, очень правильное решение - разбить systemd на несколько пакетов. Ведь это уже давно не единый программный продукт, а группа связанных подсистем. Пихать их в один пакет идеологически неверно.
> Кроме того, создание нового пакета фактически означает добавление компонентов systemd в базовый репозиторий дистрибутиваНеудивительно, учитывая, что мейнтейнер initscripts в арче Том Гундерсен - один из заслуженных разработчиков systemd (видимо, человека порядком достало поддерживать sysvinit, что неудивительно). Странно, что это не произошло раньше.
Кто следующий на очереди? Помнится, не менее заслуженный разработчик systemd Майкл Бийбл - мейнтейнер rsyslog в дебиане...
Там bsd-style система инициализации была, а не sysvinit
> Там bsd-style система инициализации была, а не sysvinitОна и осталась, насколько я понял. Просто юдев идет в этом пакете с прочими утилитами.
В арче планируется переход на systemd по дефолту?
> Кто следующий на очереди? Помнится, не менее заслуженный разработчик systemd Майкл Бийбл
> - мейнтейнер rsyslog в дебиане...Это было бы сильно :)
"/etc/rc.d/sshd start" это sysvinit?
debian с полагающиеся ему крейсерской скоростью тоже переходит. в тестинге точно есть systemd. но в вики пишут что ментейнер какого-то пакета жестко прописал зависивость от sysvinit.
Дебиан никуда не переходит (по крайней мере пока). У него кроме линукса есть kfreebsd, возможно будет hurd, куда systemd не прикручивается.
Ну это же дебиан, они никого не будут заставлять, а переход будет после переписывания определенного количества инитскриптов. Но перейти можно уже сейчас, systemd может выполнять старые скрипты. Не зря же его включили в тестинг?
> Но перейти можно уже сейчас, systemd может выполнять старые скрипты.Согласен. Использую systemd на десктопе примерно пол года. Особых проблем не возникало.
ЛППВ тестинге чего только нет... - из этого не следует что кто-то куда-то переходит.
> переход будет после переписывания определенного количества инитскриптов
Никакого переписывания нет и не предвидится. Просто добавили пакет, который будут ставить егойные фанаты. Систему ради ерунды ломать не будут.
> В тестинге чего только нет... - из этого не следует что кто-то
> куда-то переходит.
>> переход будет после переписывания определенного количества инитскриптов
> Никакого переписывания нет и не предвидится. Просто добавили пакет, который будут
> ставить егойные фанаты. Систему ради ерунды ломать не будут.Для дебиана (если брать в расчет только линуксовское ядро) проблем нет. Systemd (так же как upstart, runit, init-ng и т.д.) совместим с sysvinit. Но они не совместимы между собой! Т.е. (в случае дебиана) ничего переписывать не требуется.
P.S. Не требуется, это не значит, что нежелательно. Ссылку на баг с postgresql я уже приводил.
> Ссылку на баг с postgresql я уже приводил.Я что-то пропустил?
Извините, забыл что я не регистрировался
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618675. То есть скрипт работает, но не может полноценно использовать возможности systemd.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618675Ага, забавно. Взрослый дядинька пожал плечами и ответил адепту, поломавшему все *нахрен*: а иди-ка ты в песочек играйся...
> но не может полноценно использовать возможности systemd
Ты смотри - одни тормоза прогрессу... Какие-то кластеры, понимаешь, опции, анализируемые init-скриптом, обратная совместимость и прочая "ерунда".
PS: В другой теме недавно один школьник все пыжился написать конфиг для systemd, полноценно заменающий штатный init-скрипт для дебиановского sshd (оно попроще постгрессу будет, на порядок). Очень похоже. Человек даже не удосужился разобраться в том, *что именно делает* init-скрипт. Хором читать пришлось...
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618675
> Ага, забавно. Взрослый дядинька пожал плечами и ответил адепту, поломавшему все
> *нахрен*: а иди-ка ты в песочек играйся...Michael Stapelberg не совсем адепт. I3-wm вещь интересная, хотя и на любителя.
>> но не может полноценно использовать возможности systemd
> Ты смотри - одни тормоза прогрессу... Какие-то кластеры, понимаешь, опции, анализируемые
> init-скриптом, обратная совместимость и прочая "ерунда".Дело не в тормозах, хотя я считаю что 25 сек. на запуск сервера это много.
А в том, что init-скрипт постгреса написан несколько неправильно. ИМХО конечно.P.S. Я не защищаю systemd (для меня это пока десктопная игрушка), но думаю, что если удастся привести к одному виду систему инициализации хотя бы основных дистрибутивов будет неплохо.
> Michael Stapelberg не совсем адепт. I3-wm вещь интересная, хотя и на любителя.Ну, человек так или иначе - предметно показавший свою некомпетентность на примере.
> Дело не в тормозах, хотя я считаю что 25 сек. на запуск
> сервера это много.Поковыряйтесь с биосом - может уменьшите время. Причем тут вообще init и как магиццки вам поможет systemd? Если вам важны уже секунды простоя - оптимизировать скорость загрузки довольно глупо.
> А в том, что init-скрипт постгреса написан несколько неправильно.
Об чем неправильно?
> если удастся привести к одному виду систему инициализации хотя бы основных дистрибутивов будет неплохо.
Для этого существуют стандарты. LSB, к примеру. Обсуждайте, развивайте, улучшайте. Зачем нужна просто еще одна система инициализации, причем от откровенного "пионера" (который далек от серверной специфики, который не умеет писать кроссплатформенный код и т.п.)?
>> Michael Stapelberg не совсем адепт. I3-wm вещь интересная, хотя и на любителя.
> Ну, человек так или иначе - предметно показавший свою некомпетентность на примере.Не буду спорить .
>> Дело не в тормозах, хотя я считаю что 25 сек. на запуск
>> сервера это много.
> Поковыряйтесь с биосом - может уменьшите время. Причем тут вообще init
> и как магиццки вам поможет systemd? Если вам важны уже
> секунды простоя - оптимизировать скорость загрузки довольно глупо.Дело не в общей скорости загрузки системы, а postgresql сейчас имею (это тестовый десктоп, напихано много лишнего).
>systemd-analyzeStartup finished in 2719ms (kernel) + 36656ms (userspace) = 39376ms
>systemd-analyze blame25681ms postgresql.service
21244ms mysql.service
16454ms uml-utilities.service
Т.е. из 36 сек userspace 25 сек стартует постгрес.>> А в том, что init-скрипт постгреса написан несколько неправильно.
> Об чем неправильно?Меня несколько раздражают строки вида
[ -r /usr/share/postgresql-common/init.d-functions ] || exit 0
Не очень удобно искать причину почему сервер не стартует.
> Т.е. из 36 сек userspace 25 сек стартует постгрес.А инит-скрипты-то тут причем?
> Меня несколько раздражают строки вида
> [ -r /usr/share/postgresql-common/init.d-functions ] || exit 0
> Не очень удобно искать причину почему сервер не стартует.Конкретно данная строчка довольно безобидная. Я почти наверняка уверен, что сервер у вас стартует не из-за того, что вы ручками права на этом файле "настроили". Других "строк вида" - не видно.
А вообще, данная выглядит багом - вот и завели бы оный...
>> Т.е. из 36 сек userspace 25 сек стартует постгрес.
> А инит-скрипты-то тут причем?При том, что руками я могу стартовать посткгес примерно за секунду.
> Конкретно данная строчка довольно безобидная. Я почти наверняка уверен, что сервер
> у вас стартует не из-за того, что вы ручками права на
> этом файле "настроили". Других "строк вида" - не видно.Вопрос не в постгрессе, а в том, что подобные конструкции часто встречаются в init-скриптах.
P.S. Инит-скрипт постгресса не запускает сервер при неправильном синтаксисе в postgresql.conf (причем без варингов), но постить сотню строк скриптов считаю неправильным.
>>> Т.е. из 36 сек userspace 25 сек стартует постгрес.
>> А инит-скрипты-то тут причем?
> При том, что руками я могу стартовать посткгес примерно за секунду.Тогда это можно сделать и из инит-скрипта или systemd. Только нужно-ли - вдруг делается-то вовсе не ерунда в процессе?
>> Конкретно данная строчка довольно безобидная. Я почти наверняка уверен, что сервер
>> у вас стартует не из-за того, что вы ручками права на
>> этом файле "настроили". Других "строк вида" - не видно.
> Вопрос не в постгрессе, а в том, что подобные конструкции часто встречаются
> в init-скриптах.И будут, если вы будете продолжать как сейчас считать что багрепортингом должны заниматься добрые феи-валшебницы.
> Дело не в тормозах, хотя я считаю что 25 сек. на запуск сервера это много.ну.. лол. Novell Netware >= 5.0 с вами бы не согласилась :-D
> ну.. лол. Novell Netware >= 5.0 с вами бы не согласилась :-DДавно не связывался с нетварью. Она кому то нужна? Т.е. клиенты которые до сих пор её используют.
В гос.структурах кое-где еще осталась. Я к тому, что скорость загрузки сервера - не тот параметр из-за которого стоит биться головой о стену.
> Я к тому, что скорость загрузки сервера - не тот параметр из-за которого стоит биться головой о стену.Согласен. Но если есть возможность упростить (то есть сделать более прозрачным, скорость здесь не первостепенный фактор) процесс загрузки почему бы это не сделать. Естественно без потери надежности.
Как раз с этим тут не всё так очевидно. Смотрел systemd на SuSE 12.1. И долго ходил по граблям, чтобы прогнуть несколько сервисов под это дело. Логи невнятные. Понять что-то по ним проблематично. Особенно когда стоит задача написать собственный конфиг для этой штуки. Оно могло вообще молча умереть. Если сервис отвалился, или не взлетел(нужно было погонять watchdog, да. я знаю, что оно само умеет это делать), то systemd частенько думал, что всё хорошо. С сокетами/пайпами тоже было не все гладко.
В целом идея мне нравится, но уж больно сырое оно.
> Для дебиана (если брать в расчет только линуксовское ядро) проблем нет. Systemd
> (так же как upstart, runit, init-ng и т.д.) совместим с sysvinit.http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dis...
- добрая половина багов (я польстил) от этой самой "совместимости".А это вот - только то, что ваш гуру написал:
http://www.freedesktop.org/wiki/Software/systemd/Incompatibi...> Но они не совместимы между собой! Т.е. (в случае дебиана) ничего
> переписывать не требуется.Ох, фантазеры...
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dis...- добрая половина багов (я польстил) от этой самой "совместимости".
Нормальное состояние для sid-а.
>Нормальное состояние для sid-а.В тестинге не на много лучше. И это же без учета еще доброго десятка зависимостей и рекомендаций.
Потом сравним с расово и религиозно неверным upstart. (не троллинга ради конечно) http://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;p...
>>Нормальное состояние для sid-а.
> В тестинге не на много лучше. И это же без учета еще
> доброго десятка зависимостей и рекомендаций.
> Потом сравним с расово и религиозно неверным upstart. (не троллинга ради конечно)
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;p...systemd (по сравнению с upstart) больше затрагивает базовую систему.
Use case (не смог подобрать русского термина) systemd мне понятен. На счет реализации... будем посмотреть. Пока стоит на тестовом десктопе (debian sid). О более серьезном использовании буду думать когда (если) он появится в бетах RHEL или SLES.
Я как бы влез в разговор про совместимость с SysV-стайл скриптами. В этом апстарт очевидно уделывает systemd.
То что systemd являет собой уже отдельную параллельную привычному юниксвейному развитию ГнуЛинукса систему это же никто не отрицает ни Поттеринг сотоварищи ни его недоброжелатели.
https://www.opennet.ru/openforum/vsluhforumID3/84833.html#110
> Нормальное состояние для sid-а.Но ненормальное для утверждения о "совместимости".
>> Нормальное состояние для sid-а.
> Но ненормальное для утверждения о "совместимости".Я имел ввиду то, что количество багов в сиде зависит не только от самого пакета, но также от состояния зависимых/зависящих пакетов, обновления версии в апстриме и т.д.
Для более предметного разговора не могли бы Вы привести инит-скрипт который корректно исполняется sysvinit, но не systemd? Или номер бага.
Здесь не достаточно было? http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dis...
Вот первый попавшийся красавец:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624599
> Здесь не достаточно было? http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dis...В сиде у sysvinit 58 багов, у systemd 61. Учитывая большую сложность systemd это вполне допустимо.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624599УМВР. Хотя пометки о снятии бага я не вижу. systemd-44
>> Здесь не достаточно было? http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dis...
> В сиде у sysvinit 58 багов, у systemd 61. Учитывая большую сложность
> systemd это вполне допустимо.Учитывая статус required у sysvinit и несопоставимые статистики использования пакетов - соотношение багов достаточно странное, согласитесь. Даже если до кучи добавить баги в initscripts и т.п.
PS: А по поводу сложности - вы зря. Сейчас забросают какашками свои же... "Хорошо известно" (тм), что sysvinit скрипты - неподдерживаемый глючный кашмар целиком из костылей.
Полностью с Вами согласен. Технология достаточно сырая.
Кстати ветка началась с того, что я написал, что дебиан _НЕ_ будет переходить на systemd ;)
> Для более предметного разговора не могли бы Вы привести инит-скрипт который корректно
> исполняется sysvinit, но не systemd? Или номер бага.К примеру предыдущего оратора еще #668798, #650382, #608456.
Ну и ладно, я все равно стандартную систему иницализации поменял на systemd, пофик, шо то грузится 45 секунд, шо то... Куль посеял, куль собрал, ниче не потерял.
Поттеринговские советы смотрел?
Вдруг пара дельных идей к твоей системе подойдут.
Обновился, вообще с сустемд не взлетело, пришлось обычным инитом запускать. Материлось на консоль-кит, и ещё на чёт там. Разбиратся влом, пускай лучьше старый добрый инит будет...
Вот то же самое у меня!
С initscripts 35 секунд до десктопа, с systemd 35 секунд. Где скорость, я не нашел! Перешел обратно на initscripts, ибо они удобнее в разы.
Пока замаскировал. Интересно, сколько еще дистром можно будет пользоваться, пока все зависимости не перепишут?ЗЫж А жаль, хороший был дистр, правильный. RIP.
>ЗЫж А жаль, хороший был дистр, правильный. RIP.А куда они денутся с подводной лодки? udev - часть systemd и всё больше от него зависит. Недавно убрали поддержку /lib/udev/devices/ Не говоря уж про ConsoleKit, который по сути похоронен. Ещё немного, и его поддержку выпилят из PolicyKit. Короче, я не завидую тем, кто захочет остаться без systemd. Во фряхе, кстати, тоже скоро вылезут аналогичные проблемы.
>А куда они денутся с подводной лодки? udev - часть systemd и всё больше от него зависит. Недавно убрали поддержку /lib/udev/devices/ Не говоря уж про ConsoleKit, который по сути похоронен. Ещё немного, и его поддержку выпилят из PolicyKit. Короче, я не завидую тем, кто захочет остаться без systemd.Во, а кто-то говорил, что в линухах нет vendor lock-in, а не деле выходит, что RH имеет линуксоидов, как хочет.
>Во фряхе, кстати, тоже скоро вылезут аналогичные проблемы.
А вот про это, пожалуйста, по-подробнее.
> Во, а кто-то говорил, что в линухах нет vendor lock-in, а не
> деле выходит, что RH имеет линуксоидов, как хочет.Ну так ни кто же не мешает форкнуть весь этот зоопарк.
> А вот про это, пожалуйста, по-подробнее.Из-за consolekit же. От него зависит PolicyKit, от которого, в свою очередь, зависит много чего, включая kde. Ну а дальше идём сюда \url{http://www.freedesktop.org/wiki/Software/ConsoleKit} Пока рекомендуется использовать вместо него systemd-loginctl. Через полгода, думаю, поддержку ConsoleKit выкинут окончательно из всех проектов. Придётся или форкать, или портировать systemd на фрю.
> Из-за consolekit же. От него зависит PolicyKit, от которого, в свою очередь…тоже надо избавляться. не имею этих «китов» и живу довольный.
>>А куда они денутся с подводной лодки? udev - часть systemd и всё больше от него зависит. Недавно убрали поддержку /lib/udev/devices/ Не говоря уж про ConsoleKit, который по сути похоронен. Ещё немного, и его поддержку выпилят из PolicyKit. Короче, я не завидую тем, кто захочет остаться без systemd.
> Во, а кто-то говорил, что в линухах нет vendor lock-in, а не
> деле выходит, что RH имеет линуксоидов, как хочет.Коммерческие компании полностью контролируют дерево Open Source. Отдельные листочки их мало волнуют — опадут в ближайшую осень или зимой.
>>Во фряхе, кстати, тоже скоро вылезут аналогичные проблемы.
> А вот про это, пожалуйста, по-подробнее.Open Source завязан на ядро Linux. Системное окружение GNU можно заменить, но оно мало что решает в пользовательских программах "переднего плана". А основная ценность — именно программы переднего плана и графическое окружение. Они-то как раз сейчас полностью завязаны на интерфейсы. Началось всё с HAL/PolicyKit, а закончится через SystemD, в конечной стадии окольцевания Open Source, — ядром Linux. Хороший такой "кактус в горшочке": удобен в уходе и не требует частого полива от проприерастов. Сам не чахнет и другим проектам свободного стека развиваться не даёт (человеческие программистские ресурсы ограничены же). :) Ну вот и жрите что дают. Я предупреждал.
>[оверквотинг удален]
>> А вот про это, пожалуйста, по-подробнее.
> Open Source завязан на ядро Linux. Системное окружение GNU можно заменить, но
> оно мало что решает в пользовательских программах "переднего плана". А основная
> ценность — именно программы переднего плана и графическое окружение. Они-то как
> раз сейчас полностью завязаны на интерфейсы. Началось всё с HAL/PolicyKit, а
> закончится через SystemD, в конечной стадии окольцевания Open Source, — ядром
> Linux. Хороший такой "кактус в горшочке": удобен в уходе и не
> требует частого полива от проприерастов. Сам не чахнет и другим проектам
> свободного стека развиваться не даёт (человеческие программистские ресурсы ограничены
> же). :) Ну вот и жрите что дают. Я предупреждал.Мля!!! Да форкни ты HAL, PolicyKit и т.д. Кто тебе мешает то? Тебя расстреляют что ли из-за того что ты себе репозитарий исходников скачаешь? Ты ж там вроде крутой джабист, вот и напиши на своей джаве аналог systemd... только боюсь им никто пользоваться не будет
В этом то и весь смысл, что форкнуть может каждый, а вести процесс разработки -- только корпорация и подконтрольное ей стадо программеров.
> В этом то и весь смысл, что форкнуть может каждый, а вести
> процесс разработки -- только корпорация и подконтрольное ей стадо программеров.(задумчиво) а что такое надо, например, активно разрабатывать в udev? вот я уже год, что ли, его не обновлял -- и всё работает. ЧЯДНТ?
> Мля!!! Да форкни ты HAL, PolicyKit и т.д. Кто тебе мешает то?А кто форкнет последующие версии GNOME, KDE и Xfce, которые не_откажутся от работы с HAL и PolicyKit, ты что ли?
> Тебя расстреляют что ли из-за того что ты себе репозитарий исходников скачаешь?
Прогресс неумолим. И на одних оставшихся исходниках от сегодняшнего числа завтра далеко не уедешь.
> Ты ж там вроде крутой джабист, вот и напиши на своей джаве аналог systemd... только боюсь им никто пользоваться не будет
Вот именно. В тренд не попадаешь — вылетаешь.
> Прогресс неумолим. И на одних оставшихся исходниках от сегодняшнего числа завтра далеко
> не уедешь.вот странно. а у меня вот исходники 20-летней давности отлично компилируются и работают. ЧЯДНТ?
> Прогресс неумолим. И на одних оставшихся исходниках от сегодняшнего числа завтра далеко не уедешь.Совет "форкнуть" явно ведь не означал просто форкнуть и дальше ничего не делать. Форкнуть и развивать, естественно. А так то, изя, конечно если просто импортировать себе репозитарий, то конечно далеко не уедешь
И что? Пока ты только ноешь ничего не изменится.
> Open Source завязан на ядро Linuxпорадовал старика поутру. «opennet — клоуны на любой вкус!»
> порадовал старика поутру. «opennet — клоуны на любой вкус!»Ну так это же изен :)
Традиционно проблем не видим. Изен правильно говорит. GNU/Linux становится синонимом демократии. Машем флагом свободы.. не.. не так.. СВОБОДЫ.. и с радостью и любовью посасываем за собственный труд.
ну посасывайте, у вас же это основная цель. проецировать только зачем?
> Во, а кто-то говорил, что в линухах нет vendor lock-in, а не
> деле выходит, что RH имеет линуксоидов, как хочет.А на деле выходит, что твоего мозга не хватает на то, чтобы понять что такое vendor lock-in, но устоять перед использованием модного иностранного словечка всё-таки выше твоих сил ;-)
Если кому-то хочется поддерживать устаревший набор костылей, то флаг им в руки - никакого lock-in нет, не было и не предвидется.
на деле выходит что менеджеры красной шапки промыли твои мозги и рассказали что это все круто, современно и новомодно. А всякие ретрограды не нужны.vendor lock-in что все больше решений от одного вендора, и они все более сложные - которые развивать может только этот вендор.. Этим вендором становится Шапка - А ты этого не видишь...
Купи уже словарь и прочти что такое vendor lock-in.
Может хоть тогда перестанешь быть всеобщим посмешищем.
> Купи уже словарь и прочти что такое vendor lock-in.
> Может хоть тогда перестанешь быть всеобщим посмешищем.«Vendor lock-in» (также «proprietary lock-in», «customer lock-in», «привязка к поставщику», «замыкание на одном поставщике», «барьер для смены поставщика»), в экономике — зависимость потребителя от продуктов и сервисов одного поставщика, невозможность сменить поставщика из‑за высоких затрат на переход.
Ты тут видишь хоть одно слово про закрытые или открытые решения. Или видишь слова форкни и шморкни.
Хотя и ранее была шапка и прочие, клянчащие и питающиеся объедками со стола шляпы.
Гыыыы... Не нравится RH? Поставь себе Ubuntu, Debian, Arch или Crux какой-нибудь и никакого vendor lock-in! :)
> Гыыыы... Не нравится RH? Поставь себе Ubuntu, Debian, Arch или Crux какой-нибудь
> и никакого vendor lock-in! :)RH как был, так и останется - просто сменится вывеска на Ubuntu, Debian, Arch или Crux. А vendor lock-in не пропал. Напоминает работу фокусника в цирке. RH к которому примотали юнити - это Ubuntu. И чем таким известен Arch? У него то и юнити своего нет.
> которые развивать может только этот вендорВам кто-то исходники не даёт?
А время и силы на это всё кто даст? И что из этого получится? Очередной болженос, который еле тянут полтора землекопа и который никому не нужен ни на сервере ни на десктопе как и десятки этих самых болженосов с дистровотча?Так что никуда уже не деться, линукс -- такая же проприетарщина как и венда, только с другой парадигмой владения.
Из Педивикии "невозможность сменить поставщика из‑за высоких затрат на переход". Т.е. проще выпилить этот ваш люн^W Arch нафик. И установить православную Fre^W Слаку.
> Во, а кто-то говорил, что в линухах нет vendor lock-in, а не
> деле выходит, что RH имеет линуксоидов, как хочет.С glibc уже доимелись...
> С glibc уже доимелись...а что такого страшного произошло с glibc? ну, кроме того, что криворукие быдлокодеры развели хай на все интернеты.
> Короче, я не завидую тем, кто захочет
> остаться без systemd. Во фряхе, кстати, тоже скоро вылезут аналогичные проблемы.Глупость и нежелание работать вообще редко проходят без последствий, так что всё вполне ожидаемо :)
>> Короче, я не завидую тем, кто захочет
>> остаться без systemd. Во фряхе, кстати, тоже скоро вылезут аналогичные проблемы.
> Глупость и нежелание работать вообще редко проходят без последствий, так что всё вполне ожидаемо :)Фрейморк systemd создан из желаний и возможностей Red Hat усовершенствовать ТОЛЬКО ядро Linux, заменив кроссплатформенные механизмы нотификации HAL/PolicyKit/ConsoleKit (кстати, созданные тоже в недрах RH).
После того, как на этот фреймворк ядра Linux перейдут все остальные независимые разработчики, которые захотят (а они захотят — никуда не денутся) использовать Linux для своих графических оболочек и программ, то разработчикам других ОС ничего не остаётся, как написать нечто совместимое по API и вызовам с этим линуксовым фремворком С_НУЛЯ. А значит, в FreeBSD, например, модуль linux.ko будет вынужденно переработан с целью поддержания ЧУЖИХ фич. В реализации OpenSolaris появится аналогичная эмуляция _линуксовой_системы_нотификации_. Определённо, разработчки приложений получат преимущество в виде написания кода только для одной операционной системы — GNI/Linux с минимальными трудозатратами на другие свободные (и не очень) *nix ОС.
Но на всё это нужно время. 3 или 5 лет по адаптации системного фреймворка Linux в другие системы. Хватит ли терпения у разработчиков бороться с сырым фреймворком с нестабильным API/ABI (как это водится в Linux) на первых порах — большой вопрос. Но на десктопах альтернативные *nix в это время будут точно сливать "свободному" GNU/Linux. Именно _В_ПРИКЛАДНЫХ_ интерактивных аспектах использования, в графическом пользовательском окружении другим *nix ничего не светит. По крайней мере сейчас не видно света в конце тоннеля жизненного цикла альтернативных *nix на десктопах.
Ну а что же Linux в ближайшие 3-5 лет, как себя будет чувствовать? Почивать на лаврах и жиреть, естественно. А потом неожиданно systemd перестанет нуждаться в толстом и неповоротливом собрате. :))
>ко-ко-ко бсд против прогресса, потому что не успевает за нимНе хочешь ли ты заставить высококлассных разработчиков вместо добавления новых фич заниматься поддержкой некрофилов и их систем, к тому же еще бесплатно?
> высококлассныхЗа последние десять лет эти "высококлассные" разработчики добавили много новых фич.
НО! За последние десять лет эти "высококлассные" разработчики добавили мало полезных фич.Про освоение процессорных мощностей и объёмов оперативки уже и говорить не приходится...
Хм, я вот сижу в генте и радуюсь наличию флагов - udev был из коробки, dbus нужен для нужных программ, а consolekit, policykit, udisks и прочие абстракции у меня выпилены из зависимостей других программ. Неужели придется запиливать все эти сложности. Практика показывает - чем меньше этих абстракций, тем лучше и стабильней работает моя ОС =)
>consolekit, policykit, udisks и прочие абстракции у меня выпиленыИ на компьюете 1 пользователь? (не считая root и системных)
> И на компьюете 1 пользователь? (не считая root и системных)наверное, именно поэтому компьютер и называется «персональный», нет?
нет
> нетвау. а почему?
>>consolekit, policykit, udisks и прочие абстракции у меня выпилены
> И на компьюете 1 пользователь? (не считая root и системных)Эм... ну вообще-то юниксы были многопользовательскими когда *Kit еще и в проекте не было.
>>>consolekit, policykit, udisks и прочие абстракции у меня выпилены
>> И на компьюете 1 пользователь? (не считая root и системных)
> Эм... ну вообще-то юниксы были многопользовательскимиИстория нам говорит о другом.
//--
Название Unix связана с шуткой одного из коллег Томпсона: новая операционная система поддерживает только одного пользователя (собственно, Томпсона), и он рассматривал её как выхолощенную версию Multics - потому и нарёк новую операционную систему "Un-multiplexed Information and Computing Service".
--//
http://mydebianblog.blogspot.com/2012/02/unix.html
> этих абстракций, тем лучше и стабильней работает моя ОС =)Ой ли ? вы (без обид) считаете себя умнее тех, кто собирал ваш дистрибутив ?
Может система работает менее стабильно, но вы себя упорно заставляете верить что - более стабильно :) ?
И потом что дало выпиливание - сколько секунд загрузки выиграли, на сколько снизилась нагрузка на процессор и память ?
И что стало с юзабилити - не снизился ли комфорт работы с ос ?
ЗЫ: под комфортом я понимаю то, что при вытыкании новой флешки она сама монтируется с нужной кодировкой, а не "mount -t...так какя фс ? какое устройство, так ага.... mount -t xfs -o user,rw /dev/sdc1 /mnt/... так щас...mdkir /mnt/usb-xfs; chmod a+rwx /mnt/usb-xfs..."
> считаете себя умнее тех, кто собирал ваш дистрибутив ?Ещё раз: это гента.
Ну, те у кого включен testing уже пару дней как на systemd-tools перешли.
Обновился, все нормально работает.
Давайте все пакеты смерджим в один пакет archlinux
Поттеринги таки сумели на^Wобмануть. При "слиянии проектов systemd и udev" как-то так получилось, что для сборки udev подтянулись все зависимости systemd и udev теперь невозможно собрать без systemd.
> Поттеринги таки сумели на^Wобмануть. При "слиянии проектов systemd и udev" как-то так
> получилось, что для сборки udev подтянулись все зависимости systemd и udev
> теперь невозможно собрать без systemd.udev по-прежнему можно *использовать* без systemd, хотя собирается он как один из компонентов systemd. Технически, это "проблема" - больше для всяких извр^Wгентушников^W source-based дистрибутивов и "самоделкиных".
Как задумывали - так и получилось. Никто иного и не обещал, так что в общем - все честно. Хотя в целом такая интеграция не радует.
всякие самоделкины уже давно опробовали продукт Поттеринга, так как не вынуждены ждать, когда же майнтейнеры соизволят собрать этот пакет, и поэтому имеют свое определенное мнение о все плюсах и минусах systemd и пр.
> всякие самоделкины уже давно опробовали продукт Поттеринга, так как не вынуждены ждать,
> когда же майнтейнеры соизволят собрать этот пакетЧто, и ebuild самоделкиным править не пришлось? Или не пришлось тащить зависимости systemd при сборке вручную udev?
PS: Школота такая школота: плюсомет она осиливает вперед навыков чтения уровня 3-го класса...
> Что, и ebuild самоделкиным править не пришлось?Зачем?
> Или не пришлось тащить зависимости systemd при сборке вручную udev?Какие нахрен "зависимости systemd"? Какая "сборка вручную"?
>> Что, и ebuild самоделкиным править не пришлось?
> Зачем?Затем, что для интегрированного в systemd udev - сборка будет происходить совершенно иначе. Сюрприз! А мейнтейнеры, по вашим же словам - пакет для вас еще не собрали. Т.е. ebuild модифицировать таки придется именно вам. Теперь логическая цепочка для вас доступна?
>> Или не пришлось тащить зависимости systemd при сборке вручную udev?
> Какие нахрен "зависимости systemd"? Какая "сборка вручную"?Такая. Как я уже сказал выше - стоит научиться читать, прежде чем писать ответ.
Я, вообще-то, про то, что ебилд для systemd был доступен аж полтора года назад, и все, кто хотел, уже сумели оценить сей продукт, а посему не испытывают никакой попоболи от каждой новости про systemd. Отвечал я Вам, уважаемый, только из-за вашего хамства в отношении source-based дистрибутивов. Причем, Вы, видимо, даже не представляете, как устроен тот же портаж. А ярлыки вешать каждый способен. Прошу заметить, я нигде не упоминал про сборку udev из исходников systemd: это Вы сами надумали. Так что учитесь читать сами.