После десяти месяцев разработки компания Red Hat представила (https://www.redhat.com/en/about/press-releases/red-hat-launc...) релиз дистрибутива Red Hat Enterprise Linux 6.9 (https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enter...). RHEL 6.9 является первым выпуском, подготовленным в рамках второй стадии сопровождения, на которой приоритеты сместились в сторону исправления ошибок и проблем безопасности, с внесением незначительных улучшений, связанных с поддержкой важных аппаратных систем. Включение значительных функциональных улучшений прекращено. Ветка RHEL 6.x развивается параллельно с веткой RHEL 7.x и будет поддерживаться (https://access.redhat.com/support/policy/updates/errata) до 30 ноября 2020 года. Установочные образы RHEL 6.9 доступны (https://access.redhat.com/downloads/) для загрузки только зарегистрированным пользователям Red Hat Network (RHN).Ключевые изменения (https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...) в Red Hat Enterprise Linux 6.9:
- Проведена большая чистка устаревших алгоритмов и протоколов, безопасность которых поставлена под сомнение. В том числе блокированы алгоритмы, фигурирующие в таких атаках как DROWN (https://www.opennet.me/opennews/art.shtml?num=43971) против SSL 2.0, SLOTH (https://www.opennet.me/opennews/art.shtml?num=43649) против MD5, LOGJAM (https://www.opennet.me/opennews/art.shtml?num=42270) и FREAK (https://www.opennet.me/opennews/art.shtml?num=41782) против TLS.- Полностью удалена поддержка протокола SSLv2 и экспортных наборов шифров, включающих (https://www.opennet.me/opennews/art.shtml?num=41782) недостаточно защищённые устаревшие алгоритмы шифрования;
- Ограничено использование MD5 и SHA-0 в качестве алгоритма для создания цифровых подписей;
- Запрещена установка защищённых соединений с сервером при использовании в TLS параметров DH (Diffie-Hellman), размером менее 1024 бит.
- Отключено использование RC4 в контекстах, не приводящих к проблемам с нарушением совместимости (например, RC4 отключен в OpenSSH);
- В OpenSSL, NSS, GnuTLS и vsftpd добавлена поддержка протокола TLS 1.2;
- В NetworkManager добавлена поддержка ручной настройки DNS (при указании dns=none в настройках NetworkManager, прекращается автоматическое изменение /etc/resolv.conf);
- В Perl-модулях Net::SSLeay (https://metacpan.org/release/Net-SSLeay) и IO::Socket::SSL (https://metacpan.org/release/IO-Socket-SSL) реализована возможность жесткого определения допустимой версии протокола TLS;- В состав включена утилита cpuid, выводящая информацию о возможностях CPU на основании данных, полученных через инструкцию CPUID;
URL: https://www.redhat.com/en/about/press-releases/red-hat-launc...
Новость: http://www.opennet.me/opennews/art.shtml?num=46233
УРА!
*побежал оформлять платную подписку.
Сколько за год стоит?
Для ценителей))):
RHEL Server:
Self-support $349
Standard (Physical or Virtual Nodes)$799
Premium (Physical or Virtual Nodes)$1299
SelfSupport - хороший вариант. Заплати 350 бачей за то, что будешь САМ её поддерживать ))
Это доступ к обновлениям и базе знаний. отличие от других уровней поддержки в том, что нельзя обращаться с вопросами по телефону и через support cases (с sla) на сайте. В лучшем случае сможешь написать в багзиллу без каких-либо гарантий.
База знаний, кстати, так себе.
Гугл ее вполне себе заменяет
Кстати, а как в Редхате с PRоделками Поттеринга? Энтерпрайз типа, все дела. Тоже перевели всех и вся? Спрашиваю чисто интереса ради как юзер Дебьяна, который до сих пор не может прийти в себя от старого-доброго дистриба, известного всем своей "мамонтностью" и стабильностью и резко сменивший курс.
Объясните, пожалуйста, чем так плох systemd? По пунктам, аргументированно.
> Объясните, пожалуйста, чем так плох systemd? По пунктам, аргументированно.
Там вроде нет других причин кроме отсутствия гибкости
а это мало ?
Можете посмотреть багзилу - и количество критических багов там.
> Объясните, пожалуйста, чем так плох systemd? По пунктам, аргументированно.Объясняю: плох не s-d, а принудительная смена ориентации Debian-а.
одменов захотели сделать взаимозаменяемыми, чтоб новому одмену не пришлось изучать мэд-скилзы уволенного => одменам не дали пописать на коленке баш-скрипты, заменив это дело серьезной инфраструктурой, когда новому одмену нужны уже не месяцы, а часы, чтобы изучить, че там как устроено у клиента после прошлого (уволенного) одмена.Вот одмены и бушуют. Лично меня как юзера десктопный системдэ полностью устраивает. Это как с эволюционизмом: в научном мире уже никто не будет оспаривать эволюционизм, будут лишь потихоньку уточнять какие-то вещи внутри эволюционизма. Системдэ -- то же самое. Если есть проблемы с системдэ -- это не повод сносить ее полностью. Это повод чутка улучшить системдэ.
Претензии к systemd делятся на две части - объективная критика кода и архитектуры (а там действительно многое через задницу сделано), и упомянутая боль сзади у "veteran sysadmins".Задача, которую решает systemd, давно назрела, и ее надо решать. Само же предлагаемое решение весьма сомнительно. Было бы лучше сначала довести его до ума, а уже потом пропихивать во все дистрибутивы. Еще лучше было бы решить парочку родовых проблем в целом весьма неплохого upstart, а не изобретать велосипед.
> Задача, которую решает systemd, давно назрела, и ее надо решать.И Вас ведь не затруднит её озвучить, задачу эту?
Главное что есть у systemd или у svc в Солярисе, но чего нег у SysV init, это удержание ожидаемого состояния системы.Запущен ли сервис? Отключен или упал в процессе? Почему не стартовал сервис? Как предотвратить запуск сервиса в категорически неподходящей обстановке, чтоб он ничего не поломал (например чтоб ничего не писал в /whatever, покуда туда не примонтировалось то что должно)?
Это настолько очевидные вещи, что спрашивать о них может только человек ни разу не поддерживавший сколько-нибудь значительный парк серверов.
> Главное что есть у systemd или у svc в Солярисе, но чего
> нег у SysV init, это удержание ожидаемого состояния системы.Ага, потому что init это не менеджер сервисов. Менеджер сервисов это supervisord, monit и т.п.
monit это костыль. Возникший из-за угребищности sysV init и не решающий все задачи. А так да.
> Запущен ли сервис? Отключен или упал в процессе? Почему не стартовал сервис?
> Как предотвратить запуск сервиса в категорически неподходящей обстановке, чтоб он ничего
> не поломал (например чтоб ничего не писал в /whatever, покуда туда
> не примонтировалось то что должно)?Это всё делается коротким [ba]sh-скриптом в runit-е (или daemontools-е, или любом из других его идейных отпрысков), который [ВНИМАНИЕ! Это сложно, сосредоточьтесь1] короче соответствующей _простыни_ юнить-его-фейлов. :-P
http://jdebp.eu/FGA/run-scripts-and-service-units-side-by-si...
Это давно решённая проблема:
"TL;DR: Use runit; skip to “This is a Solved Problem” and “Additional Resources” sections at the end of this post."http://jtimberman.housepub.org/blog/2012/12/29/process-super.../
> Это настолько очевидные вещи, что спрашивать о них может только человек ни
> разу не поддерживавший сколько-нибудь значительный парк серверов.
Если обобщить - то сервисы как first class objects.
> Если обобщить - то сервисы как first class objects.Так systemd - это, оказывается, язык программирования? :)
Нет, я понимаю. Чем туманнее сформулирована задача, тем веселее её решать. Так держать, молодцы.
> Нет, я понимаю. Чем туманнее сформулирована задача, тем веселее её решать. Так
> держать, молодцы.Нет, это кто-то за деревьями не видит леса.
> это кто-то за деревьями не видит леса.К сожалению, деревьев действительно целый лес.
Объекты бывают не только в языках программирования.В Sun-овских презентациях SMF все это было очень подробно расписано, советую поискать.
> Объекты бывают не только в языках программирования.Объекты-то бывают, а вот объекты первого класса - это вполне определённое понятие, специфичное только для языков программирования.
>> Задача, которую решает systemd, давно назрела, и ее надо решать.
> И Вас ведь не затруднит её озвучить, задачу эту?Как можно более ускорить старт виртуальных инстансов на ноде, не дожидаясь, пока на самой физической машине прочихаются все сервисы. Примерно так, если исходить их того, какую фнукциональность подпихивают в systemd.
Лично меня как юзера десктопный sysvinit полностью устраивает. Это как с эволюционизмом: в научном мире уже никто не будет оспаривать эволюционизм, будут лишь потихоньку уточнять какие-то вещи внутри эволюционизма. sysvinit -- то же самое. Если есть проблемы с sysvinit -- это не повод сносить его полностью. Это повод чутка улучшить sysvinit.P.S. ну и да, горит по большей части вовсе не у админов. Или вы и впрямь считаете, что основная масса работы админа - настройка и написание логики для системы инициализации на серверах? Ну бредовый же аргумент, честное слово.
> Объясните, пожалуйста, чем так плох systemd? По пунктам, аргументированно.Знаете, если хотите почитать об этом, зайдите в любую новость об очередном релизе systemd и посмотрите комментарии.
Не подумайте, я Вас не посылаю: просто постоянно вылезают всякие с этим вопросом, а потом пропускают мимо ушей абсолютно всю аргументацию и начинают срaч. В 2014м это ещё казалось забавным, но сейчас уже порядком поднадоело.
> В 2014м это ещё казалось забавным, но сейчас уже порядком поднадоело.Ни тогда, ни сейчас, аргументы про "плохость" systemd не блистали ясностью и непротиворечивостью.
И тогда, и сейчас, аргументы за SysV init всегда основой имеют "так делали деды", и забывается, что в последнее "досистемдэшное" время обычный sysvinit был заменен на openrc или upstart в основных дистрибутивах, потому что у разработчиков назрела необходимость менять сам подход к понятию системного менеджера.
>> потому что у разработчиков назрела необходимость менять сам подход к понятию системного менеджера.Вся трабла в том, что разработчики просили инит, а им системный менеджер вкорячили.
>> В 2014м это ещё казалось забавным, но сейчас уже порядком поднадоело.
> Ни тогда, ни сейчас, аргументы про "плохость" systemd не блистали ясностью и
> непротиворечивостью.Что неясно? Какие противоречия? Голословно!
> И тогда, и сейчас, аргументы за SysV init всегда основой имеют "так
> делали деды", и забывается, что в последнее "досистемдэшное" время обычный sysvinit
> был заменен на openrc или upstart в основных дистрибутивах, потому что
> у разработчиков назрела необходимость менять сам подход к понятию системного менеджера.Классно ты умеешь с соломенными чучелами сражаться.
>> В 2014м это ещё казалось забавным, но сейчас уже порядком поднадоело.
> Ни тогда, ни сейчас, аргументы про "плохость" systemd не блистали ясностью и непротиворечивостью.Да-да-да. Сколько вам ни объясняй, всё равно вам "ничего не понятно", и как следствие этого, вы там додумываете про себя всякой чуши, и заявляете "вы сами себе противоречите". :)
В общем, дело обстоит так: спорить с деревом бесполезно. Растите себе на здоровье.
> И тогда, и сейчас, аргументы за SysV init всегда основой имеют "так
> делали деды", и забывается, что в последнее "досистемдэшное" время обычный sysvinit
> был заменен на openrc или upstart в основных дистрибутивах, потому что
> у разработчиков назрела необходимость менять сам подход к понятию системного менеджера.Если основные для Вас дистрибутивы в "досистемдэшное" время - это Ubuntu, Fedora и Gentoo (я вроде перечислил все дистрибутивы, где вышеназванные системы были приняты по дефолту), я могу Вам только посочувствовать.
А Вами как-то забывается, что вся критика sysvinit, которой Вы располагаете, относится к варианту sysv, который был в RHEL, но не имеет никакого отношения к распараллеленному sysvinit с зависимостями, который, внезапно, существовал в Debian ещё до того, как systemd начали писать.
> А Вами как-то забывается, что вся критика sysvinit, которой Вы располагаете, относится
> к варианту sysv, который был в RHEL, но не имеет никакого
> отношения к распараллеленному sysvinit с зависимостями, который, внезапно, существовал
> в Debian ещё до того, как systemd начали писать.Там глобальный недостаток. Этот код не принадлежит RedHat.
> Объясните, пожалуйста, чем так плох systemd?Для мну все решило неудобное руление из консольки. То less всюду подставляет, то километровые ключи вводить требует, то приходится извращаться чтобы логи почитать. Нельзя делать такие неудобные программы.
> Объясните, пожалуйста, чем так плох systemd? По пунктам, аргументированно.Пункт первый:
Перлы в коде, типа магических строк и прочего:
arg_header = strdup(option+7);strcpy(stpcpy(stpcpy(stpcpy(mempcpy(t, p, fn - p), ".#"), extra), fn), «XXXXXX»);
if (path_is_absolute(option+15))
ret = new(char, (e - slice) + 1 + strlen(name) + 6 + 1);
strcpy(mempcpy(mempcpy(r, f, a + 1), i, b), e);
static int env_append(char **r, char ***k, char **a) {
char **strv_env_unset(char **l, const char *p) {
char **strv_env_set(char **x, const char *p) {
там еще есть интересный пунктик с проверками входных данных - они довольно бессистемны и дубли-"триплируются".
Т.е. классичесая проверка входящего аргумента, потом с этим аргументом вызывается еще что-то, что проверя свои входные данные тем же макаром, потом все это дело парсится, при этом повторяя как минимум часть кода из проверок. Результат используется только частично и только "на месте" и чуть видоизмененный (а иногда и не чуть, а скопипащенный) парсинг проводится в следующем вызове. Хотя казалось бы, разбери один раз, с нормальной проверкой и передавай что-то типа "parsed data struct".
В общем, самосборочный велосипед парсера в действии. Со всеми "вытекающими":
http://www.openwall.com/lists/oss-security/2016/09/28/9
> systemd v209+: local denial-of-service attack
> systemd[1] fails an assertion in manager_invoke_notify_message[2] when a zero-length message is received over its notification socketНамек на второй пункт претензий:
https://www1.opennet.ru/opennews/art.shtml?num=41301
> В Systemd добавлен код для разбора формата JSON
> В дополнение к уже присутствующей поддержке формата XMLПро классику типа QR кодов и встроенного httpd скромно умолчим.
Третий:
https://lists.freedesktop.org/archives/systemd-devel/2016-Fe...
> * Most configurable timeouts in systemd now expect an argument of "infinity" to turn them off, instead of "0" as before.А чтобы жизнь медом не казалась
> To maintain backwards compatibility, "0" continues to turn off previously existing timeout settingsили
https://lwn.net/Articles/490413/
> you can still build it for usage outside of systemd systems, and we will support these builds
> officially. In fact, we will be supporting this for a long timeДа, лонг-тайм оказался периодом аж в два года.
Или очередной велосипедизм с элементами гвоздеприбивания колес:
https://lists.freedesktop.org/archives/systemd-devel/2015-Fe...
> When the user presses Ctrl-Alt-Del more than 7x within 2s an immediate reboot is triggered.
>Хотя в принципе, в долгосрочной перспективе достаточно и первых двух – монстр, которого очень тяжело поддерживать, как-то не является пределом мечтаний. А уж с таким глав-разработчиком …
"Читал я. Мелкие нападки
На шрифт, виньетки, опечатки,
Намеки тонкие на то,
Чего не ведает никто."
А что, одмены или юзеры частенько встречаются с проблемой того, что упоминаются некие option+15? Нет конечно. Ты привел программистские проблемы = проблемы сопровождения самой системды, с которыми не сталкивается никто, кроме коммитеров в системду. Если там заменить option+15 на вменяемые конструкции, ты успокоишься? Нет конечно, пойдешь и будешь дальше разоблачать системду, находя то тут, то нам "а вон здесь не оставили пустую строчку после ифа, код не красив".
> А что, одмены или юзеры частенько встречаются с проблемой того, что упоминаются некие option+15?Нет конечно. Но когда встречаются, приходится в срочном (читай: часы, а не недели) порядке обновлять парк систем и надеяться, что никакая зараза не успела проникнуть через этот option+15.
> Но когда встречаются, приходится в срочном (читай: часы, а не недели) порядке обновлять парк систем и надеяться, что никакая зараза не успела проникнуть через этот option+15.Помню, когда на горе свистнул рак (это пришлось аккурат к греческим календам), одна из зараз проникла "через этот option+15", и мне пришлось "в срочном (читай: часы, а не недели) порядке обновлять парк систем". Это было уже после Второго пришествия.
"некрасивый" код ведет за собой вполне красивые дыры. На одну из них тебе даже ссылку человек дал.systemd запущен в широкое использование сомнительными людьми, с сомнительными целями, без достаточной в нем необходимости и с жестким попранием альтернатив.
Я более чем уверен, что после смерти (дай Бог, не скорой) Линуса Торвальдса, Столмана и еще горстки "древних монстров", "линуксы" прогнут под корпорации. И без блобов ничего работать не будет в принципе. Как это уже сейчас на половине систем не работает.
> "некрасивый" код ведет за собой вполне красивые дыры. На одну из них
> тебе даже ссылку человек дал.Дыры бывают и при вполне красивом коде. Даже у (дай Бог, пусть Он проживет еще долго) Линуса Торвальдса.
> systemd запущен в широкое использование сомнительными людьми, с сомнительными целями,
> без достаточной в нем необходимости и с жестким попранием альтернатив.Системда идеальна для корпоративной среды. По причинам, которые уже указаны выше. Бизнесу необходимо, чтобы ни один из сотрудников не был незаменимым.
> Я более чем уверен, что после смерти (дай Бог, не скорой) Линуса
> Торвальдса, Столмана и еще горстки "древних монстров", "линуксы" прогнут под корпорации.
> И без блобов ничего работать не будет в принципе. Как это
> уже сейчас на половине систем не работает.Не понимаю, при чем тут системда. Там есть какие-то блобы? Нет конечно. У критиков системды частенько бывают кажущиеся им логически верными заносы вроде "если установим системду, линус умрет, а корпорации внедрят блобы".
>Ты привел программистские проблемыНет.
Во-первых, многочисленные примеры быдлoкода свидетельствуют о больших организационных проблемах в проекте. Нельзя ставить самовлюбленных похапешников кодить на сях - в долгосрочной перспективе это может очень печально закончиться. Да что там в долгосрочной - от релиза к релизу каждый раз очередную инновацию переделывают по желанию левой пятки. А это уже не программистские проблемы, и твой собеседник далее приводит именно такие примеры пользовательских проблем. Это во-вторых.
Но ты, конечно, можешь и дальше фокусироваться на наиболее удобных тебе аргументах, закрывая глаза на все остальные.Плохой демагог, плохой!
> многочисленные примеры быдлoкодаПосле усиленного изучения исходных кодов системды, Аноним привел всего 10 примеров "6ыдлокода". Учитывая, что исходники системды уже объемнее исходников ядра, не совсем, чтобы это были "многочисленные" примеры "6ыдлокода". Единичные - да. Написанные на скорую руку - да. Поддается исправлению - да. Является поводом отказаться от системды - нет.
>После усиленного изучения исходных кодовЧто за бессовестное передергивание? С чего ты взял, что изучение было "усиленным"?
Остальную часть его поста ты так и будешь продолжать игнорировать?Плохой демагог, плохой! [2]
С того, что эти куски кода копируются из темы в тему, лишь изредка при этом пополняясь новыми пунктами.
1) Почему же до сих пор никто не исправил тогда?
2) Сколько пунктов необходимо, чтобы убедить тебя? 100? 1000? 1000000? Какой смысл приводить столько примеров в риторических целях?
3) То, что список копируется из темы в тему (что еще необходимо проверить и подтвердить, но мне лень и бремя доказательства не на мне) еще не означает, что анализ кода был "усиленным". Ну либо приведи логическую цепочку, как именно из этой предпосылки ты пришел к такому выводу.
> Почему же до сих пор никто не исправил тогда?Возможно, потому что никто не обратил на них внимание самих разработчиков.
> Сколько пунктов необходимо, чтобы убедить тебя? 100? 1000? 1000000?
Думаю, для обоснования __тотальной__ __замены__ системды на что-то иное понадобится четырехзначное число подобных (мелочных) пунктов. Мы же о __тотальной__ замене говорим?
> бремя доказательства не на мне
А ты загугли эти куски с кавычками. Повсюду в результатах будет опеннет.
> не означает, что анализ кода был "усиленным"
Я понимаю, что тебе очень хочется убедить всех, что ты открыл первый попавшийся файл и тут же (без всяких усилий) нашел сдесяток option+15. А знаешь что? Давай проведем эксперимент. Прямо сейчас ты -- без всяких усилий -- возьмешь и приведешь еще 10 сомнительных строк. Таких, чтоб они не гуглились со ссылкой на опеннет. Будем считать временем начала твоих поисков 14:47 MSK (ты же не сразу прочитаешь этот коммент - даю тебе фору в 15 мин)
Первый попавшийся файл:
https://github.com/systemd/systemd/blob/master/src/libsystem...Дублирующиеся магические строчки: 329 и 337, 443 и 451, 850 883 и 908.
Хардкода столько, что я даже не буду начинать перечислять.
Практически все переменные - однобуквенные и совершенно непонятные (я честно не могу понять, почему, например, на 850 результат процедуры get_files_in_directory записывается в переменную, названную r).
Брезгует фигурными скобками, никакой последовательности в стиле. Особенно феерично смотрятся строки 832 и 833.
Странное разделение всех объявленных процедур на _public_ и static - опять же, бардак в стиле (ну обозвал бы _private_, раз на родное похапе так тянет, хоть бы выглядело однородно).Там еще подключается файл macro.h - вот там тоже много веселья, у меня даже глаза разбегаются:
https://github.com/systemd/systemd/blob/master/src/basic/mac...На 238 пушка просто: /* We override the glibc assert() here. */. Молодец, Леня!
В макросе на 323 ошибка: не учитывается знак минуса для отрицательных чисел (а они, судя по комментарию для соседнего макроса на стр. 313-316, ожидаются).
Опасный макрос на 333.
Какой-то ад на строках 335-361.
Опять же, непоследовательный стиль: где есть вертикальное выравнивание для \ в макросах, а где нет. Про однобуквенные переменные и абсолютно нечитабельные битовые хаки и начинать уже не хочется.Уверен, что есть и еще.
Плохой демагог. Очень плохой демагог!
> Дублирующиеся магические строчки: 329 и 337, 443 и 451, 850 883 и 908
> p = strappend("/run/systemd/sessions/", session);
> p = strappend("/run/systemd/sessions/", session);Правильно. Нужно было создать единую функцию strappendRunSystemdSessions. Зато не "магически" и не "дублируется". Даешь также функцию strappendRunSystemdSeats и так далее. И после этого код, конечно же, станет читабельнее.
> я честно не могу понять, почему, например, на 850 результат процедуры get_files_in_directory записывается в переменную, названную r
> результат
> r
> r[esult]Ну, видимо ты из тех, кто не использует i для счетчика, l для количества и т. д. Есть определенные символы, которые имеют однозначный смысл.
> Брезгует фигурными скобками
Это код-стайл такой. Аргументик-то так себе. Чисто вкусовщина. Как я и говорил выше, "а у вас пустая строчка после ифа отсутствует".
> На 238 пушка просто: /* We override the glibc assert() here. */. Молодец, Леня!
А теперь попробуй потратить более 10 секунд и попытайся ответить, зачем он был переопределен.
Слабо, очень слабо! Я ожидал что-нибудь типа option+15. А в ответ одни лишь "фигурная скобка стоит не там, пробел поставили не здесь, переменную назвали не так".
>А в ответ одни лишьНе одни лишь. Плохой демагог, ну.
Спорить дальше по конкретным пунктам смысла не вижу, поскольку вопрос стоял так: "усиленный" ли был код ревью, или странности можно накопать уже за полчаса поверхностного вглядывания? Ответ на вопрос: усилий прикладывать не нужно.Если есть, что ответить по существу по остальным аргументам - отвечайте на предыдущий большой пост второго анонимуса.
> странностиГоворим не о странностях, а о том, что исходники системды не вписываются в конкретно твой любимый кодстайл. Только и всего.
> усилий прикладывать не нужно
Разумеется, не нужно прикладывать усилия, чтобы обнаружить, что фломастер не того цвета/вкуса. Я просил треш вроде option+15, а ты за полчаса копаний сумел привести лишь "ой, у них там результат именован как r, а не result".
Все потому, что ты жонглируешь понятием "стиля" так, как тебе удобно. Вот и получается, что все вышеперечисленное - это у тебя всего лишь вопросы "стиля", а вот +15 - это да, другое совсем дело. Хотя при желании ты бы и +15 без проблем "стилем" назвал.Разумеется, спорить с таким невозможно и бессмысленно, потому что это сродни игре в догонялки с толстячком, который все время "в домике". Демагог по-прежнему плох.
> ты жонглируешь понятием "стиля" так, как тебе удобноТо есть то, что там фигурные скобки после else не поставлены - это не стиль, а что-то другое? Ну-ка подробнее с этого места.
> при желании ты бы и +15 без проблем "стилем" назвал.
Ни в коем случае. option+15 -- это треш, я ж тебе с самого начала сказал (при этом треш не настолько велик, чтобы полностью выбрасывать системду). А вот r вместо result - это просто мелкая придирочка. При этом складывается ощущение, что ты готов с легкостью расстаться с проектами, где употребляются односимвольные переменные -- выбрасывай тогда весь ГНУ/Линукс, раз такое дело.
> Демагог по-прежнему плох
Так улучшайся. Еще не все приемы демагогии ты заюзал. Еще есть, куда развиваться.
> i для счетчика, l для количества и т. д. Есть определенные символы, которые имеют однозначный смысл.Особенно l. Cразу вместе с I. В древних шрифтах. И конечно, для обозначения количества, а не длины.
Признавайся, на самом деле это такая проверка?
Если твой любимый шрифт заставляет тебя напрягаться, чтобы отличить i от I, I от l, а 0 от O - выбрасывай свой ШГ на помойку.
> А что, одмены или юзеры частенько встречаются с проблемой того, что упоминаются
> некие option+15? Нет конечно. Ты привел программистские проблемы = проблемы сопровождения
> самой системды, с которыми не сталкивается никто, кроме коммитеров в системду.Лишь были бы желуди, да?
Он не плох. Просто это опеннет, тут любят *bsd и не любят Поттеринга. Жалкая реальность не справится с мощью их веры.
ничем
В 6-й версии systemd нет. Надеюсь, к 2020-му можно будет перейти на Devuan.
Это вряд ли. Этот вышеотписавшийся "юзер Дебьяна" не сделал для Devuan ничегошеньки. Как и все остальные юзеры дебиана, горюющие на форуме про s-d, а сами не ударившие палец о палец.
> Это вряд ли. Этот вышеотписавшийся "юзер Дебьяна" не сделал для Devuan ничегошеньки.
> Как и все остальные юзеры дебиана, горюющие на форуме про s-d,
> а сами не ударившие палец о палец.Я, как бывший "юзер Дебьяна" сделал для дебиана очень много, а именно - перешёл на Slackware.
> Это вряд ли. Этот вышеотписавшийся "юзер Дебьяна" не сделал для Devuan ничегошеньки.а чего делать-то предлагается? Тщательно переписывать все новые и новые нагромождения systemd-зависимых поделок? Воистину, сизифов труд.
> Надеюсь, к 2020-му можно будет перейти на Devuan.Да вообще-то уже сейчас можно. Вы не смотрите, что он "Beta". Он таковым считается, пока окончательно выпиливание зависимостей на libsystemd0 не завершат. А так им вполне можно пользоваться. У меня основной системой стоит.
В Red Hat 6 используется upstart, в 7 - systemd.
> Кстати, а как в Редхате с PRоделками Поттеринга?Редхат вообще и есть автор поттерингаподелок.
> Кстати, а как в Редхате с PRоделками Поттеринга?так же. В смысле, без них скоро только embed останется, и то ненадолго.
У тебя уже udev отдельного нет, dbus нет, скоро сдохнет (или перейдет в разряд гну-фетишей, не обновляемых десятилетиями) куча всякой мелочи, которую теперь стильно-модно-молодежно иметь в виде systemd'шного модуля (acpi, к примеру, уже), и т.д.В общем-то в любой момент может (и непременно будет) изменяться поведение ядра так, что ты без этих чудес уже и не загрузишься вообще, как минимум, на стандартных архитектурах.
Про userland я уж молчу - начиная от модных DE, и, заканчивая, внезапно, старинным X.org, они тоже любят модные побрякушки.
> известного всем своей "мамонтностью" и стабильностью
это была не мамонтность и стабильность, а просто нежелание что-либо менять и думать головой - на чем и стоит весь дeбилл.ан.
Поэтому как только майнстрим развернулся в сторону сплошного плуг анд плюха, когда в системе автоматически и не спрашивая тебя, происходит какая-то невменяемая жизнь, когда ей, а не тебе, приспичило - у них особо и выбора не было. Поскулив и поиграв на прощание в демократию, выбрали то единственное, чем их кормят с лопаты - потому что ничего другого все равно не осилили бы. (не надо мне про devuan, мертворожденный выкидыш для слива пара)
А Мате в красной шапке есть?
Есть для el7 в EPEL.
когда будет выпуск CentOS 6.9 ?
Не понятно какие идиоты заминусовали это сообщение - ну да *** с ними.CentOS 6.9 сейчас находится в стадии рекомпиляции - возникли проблемы со сборкой 15 пакетов - работа ведётся. Релиз скоро будет.
// b.
Как только калькулятор единственного пользователя CentOS'а осилит пересобрать RHEL.
Второгном Жив!
RHN deprecated в пользу Red Hat customer portal (access.redhat.com).
Когда стоит ждать RHEL 8? Никаких движений пока не видно, хотя ветка RHEL 5 была выпущена 10 лет назад и скоро достигнет конца срока поддержки.
> RHEL 5 была выпущена 10 лет назад и скоро достигнет конца срока поддержки.А разве RHEL 5 ещё не прекратили поддерживать?
Может я чего-то недопонял, конечно, но вроде была новость:
http://www.opennet.me/opennews/art.shtml?num=46211
>> Может я чего-то недопонял, конечно, но вроде была новость:
>>>> будет прекращён 31 мартаТы явно что-то недопонял.
Применяя твои допущения, но с другой стороны, я делаю вывод, что до прекращения поддержки rhel5 осталось дней чуть ли не больше, чем поддерживается версия firefox или какой-нибудь убунты. Азазаза)
>>>>> будет прекращён 31 мартаАаа, вот оно что. Не досмотрел. Спасибо! :)
> Когда стоит ждать RHEL 8?Как только решат, ставить xfce или kde в дефолте. У меня есть подозрения, что gnome3 они больше в rhel не вкатят, плохой опыт rhel7
>Enterprise
>kde в дефолте
>red hat
>gnome3 больше не вкатятОх уж эти наивные сектанты.
Сектанты - это вы. Вот выкинут гном3, а ты и сожрешь "так и надо", так приказано.Ты хоть пользовал rhel или цент с гуем? Гном там древний 3.14, половина дополнений с оффсайта гнома не работает, либо со старыми багами, которые исправлены в новых версиях, но они не поддержваются 3.14. Сама эта версия гномощели не блещет стабильностью и удобной функциональностью, все самое вкусное появляется в 3.22+, и только остается надеяться, что оно протиснется в следующий минорный релиз 7-ки, но этому подтверждений не больше, чем я сказал про 8ку
> Ты хоть пользовал rhel или цент с гуем? Гном там древний 3.14,я и доси пользую на работе. только почему там третий, когда там второй?
>> Ты хоть пользовал rhel или цент с гуем? Гном там древний 3.14,
> я и доси пользую на работе. только почему там третий, когда там
> второй?Прости, братишка, не уточнил. Я про 7ку. 6-ка божественна, да. Последний оплот гнома2, после предательства mate.
На багтрекере лежмт задача про обновление гнома до 3.22. Ищите по словам rebase gnome 3.22
К моменту выходы 3.33, как раз подоспеет 3.22 в центос. Проблема никуда не денется, дополнения протухнут, баги останутся неисправленными. Просто, гном - это не то, что нужно rhel. Надеюсь, эту погань выметут оттуда. Эффективней оставить какой-нибудь openbox с десятком советов в базе знаний, как настроить, чем тянуть это чудовищеГ3.
>что gnome3 они больше в rhel не вкатят, плохой опыт rhel7И в чем это заключается? Падение прибыли произошло, массовые отказы от подписки? Или просто влажные мечты гномофоба?
>>что gnome3 они больше в rhel не вкатят, плохой опыт rhel7
> И в чем это заключается? Падение прибыли произошло, массовые отказы от подписки?
> Или просто влажные мечты гномофоба?Имеющие глаза видят, что модель разработки гнома и гтк не соответствует нормальной идеологии длительной поддержки, за что и любим rhel. Гном пилят неоглядываясь, никакого бекпортирования фиксов не делают, приложения переписывают с нуля, оставляя в 3.14 (именно эта версия сейчас в rhel7) такой неподдерживаемый хлам, что стыдно.
Туда нужно KDE5!
Я нашёл для себя в гноме несколько действительно узких мест:
1 альт-таб. Работает непредсказуемо вместе с Альт-ё. Лечится дополнением
2 иконки рабочего стола. Лечатся дополнением.
3 огромные иконки запуска приложений в shell. Особенно на большом мониторе
4 анимация по умолчанию, медленная. Отключается
5 очень странный трей
Как бы надо уметь ошибки признавать.
> Как бы надо уметь ошибки признавать.К сожалению, гном-тим не из таких, кто умеет. поэтому, на помоечку!
а зачем? Седьмая версия (7.3) самый смак сейчас
Кто в теме для чего вообще нужен RHEL? Где он обычно используется? Кто его целевая аудитория? Насколько я понимаю он сделан для рабочих станций, но в чем преимущества по сравнению с платной виндой или бесплатным Debian/CentOS?
> Кто в теме для чего вообще нужен RHEL? Где он обычно используется?
> Кто его целевая аудитория? Насколько я понимаю он сделан для рабочих
> станций, но в чем преимущества по сравнению с платной виндой или
> бесплатным Debian/CentOS?Ну, а для чего ты покупаешь страховку? Чтобы прикрыть свой жопец. Тут то же самое. Оплатил подписку - в случае системного факапа(после апдейта не забуталось ведро, к примеру)/не закрытой вовремя дыры в безопасности смело переводишь стрелки, мол: "А я вот заплатил денег, а редхатовцы такие редхатовцы вовремя заплатку не положили мне в репу". В бесплатном варианте такая отмазка "нету в репе" не прокатит - ты крайний.
> В бесплатном варианте такая отмазка "нету в репе" не прокатитпрекрасно прокатит - там, где нужны отмазки. "я кнопка нажаль, а оно - эшамбе, пешальбе, шайтанама, в репе нет или не так собрано!" После того как начальству слегка надоест - можно уговорить его сменить дистрибутив, эти - козлы, вот те - те крута, да. (и уволиться побыстрому, записав себе эту смену в резюме в список достижений - пусть следующий лох отмазывается дальше)
А вот там где нужны не отмазки, а чтоб работало, а оно непойми от чего сломалось после вроде как не связанного с этим апдейта, и _твоих_ админских знаний не хватает, в платном варианте прибежит бодрый и работящий индус, и, с горем пополам, поднимет твой прод (поднимет, поднимет - за ним, если понадобится, стоят очень грамотные люди), если заранее много заплатишь - то даже и относительно быстро.
В бесплатном к твоим услугам форумы и листы рассылки, где тебя сперва забанят на недельку за недостаточно политкорректное описание проблемы (а у тебя дымится жопа и начальство многозначительно помахивает кнутиком), и гугль, где, двести раз переуточнив запрос, ты получишь...правильно, такой же вопрос, заданный на форуме год назад, так и оставшийся без вменяемого ответа (невменяемые - "тебе оно не надо" ,"ты сам $к, надо было по другому строить прод, я, админ двух локалхостов, точно знаю как это делать", "я ничего не понял что ты тут спрашивал, но имею ценное мнение")Впрочем, тред-стартеру не поможет, его "насколькояпонимаю" целиком идиотское. Причем ничего не мешало самому это проверить, кроме, конечно, детских прыщей.