И как они так получат кусочек пирога, когда речь идёт о получении прибыли, а не о количестве установок?

registry +(

только XML конфигов да реестра не хватало.

это Вы feature request уже делаете? ;)

При том, что они делают вообще всю работу по привидению продукта в работоспособное состояние.

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

Совершенно верно. Но кто это делает и кто внедряет? ;)

в энтерпрайзе? свои таланты, зачастую при помощи систем архитекта от вендора софта/харда. в каждой по настоящему серьезной фирме, есть такой дядя который называется по разному, но занимается оценкой технологий, а после - внедрением и разработкой документации и схем деплоймента. имхо - самая офигенная работа для сисадмина о которой только можно мечтать.

Так они требуют функцию из векторного пространства или systemd? ;)

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

Вообще говоря, всё то, что умеет systemd, делалось существующими до него решениями (примеры есть выше). Зачем он нужен кроме NIH?

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

dyasny> нам нужны люди адекватные нашим задачам. слишком крутые быстро соскучатся и уйдут на повышение, слишком тупые изначально не нужны.

Опять же - это переформулируется как: «Нам не нужны грамотные кадры, которые умеют думать. Нам нужны рабы, которые никуда не будут рыпаться, пока хозяин не скажет!».

dyasny> согласен. только когда работа стоит, а админ играется с тем что ему интересно - это уже проблема.

Это в принципе нездоровая обстановка. Про «играется с тем, что ему интересно» - компания тоже должна играться с тем, что ей интересно. В частности опыт конторы по работе с различными технологиями - это шанс не утонуть, когда контору будут пытаться выдавить с рынка конкуренты, поскольку так будут открываться новые возможности. И особо крутому админу, которому уже поднадоела текущая работа, можно поручить заниматься как раз перспективными направлениями.

dyasny> Кроме того, админ который прокачал скиллы и достоин бОльшей зарплаты это конечно круто, но если он при этих скиллах не приносит ничего работодателю, то за что собственно платить?

Работодатель получил в распоряжение опыт особо крутого кадра. Это настоящее сокровище, которое можно пустить в дело и получить прибыль больше. У других такого крутого кадра нет - потенциально меньше реальных конкурентов. Радоваться надо. Я понимаю, что не всегда удаётся потратиться на новые направления, но с другой стороны кадр уйдёт, но никто не мешает нанять кадра нужной квалификации. Проблема - оверскиллнутый работник. Оверскиллнутый работник уходит и приходит подходящий - проблема решена. А до такого уровня всё равно не так быстро прокачается кадр.

dyasny> То же самое с софтом - если я захочу перейти на другое решение, я смогу, и это будет не сложно

Расскажи это тем, кто на том же MS Office сидят и накопили огроменную базу документов, которые надо читать и которые не всегда в другом ПО открывается как надо. Или тем, кто по глупости в Access свою БД сделал.

И как они так получат кусочек пирога, когда речь идёт о получении прибыли, а не о количестве установок?

вообще-то точно наоборот. речь идет именно о количестве установок. например sourceforge.net сидят на дебиане (во всяком случае когда я ковырял их серверы они как раз на нем сидели). у них огромная инфраструктура, которая в принципе повторяет такие же, но в конторах которые используют RHEL. Если у Дебиана не будет такого же функционала, SF вполне могут уйти на центос (если еще не ушли).

dyasny> блин, каким образом тут вендорлок?

Да тот же journald. Есть формат, который гарантированно поддерживается только одним продуктом и этот формат может меняться от версии к версии.

dyasny> лучше этого есть только одно - писать их прямо в SQL

rsyslog умеет. Вопрос: нафига journald? Если же всё из systemd выкинуть, то всё то, чем хвастаются сторонники systemd, пропадает сразу же.

dyasny> попробуй разобрать несколько гиг логов с параллельно пишущих серверов в DEBUG режиме руками

То есть, ты утверждаешь, что единственный возможный вариант кроме бинарных логов - парсить их вручную?

dyasny> и это значит что энтерпрайзу пофиг быстро все грузится или нет

Зависит от конкретного решения.

dyasny> и насколько простое и стабильное решение они используют

systemd на стабильное и надёжное решение ну никак не тянет. Почему - уже доходчиво разжевал Рич Фелкер, я не буду его слова тут повторять.

dyasny> набором из разных решений, с натяжкой... может быть.

Нет - решение это решение задачи. Из чего оно складывается - вопрос другой. С другой же стороны systemd точно так же можно назвать набором разных решений.

dyasny> Но зачем наворачивать хз что, когда сам дистр это умеет из коробки, на самом низком уровне?

Как минимум затем, что из коробки он всё уметь не может, если не заточен под конкретную сверхузкую задачу на конкретном месте. Если бы это было не так, то профессии системного администратора просто не существовало бы.

И что в этом плохого с точки зрения бизнеса? Денег в любом случае не получают, верно?

Опять же - это переформулируется как: «Нам не нужны грамотные кадры, которые умеют думать. Нам нужны рабы, которые никуда не будут рыпаться, пока хозяин не скажет!».

я этого нигде не говорил.

Это в принципе нездоровая обстановка. Про «играется с тем, что ему интересно» - компания тоже должна играться с тем, что ей интересно. В частности опыт конторы по работе с различными технологиями - это шанс не утонуть, когда контору будут пытаться выдавить с рынка конкуренты, поскольку так будут открываться новые возможности. И особо крутому админу, которому уже поднадоела текущая работа, можно поручить заниматься как раз перспективными направлениями.

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

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

Работодатель получил в распоряжение опыт особо крутого кадра. Это настоящее сокровище, которое можно пустить в дело и получить прибыль больше. У других такого крутого кадра нет - потенциально меньше реальных конкурентов. Радоваться надо. Я понимаю, что не всегда удаётся потратиться на новые направления, но с другой стороны кадр уйдёт, но никто не мешает нанять кадра нужной квалификации. Проблема - оверскиллнутый работник. Оверскиллнутый работник уходит и приходит подходящий - проблема решена. А до такого уровня всё равно не так быстро прокачается кадр.

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

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

Расскажи это тем, кто на том же MS Office сидят и накопили огроменную базу документов, которые надо читать и которые не всегда в другом ПО открывается как надо. Или тем, кто по глупости в Access свою БД сделал.

этих бедняг я каждый день вижу. рассказываю о прелестях открытых форматов, они тяжко вздыхают... ничего нового. Решения тоже надо уметь выбирать, так чтоб тебя не заперли. МС сейчас сильно давят на всех чтоб переходили на офис365, я ради прикола попробовал. то что это аццкий ад и так понятно, но самое веселое получается когда пытаешься отписаться. тупо невозможно - у меня заняло двое суток и примерно 9 часов на телефоне, плюс если бы я не перетащил аутлуком весь мейлбокс, остался бы без мейлов за две недели.

Да тот же journald. Есть формат, который гарантированно поддерживается только одним продуктом и этот формат может меняться от версии к версии.

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

rsyslog умеет. Вопрос: нафига journald? Если же всё из systemd выкинуть, то всё то, чем хвастаются сторонники systemd, пропадает сразу же.

умеет, но для этого надо городить отдельную инфраструктуру.

То есть, ты утверждаешь, что единственный возможный вариант кроме бинарных логов - парсить их вручную?

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

systemd на стабильное и надёжное решение ну никак не тянет. Почему - уже доходчиво разжевал Рич Фелкер, я не буду его слова тут повторять.

это его мнение, которое ничем не лучше мнения того же Леннарта.

Нет - решение это решение задачи. Из чего оно складывается - вопрос другой. С другой же стороны systemd точно так же можно назвать набором разных решений.

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

Как минимум затем, что из коробки он всё уметь не может, если не заточен под конкретную сверхузкую задачу на конкретном месте. Если бы это было не так, то профессии системного администратора просто не существовало бы.

вот тут то и зарыта собака - мне надо на самом деле ковырять каждую мелочь, или я хочу получить хорошее решение из коробки, и настраивать уже апликации, а не ОС? systemd ориентирован на последнее.

И что в этом плохого с точки зрения бизнеса? Денег в любом случае не получают, верно?

конечно получают, пожертвования от таких вот благодарных никто еще не отклонял.

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

systemd на стабильное и надёжное решение ну никак не тянет. Почему - уже доходчиво разжевал Рич Фелкер, я не буду его слова тут повторять.

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

Впрочем нет, вернее будет сказать так. Аргументы против systemd - либо претензии к дизайну (в основном философия и спорные моменты, хотя, бесспорно, есть и здравые замечания), либо претензии к коду (не выдерживаются требования стиля). Аргументы против upstart - перечень конкретных багов, приводящих в гонках и повреждениям файловой системы.

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

кто у тебя на аве?

Мне тоже показалось, что дилемма ложная. В основном все против системд и самого процесса, разрушающего традиции и философию.
т.е. засчет ненужного сравнения апстарт и системд замыливается сама суть проблемы.
мне кажется технический спорт «опенрц» или «системд» лучше отражал философскую составляющую. но по скольку он не ведется. то нам тут вообще нет смысла пыжиться.

В основном все против системд

Почему ты не можешь говорить о традициях и философии не искажая факты? Ведь опять враньё же.

У нас был путь Debian => Gentoo Так как дебиан достал непредсказуемыми глюками при обновлениях. При обновлении ядра/grub постоянно серваки переставали загружатся.

кроме умения писать, есть умение слушать (читать).
я пишу, что осуществлена подмена, поэтому так и затянулся спор. а причина вообще в другом.

не кажется технический спорт «опенрц» или «системд» лучше отражал философскую составляющую. но по скольку он не ведется. то нам тут вообще нет смысла пыжиться.

но поскольку он не ведется

И опять ты не в курсе того о чём и как вёлся разговор в рассылке Debian.

Разговор не ведётся _сейчас_, поскольку сейчас уже вообще все технические разговоры закончились. Тем не менее он вёлся и OpenRC обсуждался. В общем и целом, текущий свой статус идея OpenRC имеет не потому, что TC не туда смотрел, а скорее потому, что майнтэйнер OpenRC в Debian сам не готов к тому, чтобы всерьез претендовать на звание системы инициализации по умолчанию.

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

Well, it's been a month the OpenRC package is waiting in the FTP NEW queue (after a successful GSoC project), so it's a bit silly to tell about something which isn't even in Debian yet...

Это не претензия к техническим деталям OpenRC и не упрёк разработчикам, просто такова объективная ситуация поддержки проекта OpenRC в Debian. Поэтому OpenRC рассматривается прежде всего как перспектива, а не как готовая полноценная система.

LOL

Some remaining quirks, like out-of-the-box halt and reboot remains to solve.

значит оно не совсем умеет halt&reboot, и по-твоему «работает»? фтопку.

и даже процитровал что надо.

и даже назвал полурабочее «практически портированым».

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

Мне не надо твоих говноскриптов даже бесплатно, ибо есть journald. Но хочу убедиться что вместо «я могу» ты можешь реализовать такой функцианал. Нет - что ж, все ясно, трепло и диванный теоретик. Жду код, без него твой поток мыслей читать не буду.

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

Скажи, пожалуйста, должен ли компьютер аварийно завершать свою работу, если в логгере была поймана ошибка? Нужна ли перезагрузка компьютера, если указанная выше ошибка была найдена и исправлена, и выпущен новый пакет с исправлением?

например sourceforge.net сидят на дебиане

Они сидят на RHEL

еще лучше...
если openrc не рассматривается, то зачем его включают в голосование. по-вашему, получается что в ТС сидят идиоты которые сами не знаю, что обсуждали в октябре и пришли к выводу, что нельзя перекладывать груз и далее по тексту...

повторюсь еще раз

мне кажется технический спорт «опенрц» или «системд» лучше отражал философскую составляющую. но по скольку он не ведется. то нам тут вообще нет смысла пыжиться.

если разлад НЕ ФИЛОСОФСКИЙ, речь не идет об изменении традиций команды и философии дебиана. эти попросы решены.
а речь идиот по поводу выбора между systemd и upstart = то какой смысл нам тут вообще пыжится..

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

кто у тебя на аве?

Моя тян.

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

последний раз я лазил в их системы в 2008, и тогда у них фронт энды были на дебиане. с тех пор многое могло измениться

симпaтичная

Сам выбирал, чо

:)

Debian R.I.P.

да ладно может переиграют Ян же восстал

сервер с несколькими разными сетевыми картами, при загрузке не успевал загрузить все kmod-ы этих карт ... но в systemd таких проблем просто нет.

ИЧСХ, это починили это нихрена не путем деланья чего-то в systemd, а путем использования NetworkManager. Но почему-то вписали в заслугу systemd. Странная какая-то логика...

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

Непосредственное. Логгер по сути вкомпилен в жирный пакет systemd, который работает от PID 1. Надо ли объяснять, что произойдёт с системой, в которой покрэшился процесс с PID 1? Или что будет, если произошло обновление пакета с systemd.

последний раз я лазил в их системы в 2008, и тогда у них фронт энды были на дебиане. с тех пор многое могло измениться

По крайней мере 2 последних года фронтэнды у них на RHEL5.

4.2, логгер работает отдельным процессом (как и logind, и всё остальное).

Хватит распространять вызывающе неверные данные.

ИЧСХ, это починили это нихрена не путем деланья чего-то в systemd, а путем использования NetworkManager. Но почему-то вписали в заслугу systemd. Странная какая-то логика...

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

Логгер по сути вкомпилен в жирный пакет systemd, который работает от PID 1. Надо ли объяснять, что произойдёт с системой, в которой покрэшился процесс с PID 1? Или что будет, если произошло обновление пакета с systemd.

у вас неверная информация.

Логгер по сути вкомпилен в жирный пакет systemd, который работает от PID 1. Надо ли объяснять, что произойдёт с системой, в которой покрэшился процесс с PID 1? Или что будет, если произошло обновление пакета с systemd.

у вас неверная информация.

По крайней мере 2 последних года фронтэнды у них на RHEL5.

вполне возможно. или у них каждый набор мирроров настроен по разному (впрочем это вряд ли)

А sysv в принципе не допускает «рейсов», поскольку сервисы грузятся в заранее заданном порядке, и?

P.S.: поведение «я ещё запускаюсь, но отрапортую заранее что запустился» недопустимо.

А sysv в принципе не допускает «рейсов», поскольку сервисы грузятся в заранее заданном порядке, и?

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

Это был не трындец.

Косяк был в tmpfs /var/run tmpfs defaults 0 0

из-за него системди и не хотел работать

Прочитал новость. Снес Debian, поставил Ubuntu 12.04.4 LTS. Debian, давай до свидания. Предвосхищая вопросы, да если Ubuntu перейдёт вслед за Debian, то уйду ещё куда. Если не останется дистрибутивов без systemd, уйду на FreeBSD.

Переходит. на systemd ;) Куда теперь?

Там кроме бинарных логов ещё только XML конфигов да реестра не хватало.

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

XML сам по себе розовый и пушистый, просто его многие не умеют готовить, городя абстрактные метаструктуры типа <item name=«blabla» type=«foo»... А компактный XML, заточенный под предметную область, читается очень даже легко.

А вот бинарные логи - это очень подозрительно, да. Правда, вроде уже написана куча CLI-инструментов для выдёргивания оттуда текстов без привязки к иксам, да и syslog API успели привязать, так что часть первоначальных страхов уже не актуальна.

Объясните мне, спецы, с учётом последних событий можно будет перейти с Wheezy на Jessie простым обновлением, или придётся пол-системы восстанавливать?

Пока не знаю... Возможно сразу на FreeBSD.