[NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

[NickLion]

А что, lsb_release не катит?

Вариант с файлом проще, нежели запуск какой-то программы и получение ответа от неё.

[taaroa]

угу. так откуда берутся зомби?

повторю (ещё раз) свой вопрос: как убить зомби не перезагружая систему? и systemd этот вопрос решает. в отличие от system v init.

[/dev/random]

повторю (ещё раз) свой вопрос: как убить зомби не перезагружая систему? и systemd этот вопрос решает. в отличие от system v init.

Единственный способ убить зомби без согласия родительского процесса - это убить родительский процесс. После этого init (любой полноценный init) выполнит необходимый для удаления записи запрос waitpid().
Убить родительский процесс можно безо всякого systemd, А без этого... Если разработчики systemd нашли способ избавиться от зомби без уничтожения родителя, им надо вручить все существующие нобелевки и поставить памятник на Луне.

Или, может, вы ошибочно называете "зомби" что-то другое, не запись в таблице процессов, оставшуюся после завершения процесса из-за того, что родитель забыл вызвать waitpid()?

[alv]

В BSD это очень хорошо видно и понятно.

а ещё в америке негров линчуют·

Хочешь сказать, Потный Леннарт - из Ку-клукс-клана?

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

(с) Александр Галич

[taaroa]

Или, может, вы ошибочно называете "зомби" что-то другое, не запись в таблице процессов, оставшуюся после завершения процесса из-за того, что родитель забыл вызвать waitpid()?

см. начало.
[NIXP] Systemd не будет поддерживать дистрибутивы без /etc/os-release

[sash-kan]

боюсь, что пятнадцатый стандарт не нужен и дистростроителям…

А есть такие? Знаю о lsb_release. Но это программа (зачем?), которая выдаёт информацию, которую смогла обнаружить. А вот простой текстовый файл или переменные окружения — самый простой и надёжный способ.

совершенно верно·
ещё и более быстрый·
именно поэтому и неясна идея поттера — ведь lsb_release надо запустить лишь один раз при сборке systemd, эту информацию поместить в файлик /etc/systemd/blablabla, и наслаждаться огромным сокращением времени, требующимся systemd для написания строчки "welcome to $yourdistro"…

Хочешь сказать, Потный Леннарт - из Ку-клукс-клана?

хочу сказать, что линчевание негров имеет к этой дискуссии малое отношения·

[serzh-z]

именно поэтому и неясна идея поттера — ведь lsb_release надо запустить лишь один раз при сборке systemd, эту информацию поместить в файлик /etc/systemd/blablabla

Вывод lsb_release не содержит всей той информации, что предлагается помещать в os-release. lsb_release использует эвристику, чтобы предположить версию и имя дистрибутива. Не все дистрибутивы следуют LSB и не все содержат lsb_release.

[drBatty]

Ну, если стандартизация без затрат со стороны дистростроителей для Вас не ответ

конечно НЕ ОТВЕТ. Ибо выше я уже расписывал, почему это не нужно.

Чтобы легко было определить что за дистр на любом этапе загрузки/работы. А то иногда сидишь по ssh и долго думаешь — а какая тут ось — RHEL5.5/5.6/6.0/CentOS5.5/6.0/etc?

это исключительно проблемы вашего незнания. Откройте для себя /etc/redhat-release (такой-же файл имеется и в других дистрибутивах, только называется по другому)
ответ не принимается.

PS для сильно боящихся вирусов и троянов — никто не запрещает Вам там написать левую информацию.

та я-то напишу... а что делать миллионам хомячков, которых вы подставите?

повторю (ещё раз) свой вопрос: как убить зомби не перезагружая систему

откуда я знаю? НЕТ у меня зомби. вот как будут - буду думать. Причём думать я буду о том, что-бы они не появлялись, а не о том, как их убивать без перезагрузки.

и systemd этот вопрос решает. в отличие от system v init.

сомнительный плюс - убивает то, чего просто не существует.

[sash-kan]

именно поэтому и неясна идея поттера — ведь lsb_release надо запустить лишь один раз при сборке systemd, эту информацию поместить в файлик /etc/systemd/blablabla

Вывод lsb_release не содержит всей той информации, что предлагается помещать в os-release. lsb_release использует эвристику, чтобы предположить версию и имя дистрибутива. Не все дистрибутивы следуют LSB и не все содержат lsb_release.

для выдачи строчки "welcome to $yourdistro" этого более чем достаточно·
а пакет lsb_release, afaik, есть во всех дистрибутивах·

угу. так откуда берутся зомби?

повторю (ещё раз) свой вопрос: как убить зомби не перезагружая систему? и systemd этот вопрос решает. в отличие от system v init.

systemd нет, процессов-zombie нет·
я что-то делаю явно не так·
p.s. на чуть более серьёзной волне: а что, systemd при установке патчит linux, добавляя возможность очистить пару килобайт памяти от этих ваших неуловимых джо zombie?
так надо эти патчи отослать linux-оидам…

[Bluetooth]

А что, lsb_release не катит?

Вариант с файлом проще, нежели запуск какой-то программы и получение ответа от неё.

И чем же, простите? И потом, достаточный ли это аргумент для еще одного "стандарта"?

[NickLion]

это исключительно проблемы вашего незнания. Откройте для себя /etc/redhat-release (такой-же файл имеется и в других дистрибутивах, только называется по другому)

1) ну, теперь-то я знаю, но если бы os-release был общим для разных, то мне не пришлось бы особо искать как определить тип дистрибутива
2) угу, и сидеть перебирать файлики
Лично мне кажется, что стандарт, который никому ничего не стоит сделать, а жизнь упрощает — только положительное явление.

[NickLion]

И чем же, простите? И потом, достаточный ли это аргумент для еще одного "стандарта"?

Тем, что открыть файл это примитивная операция в практически любом языке программирования. А вот получения вывода программы — не всегда. И да, lsb_release такой стандарт, что требует установки необязательного пакета. Милое поведение.

[drBatty]

1) ну, теперь-то я знаю, но если бы os-release был общим для разных, то мне не пришлось бы особо искать как определить тип дистрибутива

вы не знаете тип дистрибутива сервера? Вы, простите, кто такой? И что вы на этом сервере делаете?

2) угу, и сидеть перебирать файлики

а зачем их перебирать-то? Изучайте свой любимый дистрибутив, который вы так любите использовать.

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

проблема в том, что упрощает такой стандарт жизнь только
1. совсем уж безбашенным одминам. У которых Over9000 разных серверов, которые туда что-то ставят, и при этом не знают КУДА.
2. злоумышленникам.

Если вы из п1, и магия $PS1 вам не знакома (как и магия ~/.bashrc) - запишите на бумажке
(как говорил мой старшина: "товарищ солдат, если у вас голова как унитаз, в котором ничего не держится, заведите себе записную книжку. Или две, как у меня")

Если вы из п2, то облегчать вам жизнь я не намерен.

Тем, что открыть файл это примитивная операция в практически любом языке программирования.

э... так мы об админе, который потерялся, и не знает, он в RH или в Deb'е, или о программе, которая была непонятно как установлена (явно не из пакета для данного дистрибутива)?

[NickLion]

вы не знаете тип дистрибутива сервера? Вы, простите, кто такой? И что вы на этом сервере делаете?

В мои обязанности не входит помнить какая система стоит на более чем 30 серверах, с учётом, что на некоторых система переустанавливается. Я — программист. На сервере программки компилю. Свой основной для предварительного тестирования я знаю. А когда надо быстро что-то проверить на QA сервере, а там ни GCC, ни tcpdump. Я как-то не привык тащить из другой версии пакеты.

а зачем их перебирать-то? Изучайте свой любимый дистрибутив, который вы так любите использовать.

В моём любимом дистрибутиве (openSuSE) УЖЕ есть файл /etc/os-release параллельно с /etc/SuSE-release и никто никому не мешает.

проблема в том, что упрощает такой стандарт жизнь только
1. совсем уж безбашенным одминам. У которых Over9000 разных серверов, которые туда что-то ставят, и при этом не знают КУДА.
2. злоумышленникам.

И проприетарным программам.

Если вы из п1, и магия $PS1 вам не знакома (как и магия ~/.bashrc) - запишите на бумажке
(как говорил мой старшина: "товарищ солдат, если у вас голова как унитаз, в котором ничего не держится, заведите себе записную книжку. Или две, как у меня")

Машины не мои, чтобы $PS1 менять. А записывать, искать. Разве cat /etc/os-release не проще выглядит? Вот то-то же.

э... так мы об админе, который потерялся, и не знает, он в RH или в Deb'е, или о программе, которая была непонятно как установлена (явно не из пакета для данного дистрибутива)?

1) Об админах ничего не знаю. Не админ. Мою ситуацию обсудили.
2) Проприетарные программы никто не отменял. И не из пакета для данного дистрибутива — такое тоже бывает.

[drBatty]

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

не... В данном случае вы выполняете обязанности администратора. И админ из вас не очень... Нормальный админ создал-бы пакет для данной системы, и установил/обновил его штатными методами данной системы. А пакету для SUSE не нужно знать что он в SUSE. Всегда ваш К.О..

В моём любимом дистрибутиве (openSuSE) УЖЕ есть файл /etc/os-release параллельно с /etc/SuSE-release и никто никому не мешает.

Когда я служил в армии РФ, у нас тоже был забор, и в заборе была дыра. И она никому не мешала. Я и сам неоднократно пьяный в дугу возвращался через эту дыру из самоволок. Философский вопрос: хорошо это или плохо?

И проприетарным программам.

вряд ли. Хотя может и так... Лучше-бы таких программ вообще не было.

Машины не мои, чтобы $PS1 менять.

всякое левое ПО вы туда ставите, а $PS1 для себя поменять не можете?

Разве cat /etc/os-release не проще выглядит? Вот то-то же.

в Windows ещё проще - там сейчас только NT, разница лишь в номере версии и комплектации. Ну и что? Это радует только Касперыча и прочих (анти)вирусописателей.

1) Об админах ничего не знаю. Не админ. Мою ситуацию обсудили.

не админ, но занимаетесь тем, чем должен заниматься админ.

2) Проприетарные программы никто не отменял.

мне, кстати, не нужно, что-бы какой-то календарик собирал и отправлял об о мне статистику в Центр. В частности и содержимое /etc/os-release. Зачем этому календарику знать имя моей ОС - вообще непонятно. Если там ему что-то надо, то есть конфиг (гуй), я там вобью необходимые данные (где что лежит). Автоматика мне не нужна, особенно проприентарная, про которую ничего не знаешь.

И не из пакета для данного дистрибутива — такое тоже бывает.

что, прямо так, по живому? Мне постоянно приходится так делать, но я переделываю левые пакеты в родные, а потом уж их ставлю. (в Slackware)

[NickLion]

не... В данном случае вы выполняете обязанности администратора. И админ из вас не очень... Нормальный админ создал-бы пакет для данной системы, и установил/обновил его штатными методами данной системы. А пакету для SUSE не нужно знать что он в SUSE. Всегда ваш К.О..

так я и обновляю штатными средствами. Я не виноват, что там не прописаны репозитарии. Вот чтобы их прописать и приходится глянуть версию, а потом добавлять соответствующий реп — для RH/CentOS 5.5, 5.6, 5.7, 6.0.

Сравнение с дырой вообще не в тему. К чему Windows тоже непонятно. Стандарты — это хорошо. В Windows нет стандартов, есть как скажет MS.

Проприетарные программы ещё долго будут. Такая психология людей. В текущей модели open source нормально отбивает деньги в популярных решениях, но для некоторого рода программ, например, специализированное ПО, такая модель не подходит.

[drBatty]

так я и обновляю штатными средствами. Я не виноват, что там не прописаны репозитарии. Вот чтобы их прописать и приходится глянуть версию, а потом добавлять соответствующий реп — для RH/CentOS 5.5, 5.6, 5.7, 6.0.

про /etc/redhat-release вы специально "забыли"? ну-ну...

Сравнение с дырой вообще не в тему.

очень даже в тему. Она тоже "никому не мешает".

К чему Windows тоже непонятно. Стандарты — это хорошо. В Windows нет стандартов, есть как скажет MS.

в Windows всё стандартное-вендовое.

Проприетарные программы ещё долго будут.

будут. но это исключение, а не правило. Да и не слишком-то этим программам нужен этот файл, без него как-то обходятся. Что даст этот ваш файл хорошего? Что раньше у меня проприентарная XYZ работала, а завтра рухнет с сообщением "неизвестная ОС"?

[KiWi]

вы не знаете тип дистрибутива сервера? Вы, простите, кто такой? И что вы на этом сервере делаете?

А в чём, собственно, проблема? Или как обычно: люблю поговорить на пустом месте?
Ситуация, что по каким-то причинам попал на сервер и нужно что-то там сделать, но при этом видишь его в первый(и, возможно, последний) раз в жизни -- вполне нормальна.

[KiWi]

И чем же, простите? И потом, достаточный ли это аргумент для еще одного "стандарта"?

Тем, что открыть файл это примитивная операция в практически любом языке программирования. А вот получения вывода программы — не всегда. И да, lsb_release такой стандарт, что требует установки необязательного пакета. Милое поведение.

О, да!
И вместо того, чтобы пойти сюда: http://lists.linuxfoundation.org/pipermail...May/002147.html
Чтобы-таки прописать в LSB кроме команды lsb_release ещё и файл /etc/lsb-release(который есть в той же Ubuntu), чтобы можно было открывать файлик, либо переписать этот ужасный python на прекрасный C -- лучше предложить завести ещё один файл. Так в стиле opensource.

[watashiwa_daredeska]

lsb_release использует эвристику

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

пакету для SUSE не нужно знать что он в SUSE.

Зато пакету .rpm/.deb может быть полезно знать, в какой он системе.

[drBatty]

Ситуация, что по каким-то причинам попал на сервер и нужно что-то там сделать, но при этом видишь его в первый(и, возможно, последний) раз в жизни -- вполне нормальна.

ещё скажите "типична"... Да и изначальное название дистрибутива вам мало что скажет - всё больше зависит от прошлого админа.

И вместо того, чтобы пойти сюда: http://lists.linuxfoundation.org/pipermail...May/002147.html
Чтобы-таки прописать в LSB кроме команды lsb_release ещё и файл /etc/lsb-release(который есть в той же Ubuntu), чтобы можно было открывать файлик, либо переписать этот ужасный python на прекрасный C -- лучше предложить завести ещё один файл. Так в стиле opensource.

это мне тоже непонятно.

[alv]

линчевание негров имеет к этой дискуссии малое отношения·

Ошибаешься, Саша - имеет самое непосредственное.
Поднят вопрос - нужен ли файл os-release. Завязанный на systemd. На что следует резонный контр-вопрос: а нужен ли systemd. Отрицательный ответ на него автоматом снимает вопрос про os-release.
PS уж совсем про линчевание негров: на моём новом ноуте openSUSE грузится с systemd 55 секунд, с SysV - 46 секунд - http://alv.me/?p=1484. Вопрос на засыпку: и кого тут надо линчевать?

[NickLion]

про /etc/redhat-release вы специально "забыли"? ну-ну...

Да ясно, что сейчас я делаю просто cat /etc/redhat-release, но на новом дистре (если вдруг такое случится) нужно будет искать — а какой файлик там хранит эту информацию?

очень даже в тему. Она тоже "никому не мешает".

Не в тему. Ибо дыра поможет прониктнуть кому-то "не тому". А этот файлик — нет. Раз дистрибутив (с Ваших слов) так легко определить сейчас, то этот файлик не упростит путь злоумышленнику.

будут. но это исключение, а не правило.

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

Да и не слишком-то этим программам нужен этот файл, без него как-то обходятся. Что даст этот ваш файл хорошего? Что раньше у меня проприентарная XYZ работала, а завтра рухнет с сообщением "неизвестная ОС"?

Иногда требуется дистро-специфичное поведение.

О, да!
И вместо того, чтобы пойти сюда: http://lists.linuxfoundation.org/pipermail...May/002147.html
Чтобы-таки прописать в LSB кроме команды lsb_release ещё и файл /etc/lsb-release(который есть в той же Ubuntu), чтобы можно было открывать файлик, либо переписать этот ужасный python на прекрасный C -- лучше предложить завести ещё один файл. Так в стиле opensource.

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

Поднят вопрос - нужен ли файл os-release. Завязанный на systemd.

Наоборот, systemd завязанный на os-release

[drBatty]

Да ясно, что сейчас я делаю просто cat /etc/redhat-release, но на новом дистре (если вдруг такое случится) нужно будет искать — а какой файлик там хранит эту информацию?

тот же самый очевидно.

Не в тему. Ибо дыра поможет прониктнуть кому-то "не тому". А этот файлик — нет. Раз дистрибутив (с Ваших слов) так легко определить сейчас, то этот файлик не упростит путь злоумышленнику.

немного не так. Дистрибутив определить непросто, но это и не нужно. Мы ставим уже готовые пакеты для СВОЕГО дистрибутива, которые(пакеты) очевидно знают, куда они ставятся. Глупые ошибки фильтруются с помощью ЭЦП и/или того-же /etc/redhat-release.
Ну а кому ещё надо определять дистр кроме инсталляторов - мне непонятно.

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

дык уже есть решение, зачем ещё один велосипед?

[NickLion]

тот же самый очевидно.

Если это будет CentOS, Debian, Ubuntu, openSuSE или ещё что — там будет другое.

немного не так. Дистрибутив определить непросто, но это и не нужно. Мы ставим уже готовые пакеты для СВОЕГО дистрибутива, которые(пакеты) очевидно знают, куда они ставятся. Глупые ошибки фильтруются с помощью ЭЦП и/или того-же /etc/redhat-release.
Ну а кому ещё надо определять дистр кроме инсталляторов - мне непонятно.

Тем же инсталляторам, верно.

дык уже есть решение, зачем ещё один велосипед?

Ещё раз, лично мне всё равно как будет называться этот файл. Лишь бы это было стандартом, и не требовало установки необязательного пакета. Пусть продвигают /etc/lsb-release. Это единственный адекватный тезис.

[bormant]

Ситуация, что по каким-то причинам попал на сервер и нужно что-то там сделать, но при этом видишь его в первый(и, возможно, последний) раз в жизни -- вполне нормальна.

Да ясно, что сейчас я делаю просто cat /etc/redhat-release, но на новом дистре (если вдруг такое случится) нужно будет искать — а какой файлик там хранит эту информацию?

Так этот вопрос вполне стандартно решается в текущем положении дел

Код: Выделить всё

$ ls -1 /etc/*release ; cat /etc/*release

и для slackware-release, и для redhat-release, и для SuSE-release, и т.д.

[diesel]

Так этот вопрос вполне стандартно решается в текущем положении дел

Код: Выделить всё

$ ls -1 /etc/*release ; cat /etc/*release

и для slackware-release, и для redhat-release, и для SuSE-release, и т.д.

и тут приходит /etc/debian-version, или /etc/debian-version + /etc/lsb-release. Феерично. При этом что форматы файлов далеки от одинаковости
а так, да, утилита lsb_release в Fedora как раз это и делает, смотрит похожа ли система на редхат, если не похожа - смотрит как там насчет дебиана. скорее всего разработчики стандарта ожидали что каждый дистрибутив просто положит простой скрипт(ХЗ почему не файл), который будет исключительно для этого дистрибутива выдавать версию в стандартном виде. Но получилось как всегда

[bormant]

Уговорили

Код: Выделить всё

$ cat /etc/*release /etc/*version

[drBatty]

Если это будет CentOS, Debian, Ubuntu, openSuSE или ещё что — там будет другое.

в CentOS тоже самое. Я проверял.

Тем же инсталляторам, верно.

а надо?

Ещё раз, лично мне всё равно как будет называться этот файл. Лишь бы это было стандартом

ну раз хотите бесполезный стандарт - так он УЖЕ есть. Его и продвигайте. Зачем новый-то городить?

Так этот вопрос вполне стандартно решается в текущем положении дел

если конечно админ не пофиксил.

[sash-kan]

Зачем новый-то городить?

1. nih-синдром
2. желание осчастливить планету _ещё_ одним «стандартом»