I love Poettering .. :-)

костры уже ждут...

А ты сравнил затраты на создание TC и MC? Нет. А следовало бы.

Предлагаешь оценивать качество по затратам? Ну, ок, в systemd Red Hat сейчас делает большие вливания денег.

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

Да без сомнения. Только вот сейчас Линукс является вполне удобным для этой задачи инструментом, а потом вдруг перестанет им быть ради какого-то «юзерфрендли», которого толком еще не видно. Мне это кажется странным (если сказать мягко).

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

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

1) я бы сказал, что не всегда.
2) даже если и так - поправил по месту и пустил в работу. Всяко быстрее, чем разбираться в каком-нибудь монолитном коде, который еще надо скачать и скомпилять.

И подробные, не в пример винде, логи никто не отменяет.

Они там тоже подробные. Но не юзабельные. Вот это предлагают и тут.

Ты из тех, кто TC видел только в каких-нибудь левых PowerPack'ах?

Насколько я помню, Lister реализован как плагин. К которому можно написать другие плагины. Даже экзешник с отдельным Lister-ом бродил.

Уверяю, сам по себе он намного мощнее юникс-вейного Krusader'а

И что ты хочешь доказать? Автор ТС разумный человек, которому не чужд UNIX-way.

Софта, качественно использующего юникс-вей, практически не существует.

emacs, netbeans, eclipse, idea, mozilla, k3b, какой-то архиватор в моей убунте...

Приведи примеры качественного софта на юникс-вее.

Ненене, Дэвид Блейн, мошенничать не получится. Причем юниксвей к качественности (в любой методологии разработки можно сделать говно)? Как ты определяешь эту «качественность»? Для меня MC вполне «качественный», для тебя - нет.

Ты сказал:

karbofos> В том, что можно сделать намного меньше, быстрее и функциональней, если не молиться на принцип юникс-вея.

Ты не думал, что бесплатная открытая программа вроде MC просто не появилась бы на свет без принципа юниксвея? Пара человек, которые ее изначально писали, просто не довели бы проект до завершения. Если не думал - подумай. А пока ты придрался к недостатку VFS в MC и весь в белом стоишь красивый.

в руках у шляпников мощнейший брандспойт для тушения костров и могучая кувалда для приведения в порядок мозгов :-)

шито, emacs, гребаный комбайн из всего чего можно, это веник-вей ? :-)

Да без сомнения. Только вот сейчас Линукс является вполне удобным для этой задачи инструментом, а потом вдруг перестанет им быть ради какого-то «юзерфрендли», которого толком еще не видно. Мне это кажется странным (если сказать мягко).

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

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

Ну, ок, в systemd Red Hat сейчас делает большие вливания денег.

Пруф.

Просто krusader никому нафиг под линуксом не нужен как и прочие двухпанельники. Вот вследствие убогости винды и доса им альтернатив практически нет.

тем не менее systemd это задумка шляпников и все идет к тому что «плакали но жрали кактус»

Прогуляйся на kde-apps и полюбуйся на количество загрузок и отзывов - он там среди первых «Никому нафиг под линуксом не нужен» только в том случае если этот «никому» неосилятор :-)

Я думаю можно было бы сделать, чтобы и большинство и меньшинство были довольны.

Например сначала документировать, а потом реализовывать.

libc хорошо документирована в стандарте unix. Документация на линуксовую реализацию тоже есть. Пишешь ядро, libc и меняешь. Да геморройно, но судя по debian/hurd и archhurd не настолько всё ужасно.

Что характерно, очень немногие программы требуют патчей для работы на hurd-е.

Жесткая же привязка к libsystemd-* - нехорошая идея.

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

Да и то, что приложение качают с сайта не ставят пакетманагером это подтверждает

феерабенд дом труба шатал этого лакатоса. да и кунн нам завещал что возможен и ещё как.

emacs, гребаный комбайн из всего чего можно, это веник-вей ? :-)

Да. С одной стороны юникс-вей там в плагинах, с другой стороны в хорошей интеграции с шеллом и скриптами.

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

У меня есть конкретная задача - поднять слаку 0.5 на 486 .. Вопрос лишь в том где ты все это сейчас найдешь :-) То же, с полярным знаком , и с твоей задачей, она очень сурово нетипична. Пока systemd пилится для типичных задач. НО, в перспективе, по вполне понятным принципам, она будет лучше чем твой

Что такого нетипичного в работе Линукс-машины в качестве лог-сервера? Для ведроидофона или уютного домашнего десктопа она может и нетипична, для сервера в сети предприятия - рядовейшая задача, Линукс ее умеет, есть разные лог-сервера, которые умеют ее выполнять так, как нужно пользователю. Куча разного оборудования (прокси, фаерволы, контроллеры беспроводных сетей, маршрутизаторы, ACS, точки доступа, и прочая, прочая) умеет сохранять свои логи на удаленном syslog-сервере. Заменять давно и успешно работающие вещи на недоделку, ИМХО, глубоко неправильно. Впрочем, сейчас это становится модным.

P.S. Если бы РедХет руками Поттеринга пилил просто новую улучшенную систему инициализации, никому бы и в голову не пришло вякать против. А пока видны только NIH-страдания из-за апстарта и желание всех принудить использовать подконтрольный продукт, для чего к системе инициализации гвоздями пытаются прибить все, от udev и логгера до менеджера сеансов и Гнома, и разводят везде майкрософтовскую вонь о себе, перспективных, и всех остальных - ретроградах, которые только кнопки двигать умеют.

2) даже если и так - поправил по месту и пустил в работу. Всяко быстрее, чем разбираться в каком-нибудь монолитном коде, который еще надо скачать и скомпилять.

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

Да и потом, кто запретит написать к systemd модуль, который на какой-то стадии частично OpenRC сэмулирует? Запустить там скрипт, другой... Кстати, а ты сам не пробовал писать модули для systemd? Не знаешь, чего это мейнтейнеры многих дистрибутивов чуть ли не ликуют, когда узнают о его возможностях? Может подход OpenRC тебе и не понадобится, сам рад будешь использовать возможности systemd.

Насколько я помню, Lister реализован как плагин. К которому можно написать другие плагины. Даже экзешник с отдельным Lister-ом бродил.

Нет, он встроен. С начала 2000-х, если не раньше. Что было раньше - не могу сказать, не юзал.

И что ты хочешь доказать? Автор ТС разумный человек, которому не чужд UNIX-way.

Автор TC не распространяет с его дистрибутивом десятки зависимостей в виде отдельных .exe-файлов. Он ставит перед собой задачу, основываясь на функциональности результата и юзабилити, и успешно её решает, а не оправдывается, что де, md5sum не умеет возвращать прогресс расчёта.

emacs
idea

Не пользовался, не могу ничего сказать. Но вот по остальным:

netbeans
eclipse

Жирные, тормозные IDE. Работают много хуже того же QtCreator'а, который если и не догоняет по функционалу, то не сильно.

mozilla

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

k3b

Сколько она мне дисков запорола... А всё потому что с growisofs работает через задницу. Не может подгрузить его как библиотеку и просто дёргать функции, приходится каждый раз запускать, читать вывод в stdout, завершать. А ведь к тому же mplayer раньше столько костылей городили на случай если он на компе юзера окажется локализованным, а вывод как-то грепать надо...

какой-то архиватор в моей убунте...

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

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

хотел бы я ссылку на этот «базовый принцип оптимизации», а то теориая операций мне совсем другие вещи подсказывает..

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

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

Ты не думал, что бесплатная открытая программа вроде MC просто не появилась бы на свет без принципа юниксвея? Пара человек, которые ее изначально писали, просто не довели бы проект до завершения. Если не думал - подумай. А пока ты придрался к недостатку VFS в MC и весь в белом стоишь красивый.

Я не осуждаю существование MC. Более того, я им ежедневно пользуюсь, и временами пишу авторам о найденных багах. Но это не значит, что когда есть финансы, их нельзя использовать во благо развития. У systemd есть финансирование. Ты не отрицал, а даже утверждал - TC лучше потому что вбухано бабло. По твоей логике, если есть финансирование, значит софт лучше. Точка зрения спорная, но я тебя спрошу вот о чём: чем ты не доволен в случае с systemd? Ведь в твою логику хорошего софта он укладывается?

Я не одну из этих недоделок студиозов с похмелья не променяю на worker :-) В нем я могу сделать все что хочу, а эти недоделанные проводники линупса пускай идут в ж..

любая книга по оптимизации

Пруф.

Поттеринг официально работает в Red Hat. Поттеринг один из самых заметных разработчиков Red Hat. Поттеринг в данный момент плотно занимается systemd. Банальная логика.

Но вообще, если хочешь, можешь сам поискать пруфы.

он вгоняет в ступор GDM

это объясняет ненависть Поттеринга к этой приблуде :)

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

Просто krusader никому нафиг под линуксом не нужен как и прочие двухпанельники. Вот вследствие убогости винды и доса им альтернатив практически нет.

Многим нужен. Но разработка ФМ - дело нетривиальное и многим не хватает вдохновения на полноценную альтернативу.

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

Будет такая задача, а она будет, будет и решение в рамках systemd Какое именно, ну это лучше у автора спросить :-)

до менее чем двух секунд, до полной готовности к работе оболочки Xfce

Работает и без него шустро и быстро. Подеринга на костёр.

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

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

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

Я думаю можно было бы сделать, чтобы и большинство и меньшинство были довольны.

Можно. Предложи им своё видение, у тебя есть такая возможность.

Что характерно, очень немногие программы требуют патчей для работы на hurd-е.

Жесткая же привязка к libsystemd-* - нехорошая идея.

Hurd сделан по стандартам POSIX, конкретных стандартов загрузки же нет. Не отрицаю, идея не лучшая, но и тому, что предлагает systemd альтернатив-то тоже по сути нет. Либо написать всё с завязкой на одну-единственную libsystemd, либо для каждого пакета - udev, syslog, cron, писать свои врапперы и потом всё это поддерживать, пытаясь уследить за всеми шевелениями в каждом пакете.

Но вообще, если хочешь, можешь сам поискать пруфы.

Ну этого я и ожидал, спасибо.

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

Плагины - не юникс-вей.

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

Обычный syslog-ng. Если systemd (когда дозреет, и его внедрят везде, где можно и низзя) не будет создавать проблемы сторонним логгерам, у меня к нему претензий с этой стороны не будет. А если будет «Наш сислог неотключаемый, перевесьте ваш динозаврий сислог на другой порт, пожалуйста» - будет хреново. Пока, судя по риторике используемой сторонами с спорах, больше похоже на «будет хреново».

Ну так и у винды хорошая интеграция ядра с графической системой и всяких «плагинов» тоже полна коробочка :-) И даже скрипты с шеллом есть :-)

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

Ну этого я и ожидал, спасибо.

О как. Я, оказывается, кругом неправ. Топик уже можно закрывать? Мне тупо лень тратить время на поиск пруфов для тебя, когда многое и так очевидно. Зато теперь я знаю, что тебе пруфов лучше не давать, ты ждёшь в тексте не смысл, а синенький подчёркнутый текст.

Ну и какую проблему локального характера решает systemd?

Загрузки системы и управления сервисами.

Тысячи запусков awk, grep и sed останутся?

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

которых станет намного меньше.

мамой клянешься?

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

Они не столь редки на каких-нибудь дата-центрах. Но основной поинт в том, что ты не ограничен в инструментарии одним только loggrep-пом.

См. мой предыдущий коммент.

sdcat systemd_log.bin > log.txt на гигабайтных объемах даст дополнительный оверхед.

И кстати, если ещё какой-нибудь SQL-подобный язык запросов к нему прикрутить

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

Я ничего не гарантирую

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

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

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

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

Возможность взять и починить самому у тебя никто не отнимет, исходники открыты всем

Разницу в курении кода на Це и баше понимаем?

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

Дебиан, Убунту? Не вижу ликования.

Автор TC не распространяет с его дистрибутивом десятки зависимостей в виде отдельных .exe-файлов.

Открой для себя пакетный менеджер, который зависимости розрулит.

Жирные, тормозные IDE. Работают много хуже того же QtCreator'а

От ты и сам добавил. Наверняка дергает в фоне что-то через CLI.

Не юникс-вей. Плагины - не юникс-вей.

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

Сколько она мне дисков запорола...

Диски мне пороли и монолитные системы еще в девяностых...

дна консольная утилита с юникодом работает, другая - нет, третья вообще не умеет распаковывать отдельный файл

Ну вот, ты перечислил недостатки присущие и виндовым монолитным архиваторам. Сам видел.

Загрузки системы и управления сервисами.

Это проблема любого дистрибутива.

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

Нафига их делать? Грепать конфиги не придётся, будет своё апи доступа к параметрам настроек.

Они не столь редки на каких-нибудь дата-центрах.

Linux не только для дата-центров, не знал? Зачем тебе systemd в дата-центрах? Юзай стандартный init, благо Gnome и прочий гуй, который к нему хотят привязать, на серверах не нужен.

sdcat systemd_log.bin > log.txt на гигабайтных объемах даст дополнительный оверхед

А почему ты уверен, что это будет твой стандартный путь грепанья логов? Я это привёл как вариант на какой-нибудь нерабочей машинке, которую требуется поднять.

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

См. выше.

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

Ничего я не агитирую. Я говорю, что мне нравится подход Поттеринга. Я хочу иметь действительно десктопный Linux, если кому-то будет не хватать сегодняшнего Linux'а, к тому времени *BSD займёт его нишу и все будут в шоколаде.

Ну так и у винды хорошая интеграция ядра с графической системой и всяких «плагинов» тоже полна коробочка :-)

Плохо только, что слишком тесная, интеграция эта. Ее бы разорвать...

И даже скрипты с шеллом есть :-)

только жутко неудобные они. В 21-то веке.

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

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

Что-то сомневаюсь.