URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 87443
[ Назад ]

Исходное сообщение
"Проект GNU начал развитие нового пакетного менеджера Guix"

Отправлено opennews , 23-Ноя-12 23:10 
Разработчики сообщества GNU представили (http://lists.gnu.org/archive/html/gnu-system-discuss/2012-11...) проект GNU Guix (http://www.gnu.org/software/guix/), в рамках которого началось развитие нового пакетного менеджера и основанного на нём свободного дистрибутива приложений GNU. Для тестирования доступен (http://git.savannah.gnu.org/cgit/guix.git/) первый альфа-выпуск проекта, который поставляется с небольшим набором пакетов, составляющих дистрибутив Guix. В настоящее время дистрибутив не поддерживает формирование отдельной загружаемой системы и поставляется как набор пакетов с приложениями для установки в уже установленных GNU/Linux системах.


Анонсированный пакетный менеджер (https://savannah.gnu.org/projects/guix/) продолжает развитие проекта Nix (http://nixos.org/nix/) и в дополнение к стандартным функциям управления пакетами поддерживает такие возможности, как выполнение транзакционных обновлений, возможность отката обновлений, работа без получения привилегий суперпользователя, поддержка привязанных к отдельным пользователям профилей, возможность одновременной установки нескольких версий одной программы и средства уборки мусора.


Формируемые для Guix пакеты устанавливаются в отдельное дерево директорий или поддиректорию в каталоге пользователя, что позволяет обеспечить его параллельное сосуществование с другими пакетными менеджерами и обеспечить поддержку широкого спектра существующих дистрибутивов. Пакеты оформляются в виде самодостаточных контейнеров, содержащих все необходимые для их работы зависимости и компоненты, позволяющие запустить приложение независимо от наличия других пакетов и без оглядки на состав базового системного окружения. Для определения сценариев сборки приложений и правил формирования пакетов предлагается использовать специально подготовленный высокоуровневый предметно-ориентированный язык и компоненты Guile Scheme API.


URL: http://lists.gnu.org/archive/html/gnu-system-discuss/2012-11...
Новость: http://www.opennet.me/opennews/art.shtml?num=35418


Содержание

Сообщения в этом обсуждении
"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 00:18 
> Линуксоиды слишком любят создавать себе трудности и героически их преодолевать.

Героическое преодоление трудностей начинается когда какой-то имбецил начинает полагать что система где есть только один Единственно Правильный Вариант (tm) - это круто. Особенно круто становится когда одним надо суперкомпьютеры а другим железку с спичечный коробок. Тут то мы и понимаем что у этих хреновин разные задачи и одного размера всем - нифига не хватит.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 00:46 
Немного разные задачи - это еще не повод городить несовместимые велосипеды.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 02:20 
> Героическое преодоление трудностей начинается когда какой-то имбецил начинает полагать
> что система где есть только один Единственно Правильный Вариант (tm) -
> это круто.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 24-Ноя-12 16:12 
>> Героическое преодоление трудностей начинается когда какой-то имбецил начинает полагать
>> что система где есть только один Единственно Правильный Вариант (tm) -
>> это круто.
> Если он отлично тюнится под абсолютное большинство задач (например, на уровне флагов
> сборки) - то почему бы и нет?

Это называется  скриптовый язык с богатым набором библиотек.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 25-Ноя-12 00:47 
> Это называется  скриптовый язык с богатым набором библиотек.

У скриптовых языков весьма ограниченная ниша.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 25-Ноя-12 02:09 
> У скриптовых языков весьма ограниченная ниша.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено flvby1 , 27-Ноя-12 10:13 
Ты считаешь, что в веб-программировании, автоматизации и ембеддед-скриптинге питон занимает свою нишу недостойно? Питонофобия на опеннете какая-то патологическая, необоснованная. Не потрудишься ответить за свои слова и назвать несколько таких поделок?
На моем десктопе федора, на серваках редхат - ничего не тормозит, не падает, стабильность на высочайшем уровне, всюду питон. Чего не скажу о SLES, на котором при определенной конфигурации установки питон вообще в системе может отсутствовать, и вся инфраструктура написана то ли на перле, то ли на шарпе.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 27-Ноя-12 10:39 
(пожимает плечами) любая программа на питоне, которая претендует на «приложение».

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено flvby1 , 27-Ноя-12 11:21 
> (пожимает плечами) любая программа на питоне, которая претендует на «приложение».

https://en.wikipedia.org/wiki/List_of_Python_software
любая-прелюбая? :)


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 27-Ноя-12 11:25 
> любая-прелюбая? :)

любая-прелюбая. вопрос не в качестве софта, а в языке.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 25-Ноя-12 02:56 
>> Это называется  скриптовый язык с богатым набором библиотек.
> У скриптовых языков весьма ограниченная ниша.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 25-Ноя-12 03:02 
> Одна из которых - пользовательское программирование, приводящее к отличному тюнингу под абсолютное большинство задач. Unix со своим шеллом - отличный тому пример.

Кроме тех случаев, когда нужна вменяемая скорость работы и не очень высокая требовательность к ресурсам.

> Unix со своим шеллом - отличный тому пример.

Да чего уж там, лучше сразу Java взять. Идеальный пример.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 25-Ноя-12 03:05 
>> Одна из которых - пользовательское программирование, приводящее к отличному тюнингу под абсолютное большинство задач. Unix со своим шеллом - отличный тому пример.
> Кроме тех случаев, когда нужна вменяемая скорость работы и не очень высокая
> требовательность к ресурсам.

Скорость и ресурсы - это либки на сях. А скриптовый язык для управления.  

>> Unix со своим шеллом - отличный тому пример.
> Да чего уж там, лучше сразу Java взять. Идеальный пример.

А ява - не скриптовый язык.



"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 24-Ноя-12 03:36 
>> Линуксоиды слишком любят создавать себе трудности и героически их преодолевать.
> Героическое преодоление трудностей начинается когда какой-то имбецил начинает полагать
> что система где есть только один Единственно Правильный Вариант (tm) -
> это круто.

Интересно это выглядит при наличии одной винды с 90 % юзеров и кучей правильных путей с 2% вместе взятыми.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 04:08 
не знаю про что вы, но про цифры —
вы всё ещё верите в леммингов?
или что олигархи — это подавляющее большинство населения?
или что они цвет этого населения?
и каждый лемминг может стать президентом? (сша, а вы про что подумали?)

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 04:42 
> не знаю про что вы, но про цифры —
> вы всё ещё верите в леммингов?

Лемминги определяют бытие.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 05:10 
для лисиц.
в любом случае последние не выбирают тоже, что и первые.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Капитан , 24-Ноя-12 13:36 
Вы не понимаете смысл выражения Not Invented Here. Оно не значит, что раз придумали не мы, значит овно и надо его троллить. Оно значит, что раз придумали не мы, значит мы придумаем свой велосипед/аналог.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 24-Ноя-12 13:48 
> раз придумали не мы, значит мы придумаем свой велосипед/аналог.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 22:06 
> …попутно рассказав, какие все остальные дураки и почему именно этот новый велосипед
> крут.

Зачем? Это докажут сами "остальные", когда начнут копипастить "ненужный велосипед".


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 25-Ноя-12 02:51 
а что ж у него истерика-то такая? ведь его велосипед однозначно круче, правда? ну, и пусть копипастят — всё равно портеровелосипед должен выиграть, yep? ан нет: сразу заистерил. «раскол, ужас, мрак, спасайся кто может!» не потому ли, что сам хорошо знает, насколько квадратные колёса у его велосипеда, а?

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 25-Ноя-12 02:54 
Выигрыш, разумеется, определяется не тем, у кого велосипед круче. А тем, кто свой велосипед лучше впаривает хомячкам. И тут леннарт понимает, что ему против признанных чемпионов не светит ровным счетом ничего.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 25-Ноя-12 03:24 
учитывая, что за ним стоит RH… «не светит» скорее бубунте. которая останется одна со своим апстартом (неплохой штукой, замечу; на n900 например %-).

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 25-Ноя-12 08:33 
И андроид, и кастомеры rhel6.

Зыж
И похреннинг не синоним рх.
Может к выходу rhel7 всё тыщу раз изменится.
Особенно если сабж удачно сопрёт лучшее, оставив худшее.
Менять систему инициализации в каждой версии та ещё работёнка.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 22:02 
> systemd это смешение всего-всего по принципу:
> if(!nih(x))
>   make_part_of_systemd(x);
> else
>   troll(x);

Это же принцип разработки upstart, всего-навсего.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 24-Ноя-12 22:41 
> Это же принцип разработки upstart, всего-навсего.

Это принцип разработки вообще. Гораздо чаще пишут то, что уже есть, а не то, чего ещё нет. Проще и похвастаться есть чем.



"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 22:59 
Но иногда - в этом есть смысл (например, технически очень сложно портировать существующие решения на нужную платформу), а иногда - нет (казалось бы, бери и портируй - так нет, тащат по кирпичику).

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 24-Ноя-12 23:19 
> Но иногда - в этом есть смысл (например, технически очень сложно портировать
> существующие решения на нужную платформу),

В этом случае это уже не разработка того, что уже есть. Ну и да, эмуляторы ( необязательно железа) рулят.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 24-Ноя-12 14:04 
> Архитектура systemd - это разделение. Кода и конфигурации, системных настроек и пользовательских.

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

> За что его, собственно, так и ненавидят

За отсутствие этой самой архитектуры.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 24-Ноя-12 21:48 
>Там давно уже к тьюринг-полноте языка идет, а ты все в INI-формат веришь.

показываешь конструкцию условия, или слил


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 22:00 
> показываешь конструкцию условия, или слил

Условия там есть. А вот циклов нет и не будет (хотя очень просили).


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 25-Ноя-12 01:58 
>> показываешь конструкцию условия, или слил
> Условия там есть. А вот циклов нет и не будет (хотя очень просили).

Это *пока* там циклов не сделали.  Но держу пари, что таки - будут.

Тем более раз "народ просит".



"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 25-Ноя-12 02:58 
> Это *пока* там циклов не сделали.  Но держу пари, что таки - будут.
> Тем более раз "народ просит".

Держу пари, что нет. Учитывая, сколько мата леннарт обрушил на головы "народа". Кажется, там было что-то про "засуньте свой гoвнокод обратно в свой сpаный sysvinit, нужно выполнить какие-то сложные операции - этим должен заниматься демон и хелпер".


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 25-Ноя-12 03:05 
> этим должен заниматься демон и хелпер

следующим логичным шагом будет выкидывание системд.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 25-Ноя-12 01:57 
>>Там давно уже к тьюринг-полноте языка идет, а ты все в INI-формат веришь.
> показываешь конструкцию условия

ConditionBlaBla и их комбинации.

> или слил

Ух какой суровый...  Иди уроки выучи.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 25-Ноя-12 14:29 
> ConditionPathExists=, ConditionPathExistsGlob=,
> ConditionPathIsDirectory=, ConditionPathIsSymbolicLink=,
> ConditionPathIsMountPoint=, ConditionPathIsReadWrite=,
> ConditionDirectoryNotEmpty=, ConditionFileNotEmpty=,
> ConditionFileIsExecutable=, ConditionKernelCommandLine=,
> ConditionVirtualization=, ConditionSecurity=,
> ConditionCapability=, ConditionHost=, ConditionNull=
> Before starting a unit verify that the specified
> condition is true. If it is not true the starting of the
> unit will be skipped

и это тьюринг полнота? Обычные фильтры на выполнимость конкретного юнита. Даже факториал на этом не посчитать.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 25-Ноя-12 15:09 
> и это тьюринг полнота?

нет, это вообще атомный ужас.

ничего, скоро портеринг поймёт, что пора вводить свой скриптовый язык, а то дофига всяких «condition» получается. а у sh — как обычно — есть Фатальный Недостаток.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 25-Ноя-12 16:21 
> и это тьюринг полнота?

Где я писал про полноту?  Но к тому дело идет, да.

> Обычные фильтры на выполнимость конкретного юнита.

Обычные, конечно.  О, сколько их вас, бедных, ждет еще, откройте TODO (ConditionBatteryPower, etc...).

Есть и "необычные", напр. ExecStartPre/ExecStartPost.  Статус проверяется.  А не за горами и специальная финтифлюшка для таких общих случаев (~ ConditionExec):
http://lists.freedesktop.org/archives/systemd-devel/2011-Aug...

Еще вам должно нравиться 100500 вариантов синтаксиса значений параметров.  Там и "-", и "!", и чего только нет.  Тяжко вам будет (это вам не /bin/sh с man-ом на пару страниц!), а документацию вы читать не привыкли...


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 25-Ноя-12 17:38 

> Обычные, конечно.  О, сколько их вас, бедных, ждет еще, откройте TODO
> (ConditionBatteryPower, etc...).

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



"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 25-Ноя-12 19:32 
>> Обычные, конечно.  О, сколько их вас, бедных, ждет еще, откройте TODO
>> (ConditionBatteryPower, etc...).
> Ограниченный, пусть и большой

Чем он ограничен?  Подскажите, пожалуйста - сам автор понятия не имеет.  Моча в голову ударила - ввел новый ConditionXYZ.

>  декларативных функций

WTF?

Кстати, декларативным программированием там и не пахнет, особенно всякие ExecStartPre/Post...

> - это проще, чем неограниченное богатство императивного кода

Чем проще-то?  Вместо использования штатных утилит и if test -b foo; then ... - теперь пишем...

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

> на примитивном языке даже без комментариев

В POSIX-shell нету комментариев?!  Отсыпьте.

> который ещё отлаживать надо.

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

Вот стала-ли она проще с приходом systemd - большой вопрос.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 25-Ноя-12 20:52 
>Кстати, декларативным программированием там и не пахнет, особенно всякие ExecStartPre/Post...

Переменные где? Без них программирование уже не императиво.

> Чем проще-то?  Вместо использования штатных утилит и if test -b foo;
> then ... - теперь пишем...

А за короткие формы ключей в скриптах вообще гнать поганой метлой.

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

Ну да, а при чтении разгадывание всяких "-b -c 2 -d 12 -e no" возможно без документации.

>> на примитивном языке даже без комментариев
> В POSIX-shell нету комментариев?!  Отсыпьте.

Код без комментариев, а не язык.

>> который ещё отлаживать надо.
> Ага.  systemd-юниты сами взлетают, а месиво из багов "а у меня
> этот ваш сервис не стартует" - всем снится...  Не смотрите
> в багтрекеры дистрибутивов, чтобы не испытать культурный шок.  Отладка необходима.

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

> Вот стала-ли она проще с приходом systemd - большой вопрос.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 25-Ноя-12 22:58 
>>Кстати, декларативным программированием там и не пахнет, особенно всякие ExecStartPre/Post...
> Переменные где? Без них программирование уже не императиво.

"Я щитаю" забыли добавить?  Или даже про makefile нынешние школьники уже не знают?

>> Чем проще-то?  Вместо использования штатных утилит и if test -b foo;
>> then ... - теперь пишем...
> А за короткие формы ключей в скриптах вообще гнать поганой метлой.

Эти короткие ключи знает любой администратор, утилита test - часть POSIX.  И в качестве ликбеза: у нее *нет* иных форм ключей, кроме "коротких".

>> А слабо вспомнить *что* пишем без заглядывания в леннартову шпаргалку?
> Ну да, а при чтении разгадывание всяких "-b -c 2 -d 12
> -e no" возможно без документации.

Ну да.  Но вам персонально не разрешили заглянуть только в маны systemd.  Что, решения таки не нашли - а как же "проще"?

>>> на примитивном языке даже без комментариев
>> В POSIX-shell нету комментариев?!  Отсыпьте.
> Код без комментариев, а не язык.

Может проблема в ком-то, кто не оставлял комментариев в неочевидных местах?  В конфигах systemd картина должна быть абсолютно аналогичная, что тут изменится?  С той лишь разницей, что пока практикующие администраторы с shell худо-бедно знакомы, а в конфигах systemd будут разбираться "с нуля" (коли предшественники вдруг оставят такой "подарочек").

Уж на что mysql-конфиги больше походят на "INI-файлы", а и там без комментариев - смерть.  Или вы в качестве необходимых воспринимаете только копипасты из мана (а-ля php.ini), чтобы буратину была понятна роль данной опции в общих чертах?  Так это для детишков...

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

Жуть какая, завязывайте с этой дурью - курите что-то послабее.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 25-Ноя-12 23:20 
>  Или даже про makefile нынешние школьники уже
> не знают?

А мейкфайлы вообще причём?

> Эти короткие ключи знает любой администратор,

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

>  С той лишь разницей, что пока практикующие администраторы с shell
> худо-бедно знакомы, а в конфигах systemd будут разбираться "с нуля" (коли
> предшественники вдруг оставят такой "подарочек").

А кто опытным админам вообще приказывает использовать systemd? Это всякие кеды/гномы без него не работают. Так что это проблема десктопа, а не серверов.

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

То есть всякие sed/grep в bash-скриптах отсутствуют, да? А вместо них используются внешние парсеры?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 26-Ноя-12 01:13 
>>  Или даже про makefile нынешние школьники уже
>> не знают?
> А мейкфайлы вообще причём?

Декларативное программирование кто вспоминал?

>> Эти короткие ключи знает любой администратор,
> Не любой, а системный.

Т.е. любой.  Другим вообще нечего делать с инициализацией системы.

> А ещё есть пользователи, которым приходится администрировать свою систему.

Нет таких.  За умных это сделали создатели дистрибутива.  Глупые - никому не интересны.

>>  С той лишь разницей, что пока практикующие администраторы с shell
>> худо-бедно знакомы, а в конфигах systemd будут разбираться "с нуля" (коли
>> предшественники вдруг оставят такой "подарочек").
> А кто опытным админам вообще приказывает использовать systemd?

Речь о другом шла.

> Это всякие кеды/гномы без
> него не работают.

Работают.  Пока.

> Так что это проблема десктопа, а не серверов.

Вообще-то, оно позиционируется как "всюду и везде", а не просто "еще одна замена иниту для домохозяек".

>>> Альтернатива - парсить регекспами тексты на естественном языке ( другого, увы, консольные
>>> утилиты не умеют, до протоколов их разработчики не доросли), а это так просто.
>> Жуть какая, завязывайте с этой дурью - курите что-то послабее.
> То есть всякие sed/grep в bash-скриптах отсутствуют, да? А вместо них используются
> внешние парсеры?

Так там разные вещи используются.  Вон, вам утилиту test показали - никаких sed/grep.  И умеет кучу того, что в systemd переименовали во всякие ConditionXYZ.  А для чего и где sed/grep используется - там и с systemd они будут, во всяких ExecStartPre...


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 01:48 
> Декларативное программирование кто вспоминал?

И?

> Т.е. любой.  Другим вообще нечего делать с инициализацией системы.

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

> Нет таких.  За умных это сделали создатели дистрибутива.  Глупые -
> никому не интересны.

Зачем так витиевато посылать в винду, где за умных всё сделали?

>> Так что это проблема десктопа, а не серверов.
> Вообще-то, оно позиционируется как "всюду и везде", а не просто "еще одна
> замена иниту для домохозяек".

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

> Так там разные вещи используются.  Вон, вам утилиту test показали -
> никаких sed/grep.  И умеет кучу того, что в systemd переименовали
> во всякие ConditionXYZ.  

И чем принципиально набор правил отличается от test + куча ключей?

>А для чего и где sed/grep используется
> - там и с systemd они будут, во всяких ExecStartPre...

А визг не поднимется, если grep/sed заменять будут?



"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 26-Ноя-12 13:48 
>> Декларативное программирование кто вспоминал?
> И?

Ну вот оно, перед тобой.  info gmake дать почитать про переменные?

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

Отсутствие необходимости и достаточной квалификации.

>> Нет таких.  За умных это сделали создатели дистрибутива.  Глупые -
>> никому не интересны.
> Зачем так витиевато посылать в винду, где за умных всё сделали?

Почему "в винду"?  Вам ответили, что есть множество дистрибутивов.  Некоторые - вполне приличного качества.

>>> Так что это проблема десктопа, а не серверов.
>> Вообще-то, оно позиционируется как "всюду и везде", а не просто "еще одна
>> замена иниту для домохозяек".
> Какая разница, как это позиционируется? Если от этого просто избавиться, то проблем
> вообще нет. К Гному/кедам прибивают это гвоздями. А на серверах-то какие проблемы?

Народ опасается, что сабж сделают системой инициализации по-умолчанию.

>> Так там разные вещи используются.  Вон, вам утилиту test показали -
>> никаких sed/grep.  И умеет кучу того, что в systemd переименовали
>> во всякие ConditionXYZ.
> И чем принципиально набор правил отличается от test + куча ключей?

Все вам уже написали чем.  А в данном случае - речь шла вообще о другом.  О том, что "никаких sed/grep".

>>А для чего и где sed/grep используется
>> - там и с systemd они будут, во всяких ExecStartPre...
> А визг не поднимется, если grep/sed заменять будут?

Дубина, о том и речь - никто их там заменять не будет и не собирается.  Мало-мальски нетривиальные случаи - запихнут в скрит и пихнут его в эту опцию.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 15:18 
> Ну вот оно, перед тобой.  info gmake дать почитать про переменные?

То есть, по-вашему, если из А следует Б, то из Б следует А, да?

> Отсутствие необходимости и достаточной квалификации.

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

> Почему "в винду"?  Вам ответили, что есть множество дистрибутивов.  Некоторые
> - вполне приличного качества.

Обычно винда - это синоним сложности что-то нестандартно настроить. Никсы потенциально настраиваемы всё равно, всё лишь зависит от громоздкости системы автоматизации.

> Народ опасается, что сабж сделают системой инициализации по-умолчанию.

Ой, бида, бида.

>>> Так там разные вещи используются.  Вон, вам утилиту test показали -
>>> никаких sed/grep.  И умеет кучу того, что в systemd переименовали
>>> во всякие ConditionXYZ.
>> И чем принципиально набор правил отличается от test + куча ключей?
> Все вам уже написали чем.  А в данном случае - речь
> шла вообще о другом.  О том, что "никаких sed/grep".

"И умеет кучу того, что в systemd переименовали
во всякие ConditionXYZ."

Это тогда к чему?

> Дубина, о том и речь - никто их там заменять не будет
> и не собирается.  Мало-мальски нетривиальные случаи - запихнут в скрит
> и пихнут его в эту опцию.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 26-Ноя-12 19:45 
>> Ну вот оно, перед тобой.  info gmake дать почитать про переменные?
> То есть, по-вашему, если из А следует Б, то из Б следует
> А, да?

Вам привели пример декларативного языка с "переменными".  Сколько можно тупить?

>> Отсутствие необходимости и достаточной квалификации.
> Про необходимость решать не вам.

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

> А квалификация почти целиком с языком связана.

Полная чушь.  С тем, что система иницализации запускает.

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

Это справедливо для ковыряния в носу.  Позанимайтесь чем-то полезным - и вы однажды поймете разницу.

> "И умеет кучу того, что в systemd переименовали
>  во всякие ConditionXYZ."
> Это тогда к чему?

К тому, что ваши мечты избавиться от sed/grep - не оправдались.  systemd меняет шило на мыло там, где отродясь никакого sed/grep не было.

> Нетривиальные случаи потому и нетривиальны

О, к слову приципился...

> их отдельные админы учитывать должны, а
> не разработчики системы.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 20:14 
> Вам привели пример декларативного языка с "переменными".  Сколько можно тупить?

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

> Вы каждую блондинистую секретаршу будете заставлять перебирать движок ее "лексуса" при
> "необходимости"?  

А весь мир что, делится на одминчегов и блондинистых секретарш?

> Полная чушь.  С тем, что система иницализации запускает.

Если что-то нужно просто запустить, квалификация особенно не нужна. А обработать ввод-вывод  перед запуском/остановом - это уже особенность языка.

> Это справедливо для ковыряния в носу.  Позанимайтесь чем-то полезным - и
> вы однажды поймете разницу.

Бла-бла-бла.  

>> "И умеет кучу того, что в systemd переименовали
>>  во всякие ConditionXYZ."
>> Это тогда к чему?
> К тому, что ваши мечты избавиться от sed/grep - не оправдались.  

Зато есть избавление от коротких ключей. Нет, если марсианам одна буква говорит о большем, чем полноценное слово/группа слов, то пусть и прогает на brainfuck.

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

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 26-Ноя-12 20:54 
>> Вам привели пример декларативного языка с "переменными".  Сколько можно тупить?
> Я не утверждал, что нет декларативного языка с переменными

Ах, уже вот как...

> Я утверждал, что язык без переменных уже не императивен.

А он еще без переменных?  Я бы рекоммендовал поковырять маны systemd - их там не один и синтаксис конфигов, мягко говоря, слабо формализован.

>> Вы каждую блондинистую секретаршу будете заставлять перебирать движок ее "лексуса" при
>> "необходимости"?
> А весь мир что, делится на одминчегов и блондинистых секретарш?

На тех, кто владеет знаниями и опытом для решения задачи и тех, кто не имеет этого.  

>> Полная чушь.  С тем, что система иницализации запускает.
> Если что-то нужно просто запустить, квалификация особенно не нужна.

Как минимум, потребуется прочитать документацию запускаемого.  

> особенность языка.

... Вне зависимости от всяких "языков".

>>> "И умеет кучу того, что в systemd переименовали
>>>  во всякие ConditionXYZ."
>>> Это тогда к чему?
>> К тому, что ваши мечты избавиться от sed/grep - не оправдались.
> Зато есть избавление от коротких ключей.

Так длинный-то вы как раз и не вспомнили.  И в чем выгода?

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

Да нет, вроде.  Например?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Michael Shigorin , 27-Ноя-12 00:43 
> Я не утверждал, что нет декларативного языка с переменными, которые, кстати,  
> "ленивые" и используются как константы.

И опять соврали (hint: := vs =).

> Я утверждал, что язык без переменных уже не императивен. Сколько можно тупить?
> Приводите уж тогда императивный язык без переменных.

Ну так не тупите.  Язык, который будет позволять выполнять указанную последовательность действий и не использовать переменные, будет вполне себе императивным.

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

Видите ли, должностные обязанности unix shell давным-давно устаканились.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 27-Ноя-12 01:05 
> Ну так не тупите.  Язык, который будет позволять выполнять указанную последовательность
> действий и не использовать переменные, будет вполне себе императивным.

Тогда Пролог императивный.

>Видите ли, должностные обязанности unix shell давным-давно устаканились.

Где вы unix-shell увидели? Или оболочка у вас только с bash ассоциируется, а тот же пайтон ей стать не может?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 27-Ноя-12 02:33 
>>Видите ли, должностные обязанности unix shell давным-давно устаканились.
> Где вы unix-shell увидели?

Там где вами написано "должны на уровне шелла реализовываться".  В unix есть стандарты, в т.ч. и для командной оболочки.  Совместимость и все такое прочее.  Питон - увы.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 27-Ноя-12 03:26 
>>>Видите ли, должностные обязанности unix shell давным-давно устаканились.
>> Где вы unix-shell увидели?
> Там где вами написано "должны на уровне шелла реализовываться".  В unix
> есть стандарты, в т.ч. и для командной оболочки.  Совместимость и
> все такое прочее.  Питон - увы.

Совместимость с чем? Напоминаю, речь про десктоп,а оболочкой пользоваться будет пользователь, а не админ/программист.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 27-Ноя-12 13:51 
> Совместимость с чем? Напоминаю, речь про десктоп,а оболочкой пользоваться будет пользователь,
> а не админ/программист.

Со стандартами unix, начиная с POSIX.  Десктоп - тоже unix, просто марьванна это знать не обязана, а мейнтейнеры дистрибутива - знают.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 27-Ноя-12 07:59 
> а тот же пайтон ей стать не может?

show me. и не только питоношелл, но и тех, кто этим пользоваться будет.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 26-Ноя-12 02:49 
>  С той лишь разницей, что пока практикующие администраторы с shell
> худо-бедно знакомы, а в конфигах systemd будут разбираться «с нуля» (коли
> предшественники вдруг оставят такой «подарочек»).

добавлю, что знание sh полезно и «вне инита», а знание системд полезно только для системд.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 22:05 
> Ох, мартышко...   Там давно уже к тьюринг-полноте языка идет, а ты все в INI-формат веришь.

А чего в него верить? Конфиги systemd - это чистый INI, и никакой тьюринг-полноты там никогда не будет - by design. Только настройки.

> За отсутствие этой самой архитектуры.

Докажи или слил.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 25-Ноя-12 02:08 
>> Ох, мартышко...   Там давно уже к тьюринг-полноте языка идет, а ты все в INI-формат веришь.
> А чего в него верить?

Не знаю, я не обязан объяснять причины вашей веры.  "Кто верит в Магомета, кто в Аллаха, кто в Иисуса..." (ц)  Вера тем и отличается от знания, что иррациональна.

> Конфиги systemd - это чистый INI

Ну-ну...

> Докажи или слил.

Докажите отсутствие Чайника Рассела сперва, вьюнош.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 25-Ноя-12 03:00 
> Не знаю, я не обязан объяснять причины вашей веры.  "Кто верит
> в Магомета, кто в Аллаха, кто в Иисуса..." (ц)  Вера
> тем и отличается от знания, что иррациональна.

А кто-то - что в ненавистных лично ему (по религиозным соображениям) программах нет архитектуры. Или что INI - это не INI, а нечто иное (и 2*2<>4, ага).


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 25-Ноя-12 15:41 
> А кто-то - что в ненавистных лично ему программах нет архитектуры.

Ну вот и предъявите ее наличие.  Вам говорят что ее нет потому, что ее нет.

"О, а вот это тоже крутая идея, давай приделаем!" - это не архитектура системного ПО, это балаган.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Пиу , 24-Ноя-12 14:58 
>Надеюсь, тоже станет стандартом через пару лет.

молюсь Линусу чтобы не стало


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено kai , 23-Ноя-12 23:15 
Мне это больше setup.exe напоминает.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 23-Ноя-12 23:41 
это бандлы чистой воды из макоси.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 23-Ноя-12 23:45 
> как вообще это можно сравнивать с виндой, не понимаю. с её длл-
> и регистри-хэлл…
> не давно за комп сели что ли…

DLL hell вроде как в комплекте.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 23-Ноя-12 23:52 
с чем?

зыж
чтоб чуть понятнее было (для новичков) — DLL hell, это не когда их много, разных версий и в разных местах.
А когда разное ПО требует записать в один и тот же файл разные версии библиотеки.
например, есть библа c:/winda/system32/jopa.dll. Программа vagina.exe требует эту библу версии 1.0, а piston.exe — 3.3.
При этом в этих версиях и разные АБИ, и АПИ.

Сабж проблему dll hell решает.
(но только её :D)


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 00:24 
> Сабж проблему dll hell решает.

Смотря в каком смысле. Если тягается 100500 версий либы там и тут - не очень понятно кто захочет заниматься обновлением всего этого убер-мега-срача.



"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 00:32 
в любом.
хэлл — это хэлл. с падением в корку, матюгами, переустановками винды и тд, и тд.
а хочу—не_хочу — это к соседней блондинке.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 24-Ноя-12 02:13 
>Смотря в каком смысле. Если тягается 100500 версий либы там и тут - не очень понятно кто захочет заниматься обновлением всего этого убер-мега-срача.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 02:19 
>>Смотря в каком смысле. Если тягается 100500 версий либы там и тут - не очень понятно кто захочет заниматься обновлением всего этого убер-мега-срача.
> Пакетный менеджер понимаешь как работает, или таки махровый вендузятник?

А кто сказал, что _это_ будет работать как нормальный пакетный менеджер?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 24-Ноя-12 02:41 
Сабж:
>Контроль зависимостей.

 


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 08:28 
>А кто сказал, что _это_ будет работать как нормальный пакетный менеджер?

Ричард сказал.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 25-Ноя-12 00:45 
Да он много чего говорит, да его сотрудники все не так делают.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 02:32 
> чтоб чуть понятнее было (для новичков) — DLL hell, это не когда их много, разных версий и в разных местах.
> А когда разное ПО требует записать в один и тот же файл разные версии библиотеки.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 04:12 
нет. если рассматривать только в плане дллхэлл, то сабж — это костыль для борьбы с ним.
как и бындлы в макос.
как и дллкэш в винде.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 16:48 
А что тогда не костыль? (вопрос риторический, но можете ответить с примером - интересно будет посмотреть)

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 02:41 
С грехом попалам родили костыль http://en.wikipedia.org/wiki/Side-by-side_assembly

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 04:25 
ага :D
а потом и сами офигели
>Microsoft Visual C++ 2005 and 2008 employ SxS with all C runtime libraries. However, runtime libraries in Visual C++ 2010 no longer use this technology; instead, they include the version number of a DLL in its file name

посмотрели на линух и поняли, от этой хрени больше проблем, давай делать как в линухе.
а вот это вообще жесть:
>Disadvantages
>* Only supported on Windows XP and later. In Windows XP, a bug in sxs.dll causes heap corruption, leading to application crashes. This issue is not fixed by any XP service packs. Users must manually install a QFE (Quick Fix Engineering).
>* Considerably higher disk space consumption. The winsxs directory typically starts at several gigabytes in size and continues to grow as applications are installed. Further, there is currently no supported way to significantly reduce the size of the winsxs directory.

и после этого ещё на линух кто-то из них вякать смеет? :D


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 24-Ноя-12 11:29 
а причем тут линукс? В нём единственный способ борьбы с dll-hell -- это меинтейнер. И единственное, что спасает линукс от dll-hell -- нехватка проприетарных программ.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 15:32 
>а причем тут линукс?

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 20:20 
>да у тебя дофига аргументации. Но в итоге выходит, что проприетарщина бывает или:
>1) всё в одном бинарном блобе(skype)

да, дофига. потому что любой, кто хоть сколько-нибудь знаком с вопросом знает:
$ ldd /opt/bin/skype
    linux-gate.so.1 (0xffffe000)
    libasound.so.2 => /usr/lib32/libasound.so.2 (0x42388000)
    libXv.so.1 => /usr/lib32/libXv.so.1 (0x43541000)
    libXss.so.1 => /usr/lib32/libXss.so.1 (0x42163000)
    librt.so.1 => /lib32/librt.so.1 (0x41d92000)
    libdl.so.2 => /lib32/libdl.so.2 (0x41c24000)
    libX11.so.6 => /usr/lib32/libX11.so.6 (0x41e45000)
    libXext.so.6 => /usr/lib32/libXext.so.6 (0x420ea000)
    libQtDBus.so.4 => /usr/lib32/qt4/libQtDBus.so.4 (0x4230f000)
    libQtXml.so.4 => /usr/lib32/qt4/libQtXml.so.4 (0x42699000)
    libQtGui.so.4 => /usr/lib32/qt4/libQtGui.so.4 (0x427e8000)
    libQtNetwork.so.4 => /usr/lib32/qt4/libQtNetwork.so.4 (0x42449000)
    libQtCore.so.4 => /usr/lib32/qt4/libQtCore.so.4 (0x43278000)
    libpthread.so.0 => /lib32/libpthread.so.0 (0x41c2a000)
    libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/32/libstdc++.so.6 (0xf7610000)
    libm.so.6 => /lib32/libm.so.6 (0x41bfb000)
    libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/32/libgcc_s.so.1 (0xf75f4000)
    libc.so.6 => /lib32/libc.so.6 (0x41a5b000)
    /lib/ld-linux.so.2 (0x41a39000)
    libxcb.so.1 => /usr/lib32/libxcb.so.1 (0x41e29000)
    libdbus-1.so.3 => /usr/lib32/libdbus-1.so.3 (0x4218d000)
    libglib-2.0.so.0 => /usr/lib32/libglib-2.0.so.0 (0x41c62000)
    libpng15.so.15 => /usr/lib32/libpng15.so.15 (0x41f64000)
    libz.so.1 => /lib32/libz.so.1 (0x41be4000)
    libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0x41ff3000)
    libgobject-2.0.so.0 => /usr/lib32/libgobject-2.0.so.0 (0x41d9d000)
    libSM.so.6 => /usr/lib32/libSM.so.6 (0x42159000)
    libICE.so.6 => /usr/lib32/libICE.so.6 (0x421ce000)
    libXrender.so.1 => /usr/lib32/libXrender.so.1 (0x41fd7000)
    libXrandr.so.2 => /usr/lib32/libXrandr.so.2 (0x41fcd000)
    libXinerama.so.1 => /usr/lib32/libXinerama.so.1 (0x427a5000)
    libfontconfig.so.1 => /usr/lib32/libfontconfig.so.1 (0x41f90000)
    libgthread-2.0.so.0 => /usr/lib32/libgthread-2.0.so.0 (0x41d7d000)
    libXau.so.6 => /usr/lib32/libXau.so.6 (0x41d6e000)
    libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0x41d84000)
    libbz2.so.1 => /lib32/libbz2.so.1 (0xf75e0000)
    libffi.so.5 => /usr/lib32/libffi.so.5 (0x41d74000)
    libuuid.so.1 => /lib32/libuuid.so.1 (0x42149000)
    libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf75b5000)

зыж
ещё раз повторю:
>>1) всё в одном бинарном блобе(skype)

БРЕХНЯ


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 22:07 
>я с тебя фигею. Какое отношение вывод ldd имеет к dll-hell?

а я с тебя.
никакого отношения не имеет.
зато имеет отношение к твоей брехне ­— «1) всё в одном бинарном блобе(skype)» — ldd доказал что ты врёшь.
>Я говорил про либы которые софт таскает с собой. Разумеется, что нет привнесённых либ -- нет и dll-hell.

т.е. вот так вот неуклюже ты хочешь сказать, что skype НЕ таскает либы в себе? :D

зыж
ещё раз повторю, в linux вагон и маленькая тележка разруливать dll-hell.
гораздо больше, чем в винде. в этом плане винда сак бай дезигн.
задумайся, на том же примере:
>libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/32/libstdc++.so.6 (0xf7610000)
>libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/32/libgcc_s.so.1 (0xf75f4000)

скайп сцуко знал, что у меня gcc 4.5.4, угу! :D


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Michael Shigorin , 25-Ноя-12 20:01 
> да, дофига. потому что любой, кто хоть сколько-нибудь знаком с вопросом знает:

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

http://wiki.opennet.ru/MSSP


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 25-Ноя-12 21:18 
и где это я выгораживаю винду? она служит наглядным примером того, где dll-hell есть. следовательно с ней надо сравнивать, точка

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 24-Ноя-12 02:06 
>Мне это больше setup.exe напоминает.

Потому что ты ничего кроме setup.exe  не знаешь


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Ilya , 23-Ноя-12 23:17 
Пакеты оформляются в виде самодостаточных контейнеров, содержащих все необходимые для их работы зависимости и компоненты

It's Windows system.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 23-Ноя-12 23:31 
> It's Windows system.

It's GNU system!


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 23-Ноя-12 23:42 
да-да, про вида\систем32 типа того никто не слышал.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 00:25 
> да-да, про вида\систем32 типа того никто не слышал.

Это скорее Program Files/Your Program Name


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 00:50 
да уж куда скорее то.
спутать пакетный менеджер с самопальным setup.exe (порождённый больной фантазией создателя), позволяющим менять системные библиотеки в system32 (винда правда сейчас любезно спрашивает — а вы уверены? да х/з, мля!!! я что-ли этот крап писал?) — на это способен только гуманитарий на отдыхе.
так что вы уж медленно разберитесь что такое сабж, что такой бандлы в макос и чем они отличаются от винды.
вот на досуге:
http://developer.apple.com/library/mac/documentation/CoreFou...
начать тут http://en.wikipedia.org/wiki/Application_bundle
ну и ссылки к сабжу.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 26-Ноя-12 15:43 
> начать тут http://en.wikipedia.org/wiki/Application_bundle

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

А проблема одна и та же остается: всем похрен на 100500 устаревших либ и их баги, глюки и просто дыры, исправленные в новых версиях.

Упомянутая штука будучи пакетным менеджером может потенциально справиться с проблемой, но т.к. провоцирует велосипедизмы - обладает повышенной вероятностью грабель. И собственно shared libs по идее должны шариться. А зачем мне независимая копия кутей на ...цать мегов в каждой кутевой программе? И в памяти - аналогично.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено тоже Аноним , 23-Ноя-12 23:43 
А еще представилось окошко: сегодня интернет будет очень медленным, мы все обновляемся...

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 24-Ноя-12 02:09 
> Пакеты оформляются в виде самодостаточных контейнеров, содержащих все необходимые для
> их работы зависимости и компоненты
> It's Windows system.

It's a wrong translation.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено чвс , 23-Ноя-12 23:21 
Прочитав последний абзац понял что это полный абзац. Да здравствует виндапакет, всё своё тащу с собой и ставлю в папку пользователя. Мне как раз нравилось что, ничего не дублировалось. А главное ещё один язык программирования, их так мало, давайте для каждой утилиты свой писать )

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 23-Ноя-12 23:27 
Насколько я понял все несколько иначе. Пакет тащит за собой все зависимости в виде пакетов, пакеты _одной и той же_ версии не дублируются.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено тоже Аноним , 23-Ноя-12 23:45 
Не очень понятно, зачем вокруг этого дистрибутива еще какой-то дистрибутив.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 04:41 
> Не очень понятно, зачем вокруг этого дистрибутива еще какой-то дистрибутив.

Сейчас нынче модно всем писать свои ОС. Вот гнушники не отстают - давно уже GNU OS собираются выпустить.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Капитан , 24-Ноя-12 11:43 
> давно уже GNU OS собираются выпустить.

Вообще-то, с рождения собираются.


"gnu os"
Отправлено hater , 24-Ноя-12 12:29 
вылазь из танка, GNU - это и есть OS. с ядром hurd заминка вышла, но Линус со своим  подсобил. Теперь вот решили сделать пакетный менеджер...

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 23-Ноя-12 23:47 
> Насколько я понял все несколько иначе. Пакет тащит за собой все зависимости
> в виде пакетов, пакеты _одной и той же_ версии не дублируются.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 23-Ноя-12 23:57 
К хранилищу нет доступа у обычных пользователей. То что сабж не требует рута не значит что работает под текущим пользователем, там демон есть со своим аккаунтом для манипуляций с общим хранилищем, а то что установлено пользователем к себе в ~, как подсказывает КО, других не коснется.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 00:49 
> К хранилищу нет доступа у обычных пользователей. То что сабж не требует
> рута не значит что работает под текущим пользователем, там демон есть
> со своим аккаунтом для манипуляций с общим хранилищем,

Это звучит уже более разумно.

> а то что установлено пользователем к себе в ~, как подсказывает КО, других не коснется.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 24-Ноя-12 02:30 
>Лучше бы вообще такую возможность отрубить нафиг. Спам-боты, досеры и бэкдоры прекрасно работают и от юзера. А бэкдор еще и дает возможность удаленно потестить сплойты на рута.

Только причём здесь менеджер пакетов GNU? Столман Linlock зашлёт?
Возможно имеет имеет смысл запретить запуск программ из /home кроме тех, которые установил менеджер.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 02:33 
> Только причём здесь менеджер пакетов GNU? Столман Linlock зашлёт?
> Возможно имеет имеет смысл запретить запуск программ из /home кроме тех, которые
> установил менеджер.

Юзер его сам словит, зачем дядьку РМС этим грузить.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 24-Ноя-12 02:50 
GNU Guix то причём? (ещё раз)

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 04:40 
> GNU Guix то причём? (ещё раз)

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ffirefox , 24-Ноя-12 05:20 
Это как? Из разрешенных админом репозитариев и подписанных пакетов?

Наличие у пользователя возможностей ставить софт совсем не означает возможность ставить что попало и откуда попало.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 05:24 
так он же сказал что на винду похоже, значит торренты, с крэки и с смс прилагаются :D

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 24-Ноя-12 05:29 
> Это как? Из разрешенных админом репозитариев и подписанных пакетов?

remove-packages su sudo bash x11
echo "bwahaha, enjoy your cleanness!"
exit 0


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 06:10 
Password:
Sorry, try again.
Password:
Sorry, try again.
Password:
Sorry, try again.
3 incorrect password attempts

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 24-Ноя-12 06:29 
ну и какая тогда разница, от юзера или от рута? кроме той, конечно, что юзер радостно загадит систему всяким шлаком, и потом всё равно придётся откатывать.

если это корпоративная среда, то позволять юзеру ставить что попало (пусть даже из «довереных» репозиториев) бессмысленно: всё, что ему надо для работы, у него уже должно стоять. если ему чего-то не хватает, то по заявке админ доставит, проверив, чтобы оно не было косячным и более-менее зная, как разруливать, если чо.

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

итого: какой сценарий использования-то? кроме загаживания хомяка ерундой (и да, /home *у юзера* без noexec? are you serious?).

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Пр0х0жий , 27-Ноя-12 12:35 
> ну и какая тогда разница, от юзера или от рута? кроме той,
> что юзер радостно загадит систему всяким шлаком, ...

:)
Точно.

> итого: какой сценарий использования-то?
> кроме загаживания хомяка ерундой (и да, /home *у
> юзера* без noexec? are you serious?).

С этим exec, оно без Guix загаживается.
Например разворачивая тарболы с ftp.mozilla.org/pub/ к себе в home.
Чтоб обновлялось автоматом.
Или нечто подобным.
Таких инструкций на трекерах, развернуть архив с бинарным кодом в home, пруд-пруди.
Да и без Guix и трекеров, дефолтом в home и не глядя, можно затолкать всё что угодно:

Install
the game into a directory below your home directory (the default location of
~/.megaglest is fine)


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 24-Ноя-12 10:49 
>> GNU Guix то причём? (ещё раз)
> Например, так: словленный юзером в браузере сплойт запускает guix (так как его
> можно запускать от имени пользователя), и подтягивает через него свои компоненты
> в систему.

Не в систему, а куда-то в /home/username/.Guix-profile.
И только зарегистрированные рутом пакеты.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Michael Shigorin , 25-Ноя-12 20:04 
> Например, так: словленный юзером в браузере сплойт запускает guix (так как его
> можно запускать от имени пользователя), и подтягивает через него свои компоненты
> в систему.

Да, куда там нынешнему сплойту без libGL или libmysqlclient...


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 26-Ноя-12 15:45 
> Возможно имеет имеет смысл запретить запуск программ из /home кроме тех, которые
> установил менеджер.

А как их отличать предлагается?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Пр0х0жий , 26-Ноя-12 18:12 
> Возможно имеет имеет смысл запретить запуск программ из /home кроме тех, которые
> установил менеджер.

Т.е. всё-таки держать исполняемый код в хомяке?
Это конечно сильно...
:)


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 23-Ноя-12 23:46 
это не виндапакет (как вы выражаетесь). и даже близко не валялся.
ау, что вообще гуманитарии делают на этом ресурсе?

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено sasa , 24-Ноя-12 01:28 
>  А главное ещё один язык программирования

Guile is the GNU Ubiquitous Intelligent Language for Extensions, __the official extension language for the GNU operating system__.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 04:44 
> Guile is the GNU Ubiquitous Intelligent Language for Extensions, __the official extension
> language for the GNU operating system__.

Кстати, а какой официальный язык в GNOME operating system? Тоже марсианский?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 25-Ноя-12 16:10 
Scheme - это диалект Лиспа, неуч. Когда появился Лисп, никаких сей, питонов и жабы даже в проекте не было

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Michael Shigorin , 25-Ноя-12 20:08 
> Scheme - это диалект Лиспа, неуч.

Кстати, если вдруг здесь окажутся любители похакать инсталятор на схеме -- в альте ровно так и обстоит (altlinux.org/alterator). :)


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 25-Ноя-12 21:37 
>  Когда появился Лисп, никаких сей, питонов
> и жабы даже в проекте не было

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 26-Ноя-12 03:08 
быдлокодеров всегда было больше, чем программистов. вот и написали 100500 перделок.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 03:36 
> быдлокодеров всегда было больше, чем программистов. вот и написали 100500 перделок.

Это да. В IT вообще какая-то несправедливость: в подавляющем большинстве случаев быдлокодеры пишут быдлокодкод для быдлоюзеров. А Программисты, пишущие Код - штучный товар. Как и Юзеры. Очевидно, что и тот лиспобыдлокод, который мы имеем возможность наблюдать сейчас, написан быдлокодерами того времени, и используется современными быдлоюзерами, а Настоящие  Лисп-Программы от Настоящих Лисп-Программистов для Настоящих Юзеров затерялись среди этих отбросов.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 26-Ноя-12 03:53 
«того» лиспокода мы не наблюдаем, потому что лисп-машины сыграли на мусорку.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 15:28 
> «того» лиспокода мы не наблюдаем, потому что лисп-машины сыграли на мусорку.

Беда. А "этот" лиспокод и на обычных компах пишут, ну что за несправедливость.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 26-Ноя-12 13:55 
>> быдлокодеров всегда было больше, чем программистов. вот и написали 100500 перделок.
> Это да. В IT вообще какая-то несправедливость: в подавляющем большинстве случаев быдлокодеры
> пишут быдлокодкод для быдлоюзеров.

Про качество и количество софта - вы очень верно, несмотря на желаемую иронию...

> Настоящие  Лисп-Программы от Настоящих Лисп-Программистов для Настоящих
> Юзеров затерялись среди этих отбросов.

Да нет.  До сих пор лисп-языки лидируют в определенных областях, где эти "Лисп-Программы" может назвать каждый.  Но передо мной, видимо, очередной PHP-гуру веб-программирования...  Вот вы и не вкурсе.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 26-Ноя-12 19:49 
>> Да нет.  До сих пор лисп-языки лидируют в определенных областях, где
>> эти "Лисп-Программы" может назвать каждый.
> Но пихают их везде и всюду.

Где?  Scheme - стандартный язык расширения для GNU.  Был и остается.

Больше сфер, где лисп мог бы затронуть среднестатистического PHP-программиста - нет, успокойтесь.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 20:17 
>>> Да нет.  До сих пор лисп-языки лидируют в определенных областях, где
>>> эти "Лисп-Программы" может назвать каждый.
>> Но пихают их везде и всюду.
> Где?  Scheme - стандартный язык расширения для GNU.  Был и
> остается.

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



"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 26-Ноя-12 20:55 
> Расширения - это уже пользовательское программирование. Мне интересно посмотреть на пользователей

Смотрите, кто мешает?  Расширения на scheme доступны точно так же, как и остальной код приложений...


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 21:23 
>> Расширения - это уже пользовательское программирование. Мне интересно посмотреть на пользователей
> Смотрите, кто мешает?  Расширения на scheme доступны точно так же, как
> и остальной код приложений...

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Michael Shigorin , 26-Ноя-12 21:28 
> Так не вижу я этих расширений на схеме.

Надо же, а я как гимп запускаю -- так снова вижу.

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

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

PS: #276 пришлось удалить как масло в флейм; что до формализации вывода утилит -- прошу посмотреть POSIX и SUSv3, чтоб не вводить общественность в заблуждение (это _не_ полная и не однозначная в некоторых случаях спецификация, но тем не менее всё гораздо лучше, чем спецификация реализацией, как в некоторых других местах).


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 21:36 
> PS: #276 пришлось удалить как масло в флейм;

А вы отредактируйте или ткните пальцем, я вашу логику не понимаю.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Michael Shigorin , 26-Ноя-12 21:48 
>> PS: #276 пришлось удалить как масло в флейм;
> А вы отредактируйте

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

> или ткните пальцем, я вашу логику не понимаю.

"Как будто вывод Unix-утилит формализован вообще" -- неправда, о чём Вам и было сообщено отдельно.

"Программа развивается, чего вы хотите? Останется дрянью после нескольких лет - тогда поливание дерьмом обоснованно" -- попытка лезть со своим уставом в чужой монастырь: давайте мы сами разберёмся, как принимать то недоработанное, которое нам _сегодня_ пытаются влить как касторку от всех реально существующих и не вполне существующих проблем.

"То есть, по-вашему, есть только профессионалы и дилетанты?" -- передёргивание, Вам чётко сформулировали относительно _задачи_ и тут действительно вариантов ровно два, как их ни назови.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 21:55 
>>> PS: #276 пришлось удалить как масло в флейм;
>> А вы отредактируйте
> Редактирует Максим (т.е. точное сообщение звучало бы "отредактировано администратором").

Вот и попросите отредактировать его.

>[оверквотинг удален]
> поливание дерьмом обоснованно" -- попытка лезть со своим уставом в чужой
> монастырь: давайте мы сами разберёмся, как принимать то недоработанное, которое нам
> _сегодня_ пытаются влить как касторку от всех реально существующих и не
> вполне существующих проблем.
> "То есть, по-вашему, есть только профессионалы и дилетанты?" -- передёргивание, Вам чётко
> сформулировали относительно _задачи_ и тут действительно вариантов ровно два, как их
> ни назови.
> "Документацию нужно читать для использования запускаемого, и настройки, а никак не ля
> запуска" -- видимо, никогда не сталкивались со сложными штуками и пусконаладочными
> работами по ним.

На правило ссылки, пожалуйста, а не на ваше личное мнение.

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

Мы - это кто? Не слишком ли большую роль на себя берёте?


"(offtopic) модерирование на opennet"
Отправлено Michael Shigorin , 26-Ноя-12 22:48 
> Вот и попросите отредактировать его.

Порой прошу, но не в подобных случаях.

> На правило ссылки, пожалуйста, а не на ваше личное мнение.

Было в #280 -- см. http://wiki.opennet.ru/ForumHelp, п. 6 и теперь 2.  Также прошу учесть, что личное мнение [s]болвана-[/s]модератора и является тем, что применяется совместно с зафиксированными правилами в качестве руководства к (без)действию -- увы.

>> попытка лезть со своим уставом в чужой монастырь: давайте мы сами разберёмся,
>> как принимать то недоработанное
> Мы - это кто? Не слишком ли большую роль на себя берёте?

Это те, кто Вам в (офтопичном здесь) вопросе про systemd оппонирует.  Да и прочим "судящим по лору" прожигателям своего и чужого времени.


"(offtopic) модерирование на opennet"
Отправлено Анон , 26-Ноя-12 23:09 
> Да и прочим "судящим по лору" прожигателям своего и чужого времени.

Это не я тут модерирую настолько мелочные вещи, что ценитель своего времени не будет на них и внимания обращать.

>Также прошу учесть, что личное мнение [s]болвана-[/s]модератора и является тем, что применяется совместно с зафиксированными правилами в качестве руководства к (без)действию -- увы.

Это да. Но при этом он наживает себе врагов, которые в достаточном количестве не очень ему и нужны. Особенно враги безымянные и безвестные у известного человека.  А так ваше дело, конечно.


"(offtopic) модерирование на opennet"
Отправлено Michael Shigorin , 26-Ноя-12 23:41 
Испугался и убежал. :)

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 26-Ноя-12 13:13 
> И при этом на этих сях, питонах и жабе умудрились написать  100500 программ, а лисп так и остался инновационным языком и официальным  для расширений.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 26-Ноя-12 16:03 
> У каких «древних» языков красивая нотация?

у лиспа, например.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 26-Ноя-12 16:37 
> У каких "древних" языков красивая нотация? В те времена другая задача стояла - эффективность работы машины, а не человека.

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

> Скажем, по силе пиара рядом с лиспом стоит такой же красивый Tex. Тоже вроде бы древний, и хорош в своей области, но ODF сделали на xml.

По той же причине, по какой не выбрали PDF или Postscript.

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

У винды тоже вон немалая аудитория :)
Я не про размер аудитории говорю, а про то, что она есть и давно сформировалась. Кроме того, языки входят в моду и выходят из нее каждый десяток лет, а некоторые вещи остаются вечными. Лисп не вечен, но он пережил значительно больше, чем другие языки, некогда бывшие популярными, и переживет еще, и кое-кто в FSF еще помнит об этом


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 26-Ноя-12 19:51 
> А в Linux-то где инновации? Там обычная автоматизация-то не работает, ради
> которой Unix создавался. Ручная настройка и текстовые конфиги - это старьё.

Может вам не стоит выдавать ваше шапочное знакомство за мнение?

Что у вас не автоматизируется-то, болезный?  И чем автоматизации помешали текстовые конфиги?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 20:21 
> И чем автоматизации помешали текстовые
> конфиги?

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 26-Ноя-12 20:48 
>> И чем автоматизации помешали текстовые конфиги?
> Создавать их тяжко. Без типичных-то функций текстового редактора, вроде подсветки синтаксиса,
> автодополнения, контексной помощи и отладчика.

Если вам неприменно надо *руками* редактировать файлы - что мешает использовать нормальный редактор со всеми этими функциями?  Emacs, к примеру.

Только каким боком тут "автоматизация"?



"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Анон , 26-Ноя-12 21:28 
> Если вам неприменно надо *руками* редактировать файлы - что мешает использовать нормальный
> редактор со всеми этими функциями?  Emacs, к примеру.

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

> Только каким боком тут "автоматизация"?

Никаким. В исходном сообщении связи тоже нет.



"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 26-Ноя-12 21:52 
>> Если вам неприменно надо *руками* редактировать файлы - что мешает использовать нормальный
>> редактор со всеми этими функциями?  Emacs, к примеру.
> Этот редактор явно не для пользователей написан.

Вам тут уже намекнули - за всех не стоит распинаться.  Не подходит вам - не стоит делать далеко идущих выводов...

> И да, де его подсветка
> синтаксиса конфигов, с которым приходится встречаться, за исключением  наиболее популярных?

"Принеси то, не знаю что"?

>> Только каким боком тут "автоматизация"?
> Никаким. В исходном сообщении связи тоже нет.

Спрашивают не с "исходного сообщения", а с вас.  Ибо человек с вашим ником распинался за "не работающую автоматизацию" в Linux.

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


"/"
Отправлено Анон , 26-Ноя-12 22:05 
>> И да, де его подсветка
>> синтаксиса конфигов, с которым приходится встречаться, за исключением  наиболее популярных?
> "Принеси то, не знаю что"?

Ок, частный случай: функции редактора для редактирования правил udev. Редактирования xorg.conf с nvidia. Редактирование dosbox.conf

> Не наблюдаю проблем с "автоматизацией".  

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



"/"
Отправлено myhand , 26-Ноя-12 22:34 
> Ок, частный случай: функции редактора для редактирования правил udev. Редактирования xorg.conf
> с nvidia. Редактирование dosbox.conf

xorg.conf есть точно, остальное - без понятия, честно.  Смотрите в вики, может кому-то надо и кто-то выложил.

Более интересный вопрос зачем эта иллюминация...  Но, увидев ниже слово "ЛОР" - начинаю понимать.

>> Не наблюдаю проблем с "автоматизацией".
> Ну а я наблюдая, дальше  что?

Ну так и приведите пример.  А то "проблемы с автоматизацией" (sic!).    Когда всего-то у какого-то пацаненка флешка не монтируется.

> Мне тем лора на тему

Меньше всякие помойки посещайте.


"/"
Отправлено Анон , 26-Ноя-12 22:57 
> xorg.conf есть точно,

Xorg.conf с nvidia, а там куча такая ключей.

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

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

> Более интересный вопрос зачем эта иллюминация...  Но, увидев ниже слово "ЛОР"
> - начинаю понимать.

Зачем нужна подсветка синтаксиса? Да действительно, незачем. Пусть код сливается с комментариями и закомментированным кодом. Аскеты могут и в лесу жить, без компа.


>    Когда всего-то у какого-то пацаненка флешка не монтируется.

Действительно, не работает базовая автоматизация, какая мелочь.

>> Мне тем лора на тему
> Меньше всякие помойки посещайте.

Как-будто есть варианты.


"/"
Отправлено myhand , 26-Ноя-12 23:27 
>> xorg.conf есть точно,
> Xorg.conf с nvidia, а там куча такая ключей.

Читайте документацию.  Подсветка никак ее не заменит.

> Когда каждый пишет свой "парсер" вместо

В (третий?) который раз - не распинайтесь за всех и вся.

>> Более интересный вопрос зачем эта иллюминация...
> Зачем нужна подсветка синтаксиса? Да действительно, незачем. Пусть код сливается с комментариями и закомментированным кодом.

Чтобы отделить код от комментариев не нужно никакой *специальной* подсветки синтаксиса вообще.  Нужно просто научиться работать с текстовым редактором.

>>    Когда всего-то у какого-то пацаненка флешка не монтируется.
> Действительно, не работает базовая автоматизация, какая мелочь.

Это проблемы конкретного пацаненка.  Причем тут Linux?

>>> Мне тем лора на тему
>> Меньше всякие помойки посещайте.
> Как-будто есть варианты.

Есть.  Вам как раз предложили вариант.


"/"
Отправлено Анон , 26-Ноя-12 23:42 
>>> xorg.conf есть точно,
>> Xorg.conf с nvidia, а там куча такая ключей.
> Читайте документацию.  Подсветка никак ее не заменит.

Почему-то в винде и nvidia-config читать документацию не нужно - возможностей интерфейса хватает.

>> Когда каждый пишет свой "парсер" вместо
> В (третий?) который раз - не распинайтесь за всех и вся.

Загляните в код и убедитесь сами. semantic подобные модули не используют - всё пишут сами.

> Чтобы отделить код от комментариев не нужно никакой *специальной* подсветки синтаксиса
> вообще.  Нужно просто научиться работать с текстовым редактором.

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

> Это проблемы конкретного пацаненка.  Причем тут Linux?

А когда Linux при чём? Когда у всех не работает?


"/"
Отправлено Michael Shigorin , 26-Ноя-12 23:56 
>> Это проблемы конкретного пацаненка.  Причем тут Linux?
> А когда Linux при чём? Когда у всех не работает?

Когда идентифицировали баг или недостающую фичу в Linux, вестимо.


"/"
Отправлено Анон , 27-Ноя-12 00:02 
>>> Это проблемы конкретного пацаненка.  Причем тут Linux?
>> А когда Linux при чём? Когда у всех не работает?
> Когда идентифицировали баг или недостающую фичу в Linux, вестимо.

http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.de...


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено Michael Shigorin , 27-Ноя-12 00:12 
> linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current.html

И эти MSSP ещё будут мимикрировать под гентушников, да.

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

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


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено Анон , 27-Ноя-12 00:24 
>> linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current.html
> И эти MSSP ещё будут мимикрировать под гентушников, да.
> С Артёмом мы эту статью обсуждали в частном порядке; к сожалению, она
> так и представляет из себя смесь фактов, мифов, расплывчатых утверждений и
> одностороннего рассмотрения tradeoff'ов.  

Чтобы получилось что-то стоящее, это не с Артёмом обсуждать надо.

Вот, к примеру:

No unified configuration system for computer settings, devices and system services. E.g. distro A sets up networking using these utilities, outputting certain settings residing in certain file system locations, distro B sets up everything differently. This drives most users mad.

!! Two most popular open source desktops, KDE and Gnome, can configure only few settings by themselves thus each distro creates its own bicycle (applications/utilities) for configuring a boot loader/firewall/network/users and groups/services/etc.

и отсутствие нормальной возможности полноценно даже редактировать xorg.conf, обсуждаемое в данной ветке.


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено Michael Shigorin , 27-Ноя-12 00:34 
> Чтобы получилось что-то стоящее, это не с Артёмом обсуждать надо.

Если про его статью, то всё же с ним.

> Вот, к примеру:
> No unified configuration system for computer settings, devices and system services.
> E.g. distro A sets up networking using these utilities, outputting certain settings
> residing in certain file system locations, distro B sets up everything
> differently. This drives most users mad.

Про "most users" -- неудачная шутка, стандартов конфигурирования сети три штуки: /etc/sysconfig/network*, /etc/network/ и самопальные скрипты (в альте трудами и по инициативе Дениса Овсиенко была внедрена его разработка -- /etc/net -- но тем же шляпникам оказалось слабо отказаться от своей груды костылей в пользу нормально спроектированной подсистемы, судя по https://bugzilla.redhat.com/195365).

> !! Two most popular open source desktops, KDE and Gnome, can configure
> only few settings by themselves thus each distro creates its own
> bicycle (applications/utilities) for configuring a boot
> loader/firewall/network/users and groups/services/etc.

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

> и отсутствие нормальной возможности полноценно даже редактировать xorg.conf,
> обсуждаемое в данной ветке.

Вы шутите.  Ответственно заявляю как пользователь vim(1), им же правивший под специфические производственные нужды утилитку на базе libxorgconfig.


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено Анон , 27-Ноя-12 00:59 
>> Чтобы получилось что-то стоящее, это не с Артёмом обсуждать надо.
> Если про его статью, то всё же с ним.

Статья - для читателей. Вот с ними и обсуждать. Автор не может знать всё. Пользователи поправят.

>> Вот, к примеру:
>> No unified configuration system for computer settings, devices and system services.
>> E.g. distro A sets up networking using these utilities, outputting certain settings
>> residing in certain file system locations, distro B sets up everything
>> differently. This drives most users mad.
> Про "most users" -- неудачная шутка, стандартов конфигурирования сети три штуки: /etc/sysconfig/network*,
> /etc/network/ и самопальные скрипты (в альте трудами и по инициативе Дениса
> Овсиенко была внедрена его разработка -- /etc/net -- но тем же
> шляпникам оказалось слабо отказаться от своей груды костылей в пользу нормально
> спроектированной подсистемы, судя по https://bugzilla.redhat.com/195365).

Придирка к E. G. unified configuration system отсутствует.  Скажем, для сети нет нормального GUI. У alsa пропала alsaconf , без которой иногда карта не заводится, нет GUI.


>> !! Two most popular open source desktops, KDE and Gnome, can configure
>> only few settings by themselves thus each distro creates its own
>> bicycle (applications/utilities) for configuring a boot
>> loader/firewall/network/users and groups/services/etc.
> Здесь налицо полное непонимание происходящего, т.е. не тянет даже на "критику от
> лица пользователя" (которому скорее без разницы, как это называется, лишь бы
> работало).

Какое непонимание? GUI KDE и GNOME могут что-то настраивать, но не всё. Как и дистрибутивоспецифичные drakconf, yast, debconf, alterator и т. д.

>> и отсутствие нормальной возможности полноценно даже редактировать xorg.conf,
>> обсуждаемое в данной ветке.
> Вы шутите.  Ответственно заявляю как пользователь vim(1), им же правивший под
> специфические производственные нужды утилитку на базе libxorgconfig.

Покажите подсветку синтаксиса и опций xorg.conf для  драйвера nvidia в vim.


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено Michael Shigorin , 27-Ноя-12 12:20 
> Статья - для читателей. Вот с ними и обсуждать. Автор не может знать всё.
> Пользователи поправят.

Пользователи, а не как верно замечено -- стенатели со стороны.

> Придирка к E. G. unified configuration system отсутствует.

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

> Скажем, для сети нет нормального GUI.

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

> У alsa пропала alsaconf , без которой иногда карта не заводится, нет GUI.

Что-то я уже порядком лет такого не слыхивал, включая ISA PnP и полупрофессиональные карты.  И GUI там нужен примерно как почтовому серверу -- едва ли не единственная задача "определить порядок звуковушек и кто по дефолту" и то малоактуальна.

PPS: когда-то слыхивал и смутно припоминается, что даже один раз натыкался или показывали.  Но это как бы не 2004 +/-2.

> Какое непонимание? GUI KDE и GNOME могут что-то настраивать, но не всё.
> Как и дистрибутивоспецифичные drakconf, yast, debconf, alterator и т. д.

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

> Покажите подсветку синтаксиса и опций xorg.conf для  драйвера nvidia в vim.

Всё подсвечивается (и это не самый распоследний vim):

    Option "TwinView" "1"
    Option "metamodes" "DFP-0: nvidia-auto-select +0+0, DFP-1: nvidia-auto-select +1600+0"
    Option "Coolbits" "1"

PS 2 all: коллеги, предлагаю это чудо при попытках хронофагии экскоммуницировать -- пытается прикидываться местным, вот только негров у нас на деревне отродясь не было.


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено Анон , 27-Ноя-12 14:14 
> Пользователи, а не как верно замечено -- стенатели со стороны.

Ну, разумеется, у пользователей мнение совпадает с Шигориным. Остальные - стенатели.

>> Придирка к E. G. unified configuration system отсутствует.
>> Скажем, для сети нет нормального GUI.
> То-то юзеры с тем же NetworkManager разбираются быстрей, чем с виндовым недоразумением
> и типовыми вендорскими костылями, пытающимися каждый на свой лад его подпереть.

NetworkManager? Который по работоспособности синоним pulseaudio? Ему до стабильности ещё далеко. Это - нормальный GUI?

>> У alsa пропала alsaconf , без которой иногда карта не заводится, нет GUI.
> Что-то я уже порядком лет такого не слыхивал, включая ISA PnP и
> полупрофессиональные карты.  

Ну разумеется, Шигорин не слышал, значит этого нет. А посмотреть google на проблемы на эту тему нельзя - статус.

>> Какое непонимание? GUI KDE и GNOME могут что-то настраивать, но не всё.
>> Как и дистрибутивоспецифичные drakconf, yast, debconf, alterator и т. д.
> И что характерно -- утилиты DE скорее занимаются пользовательскими настройками, а дистрибутивоспецифичные
> -- общесистемными.

Ну, естественно. KSysV - это программа пользовательской настройки. Как и KMyFirewall (учитывая, что под никсами проще проксями пользоваться, которые, правда, по Шигорину, тоже системные, ибо конфиги в /etc лежат, а не в /home/user/.config). При этом всех пользовательских настроек они не умеют всё равно.

>> Покажите подсветку синтаксиса и опций xorg.conf для  драйвера nvidia в vim.
> Всё подсвечивается (и это не самый распоследний vim):

    Option 
> "TwinView" "1"
>     Option "metamodes" "DFP-0: nvidia-auto-select +0+0, DFP-1: nvidia-auto-select +1600+0"
>     Option "Coolbits" "1"

А где расширение-то? Дабы его код посмотреть на тему поддержки ключиков драйвера nvidia.

> PS 2 all: коллеги, предлагаю это чудо при попытках хронофагии экскоммуницировать --
> пытается прикидываться местным, вот только негров у нас на деревне отродясь
> не было.

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


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено Michael Shigorin , 27-Ноя-12 16:29 
> Остальные - стенатели.

Это Ваши слова, а не мои.

> NetworkManager? Который по работоспособности синоним pulseaudio?
> Ему до стабильности ещё далеко. Это - нормальный GUI?

Который тоже жуткий комбайн с мордой.  Вы же просили GUI?  Предъявите хоть один лучше, а мне /etc/net за глаза хватает.

> Ну разумеется, Шигорин не слышал, значит этого нет.

Значит, это не так актуально, как некоторые пытаются представить.

> А посмотреть google на проблемы на эту тему нельзя - статус.

Ваш причём -- сами сказали, сами и доказывайте.

>> И что характерно -- утилиты DE скорее занимаются
> Ну, естественно. KSysV - это программа пользовательской настройки.

Слово "скорее" Вам знакомо только в смысле скорости?

>>     Option "Coolbits" "1"
> А где расширение-то? Дабы его код посмотреть на тему поддержки ключиков драйвера
> nvidia.

Какое там расширение -- просто работает, а чем в /usr/share/vim/syntax/ обеспечивается -- не моё хомячье дело. :P

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

Так жалко ведь... думаете, я никогда чушь не нёс и мне (в т.ч. тут) не вправляли извилины?  Правда, целенаправленно с подвохом -- не было, а за Вами регулярно проскакивает.  Хотя опять же -- в таких суждениях всегда рад ошибиться.


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено Анон , 27-Ноя-12 16:51 
> Так жалко ведь... думаете, я никогда чушь не нёс и мне (в
> т.ч. тут) не вправляли извилины?  Правда, целенаправленно с подвохом --
> не было, а за Вами регулярно проскакивает.  Хотя опять же
> -- в таких суждениях всегда рад ошибиться.

А казались адекватным человеком. А вам просто заняться нечем? Да ещё и с вправленными извилинами? Тогда вообще всё ясно: http://offline.computerra.ru/2004/541/33566/
Ну да ладно, адью.


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено Michael Shigorin , 27-Ноя-12 16:58 
> А вам просто заняться нечем?

Сходите уже, что ли, в гугль -- а вообще-то недавно отвечал User294 со ссылками, оправдываясь, что пропадал: http://www.opennet.me/openforum/vsluhforumID3/87220.html#153


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено arisu , 27-Ноя-12 17:01 
> Ну да ладно, адью.

кисо абиделось? какая жалость…


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено myhand , 27-Ноя-12 17:22 
>> Пользователи, а не как верно замечено -- стенатели со стороны.
> Ну, разумеется, у пользователей мнение совпадает с Шигориным. Остальные - стенатели.

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

Почитайте обсуждение в debian-devel, к примеру.

>>> У alsa пропала alsaconf , без которой иногда карта не заводится, нет GUI.
>> Что-то я уже порядком лет такого не слыхивал, включая ISA PnP и
>> полупрофессиональные карты.
> Ну разумеется, Шигорин не слышал, значит этого нет. А посмотреть google на
> проблемы на эту тему нельзя - статус.

Школота везде себе способна насоздавать проблемы, причем здесь ALSA и что в этом нового чтобы специально "смотреть"?


"(offtopic) windows isn't even ready for criticism, so?"
Отправлено arisu , 27-Ноя-12 08:25 
статья вообще вся смешная, наверное. каюсь, я не прочитал дальше плача по поводу того, что screensaver можно убить клавиатурным сочетанием (это у него называется «несекурность», обалдеть). у чувака какое-то странное стремление во-первых, жить в клетке, во-вторых, всех других по клеткам рассадить, в-третьих, «настроить систему могут только супергении».

ну да, согласен: GNU/Linux не готов для десктопа безмозглой человекообразной обезьяны. по-моему, это дополнительный огромный плюс системы. гномеры вон пытаются этот плюс сточить, но не особо удачно.

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


"/"
Отправлено myhand , 27-Ноя-12 02:21 
> Почему-то в винде и nvidia-config читать документацию не нужно

Ну так и используйте nvidia-config, что мешает?

>>> Когда каждый пишет свой "парсер" вместо
>> В (третий?) который раз - не распинайтесь за всех и вся.
> Загляните в код и убедитесь сами.

"Докажите за меня сами." (с)  Нет, спасибо.

>> Чтобы отделить код от комментариев не нужно никакой *специальной* подсветки синтаксиса
>> вообще.  Нужно просто научиться работать с текстовым редактором.
> Про закомментированный код почему-то забыли упомянуть.

Чем он отличается от других комментариев?  А если там псевдокод?  А если там код написан неформально, с ошибками?

Любители этой вырвиглаз-практики способны все довести до полного маразма...

>> Это проблемы конкретного пацаненка.  Причем тут Linux?
> А когда Linux при чём? Когда у всех не работает?

Грубо говоря, да.  Раз вы лапшу на уши вешаете про какие-то глобальные проблемы с "автоматизацией" - начните 1)с определения что вы под этим понимаете (вот я вас недопонял, думал речь идет о развертывании linux на предприятиях) и 2) с описания задач этой самой автоматизации, которые linux почему-то не может решить (а не аччотов от криворуких пацаненков с лора).


"/"
Отправлено arisu , 27-Ноя-12 08:42 
> Это я уже заметил. Раз opennet, то серверы, предприятия, админы. Пользователей как
> бы не существует, как и десктопов.

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

«стенальщики» о «линуксе и десктопе» живут в прошлом веке, увы. сегодняшние реалии же таковы, что большинству «обычных пользователей» десктоп до афедрона — вместе с его мощностью и универсальностью. что, кстати, поняли и гномеры, и m$. эти пользователи не будут вообще ничего настраивать, ни через конфиги, ни через GUI, им нужна в настройках только одна кнопка: «сделать зашибись!» если кнопок больше, они окно настроек закрывают.

а вот чуть более «продвинутые» пользователи при необходимости и конфиги поправят. потому что это не rocket science, да и делать это надо один раз, а потом просто работать.

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

хотя нет, понимаю: если немного смешать понятия, то можно кричать, что «ничего не работает, а модератор всегда прав!!1111»


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Константин , 23-Ноя-12 23:24 
Да... Мода на дистры проходит, теперь за пакетные менеджеры взялись, опять каждый свой, без оглядки на "однополчан"
НИКОГДА НИОДИН менеджер пакетов не станет стандартом (были и будут deb, rpm и с натяжкой tgz) а стопиццот остальных - я никогда не слышал про их nix (слышал, но и тогда все спрашивали - что это такое) а они уже на его основе следующее поделие с наполеоновскими планами придумали.
И каждый же мечтает - Как сделаю ПМ! вот как станет мой ПМ САМЫМ стандартным.. Только тот же набор фич, вечнонедоделанный, с двумя контрибутерами и тремя юзерами (двое из них контрибутеры) ПАРВЁМ ФСЕХАФ

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено all_glory_to_the_hypnotoad , 24-Ноя-12 00:40 
deb, rpm и, совсем неожиданно, tgz - не менеджеры пакетов. Млять.. да откуда столько школоты на опеннете

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено KT315 , 23-Ноя-12 23:46 
> работа без получения привилегий суперпользователя

прювет вирусы с пакетыми с неизвестных источников, прощай репозиторий и ручная компиляция вирусов?
Неосиляторы дистрибутивных пакетных менеджеров, должны платить за свою тупость.
"Создайте еще более понятный интерфейс и мир создаст еще более тупого юзера." (с) кто-то умный
Давайте просто сразу линковать все статически :-) слабо?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 00:03 
Кстати, там не сказано что для управления пакетами не нужен рут, там сказано что самому ПМ не нужен рут для работы.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ffirefox , 24-Ноя-12 05:29 
Робята, Я понимаю, что некоторые все на транзисторах до сих пор собирают, но хоть чуть чуть почитать по ссылке бы надо.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено oops , 24-Ноя-12 10:01 
> Пакеты оформляются в виде контейнеров, содержащих все необходимые для работы приложений компоненты, позволяющие запустить приложение без оглядки на состав базового системного окружения.

а вот я и подумал, что все слинковано статически. нет?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено АнониМ , 23-Ноя-12 23:59 
прикольная вещица - немного напоминает maven из java ... потрогаем на досуге.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено добрый дядя , 24-Ноя-12 00:07 
что я могу сказать... это супер! что кто-то, судя по описаниям этого проекта, решил создать пакетную систему моей мечты без недостатков всех нынешних - их сейчас много но все они убоги хотя бы тем что не позволяет работать от юзера и не позволяют параллельное существование нескольких версий + создание установочных пакетов "всё с собой" (без дублирования при установке, если что-то уже стоит то используем)

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

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 00:51 
http://www.stallman.org/stallman-computing ;-)

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 26-Ноя-12 16:01 
> http://www.stallman.org/stallman-computing ;-)

Прикольный он все-таки тип, хоть и своеобразный :)


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 24-Ноя-12 04:51 
> не позволяет работать от юзера

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ffirefox , 24-Ноя-12 05:33 
Юзерский скрипт может переколбасить только юзерскую (одного юзера) часть системы. Да и то только ту, что админ разрешит.

В чем проблема, если юзеру разрешить устанавливать в свой user space программмы из списка (и источников), который разрешил админ?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 24-Ноя-12 06:04 
> В чем проблема, если юзеру разрешить устанавливать в свой user space программмы
> из списка (и источников), который разрешил админ?

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 24-Ноя-12 11:42 
и даже скрипты выполнять нельзя? ну ты суров

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 24-Ноя-12 11:51 
> и даже скрипты выполнять нельзя? ну ты суров

современный *юзер*, пишущий скрипты? я же не зря слово «юзер» выделил. им тупо не надо, они будут бегать по интернетам и истерично искать «окошко с кнопочкой». а те, кто таки умеют писать скрипты, не поленятся набрать sh myscript.sh. или даже алиас для этого сделать.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Пр0х0жий , 27-Ноя-12 10:51 
> Юзерский скрипт может переколбасить только юзерскую (одного юзера) часть системы.
> В чем проблема, ...?

В том, что пользовательские данные иногда стОят дороже всего компьютера целиком.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Michael Shigorin , 25-Ноя-12 20:13 
> - их сейчас много но все они убоги хотя бы тем что не позволяет работать от юзера

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

> и не позволяют параллельное существование нескольких версий

rpm позволяет (как и тот же dpkg) -- если нет файловых конфликтов либо пакет собран как relocatable.

> + создание установочных пакетов "всё с собой" (без дублирования
> при установке, если что-то уже стоит то используем)

Последнее особенно неприятно тем, что вносит неопределённость.

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

Вообще-то если почитать про NixOS (занятный проектик, услышал про него с год тому) -- то как раз всё становится на свои места: у них purely functional OS и наиболее естественно реализация ложится как раз на функциональный язык.

У меня в altlinux.org/m-p местами схожий подход (но к построению образа дистрибутива) и текущим "движком" является make, хотя и бродят мысли про более подходящий DSL порой.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Пр0х0жий , 26-Ноя-12 19:57 
> супер! ... пакетную систему моей мечты без недостатков всех нынешних
> ... но все они убоги хотя бы тем
> что не позволяет работать от юзера

Для Сам Себе Злобных Буратинав:

%wheel ALL = (APT_RUN_AS) NOPASSWD: APT_CMD
alias sapt-get='sudo apt-get'
# usermode -G wheel всех


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Пр0х0жий , 27-Ноя-12 10:17 
> # usermode -G wheel всех

Должно быть
# usermod -G wheel всех

Извиняюсь за ачипятку.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 00:18 
> Пакеты оформляются в виде контейнеров, содержащих все необходимые для работы приложений компоненты

Глупость какая-то...


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 00:19 
> Глупость какая-то...

Да нет же, просто 927-й комикс с xkcd :)


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено RNZ , 24-Ноя-12 01:19 
Вы предыдущее предложение не прочитали?
"пакет устанавливается как /nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-17.0.0/, где "r8vvq9k..." является уникальным идентификатором пакета, используемым для контроля зависимостей."
В nix пакеты тянутся по зависимостям. Второе предложение похоже взято с потолка.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено all_glory_to_the_hypnotoad , 24-Ноя-12 00:35 
> Пакеты оформляются в виде контейнеров, содержащих все необходимые для работы приложений компоненты, позволяющие запустить приложение без оглядки на состав базового системного окружения.

привет, виндовс 95


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено c0smonaut , 24-Ноя-12 01:03 
Софт в хомяке с правом перезаписи бинарников. Да здравствуют linux-вирусы(?)

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено RNZ , 24-Ноя-12 01:22 
Верной дорогой идёте товарищи!

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

Это предложение не соотвествует действительности, по крайней мере в nix пакеты тянутся по зависимостям и не являются контейнерами на манер "всё в себя".


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено RNZ , 24-Ноя-12 01:26 
Так и есть, никакого "всё в себя":
http://lists.gnu.org/archive/html/gnu-system-discuss/2012-11...
> The distribution is self-contained: each package is built based solely
> on other packages in the distribution; the root of this dependency graph
> is a small set of bootstrap binaries.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 01:31 
сезонный фактор влияет? Появление pkgng во FreeBSD, вот теперь GNU что-то делает...

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено SergMarkov , 24-Ноя-12 02:22 
давно пора

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 24-Ноя-12 02:45 
Кто о чём, а вендузятники о Форточках. =)

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 03:19 
не люблю так делать, но
+100500

увидели хоть что-то отдалённо напоминающее — всё, винда адназначна.
а то, что в любом «не_стандартном» (кто-то там прокричал, де… в линухах стандартов нету-у-у-у) и занюханом дистре линуха я могу точно сказать какая библа когда поставлена, зачем поставлена, каким приложениям требуется и как разрулить конфликт, ежили таковой случится и всё это при помощи парочки-тройки не сложных действий.
и это же относится и к сабжу (включая ещё и транзакции. контрольный выстрел).
нда-а-а-а. винда-а-а-а.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 24-Ноя-12 11:32 
Не говори.
Ещё смешнее, что их бурные эмоции были вызваны не пакетным менеджером, а фантазией автора. Я хз откуда он взял и что имел в виду, когда писал это:
>Пакеты оформляются в виде контейнеров, содержащих все необходимые для работы приложений компоненты

 


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 24-Ноя-12 11:36 
> Я хз откуда он взял и что имел в виду, когда писал это

так опеннет же! за что и люблю: тут в переводе можно прочитать такое, что сам и не придумаешь.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено lucentcode , 24-Ноя-12 04:42 
Годная статья, надеюсь со временем данная штука будет в Arch'е.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Crazy Alex , 24-Ноя-12 08:10 
Только, пожалуйста, ТОЛЬКО в Arch'e - ему уже хуже не будет, а нормальные дистрибутивы калечить не надо.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 11:19 
> Годная статья, надеюсь со временем данная штука будет в Arch'е.

А зачем надеяться? Вручную прикрутить и самому можно, как уже сделали с Portage (https://aur.archlinux.org/packages/portage-git/) и с pkgsrc (https://aur.archlinux.org/packages/netbsd-pkgsrc/). А пакетным менеджером по умолчанию его в Arch'е не сделают, ибо их родной pacman и есть то, что отличает Arch от любого другого дистрибутива (кроме основанных на Arch, само собой). Особенно это верно сейчас, после перехода с initscripts на systemd. Если еще и пакетный менеджер на что-нибудь заменят, от Arch'а останется одно название.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Crazy Alex , 24-Ноя-12 08:15 
Тьфу, что за помрачение рассудка... Ну я ещё с горем пополам могу понять, когда хочется иметь пачку разных версий одного и того же пакета. Но установка в пользовательский каталог? Зачем? Чтобы доступнее было на запись чему малвари? Чтобы юзер мог случайно софтину удалить/покалечить? Чтобы, к конце концов, поиск по хомяку дольше длился? О полумертвом Guile я уж не говорю - хоть бы язык какой-нибудь распространенный взяли - да lua тот же.

В общем, из описанного единственное, что интересно - это транзакции и откаты.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ан0нимус , 29-Ноя-12 00:14 
Доку почитайте: http://nixos.org/nix/docs.html

В хоум nix-daemon только ставит нужные симлинки.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 29-Ноя-12 16:54 
> Но установка в пользовательский каталог? Зачем?

Затем, что половозрелые пользователи в здравом уме и трезвой памяти такое делают (hint: ./configure && make && etc).  И не обязательно у них должен быть доступ к системе с какими-то расширенными привилегиями.

Так что как один из вариантов - вполне.

> О полумертвом Guile я уж не говорю

Чем он полумертв?  Не говоря уже о том, что был и остается стандартным языком расширения в GNU.



"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено XoRe , 24-Ноя-12 11:10 
Интересно, а что будут делать 100500 приложений, каждая со своим libpng, когда в libpng найдут ещё одну уязвимость?

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Crazy Alex , 26-Ноя-12 15:45 
Тут всё не так печально - по идее, обновления будут - там, где само приложение допускает соответствующую версию. Но нужную версию с багфиксом сделать всегда можно. Другое дело - что это будет способствовать зоопарку версий библиотек, за что их разработчики спасибо не скажут. Хотя скорее всё быстро устаканится - будут закрывать на фиг все багрепорты для древних версий библиотек, и поневоле придётся на более-менее актуальные переползать. А где всё надёжно и стабильно - там на зоопарк версий плевать, в общем-то.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено XoRe , 26-Ноя-12 22:34 
Это был риторический вопрос)
Я указал на один из минусов системы.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 24-Ноя-12 11:15 
интересно, а хоть кто-то из яростно тут сражающихся сходил на оффсайт и почитал, что же на самом деле такое эта система? а то как переводят на опеннете — известно.

p.s. нет, я — не ходил.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Аноним , 24-Ноя-12 12:26 
как только я увидел это /r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-17.0.0/
мне стало плохо

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Alex , 24-Ноя-12 13:35 
> работа без получения привилегий суперпользователя

Это как? В чём разница с обычными дистрами?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено mylefthand , 24-Ноя-12 14:07 
>дистрибутив GNU. Но ведь дистрибутив GNU должен функционировать поверх Hurd. Они забили на Hurd?! Nooooooooooo!

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 24-Ноя-12 14:11 
это кому он «должен»?

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено myhand , 24-Ноя-12 14:59 
>>дистрибутив GNU. Но ведь дистрибутив GNU должен функционировать поверх Hurd. Они забили на Hurd?! Nooooooooooo!

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

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено sarbash , 24-Ноя-12 20:38 
Всё это напоминает обострение синдрома NIH...
Разве не пакетный менеджер решает проблему зависимостей и dll-hell?
Зачем рядовому пользователю возможность установки приложений?
В Enterprise сие под контролем админа, я на своём локалхосте прекрасно решаю задачу установки с помощью штатного пакетного менеджера, мой личный home полностью под моим контролем и бинарникам в нём нечего делать (конечно, есть исключения, в пределах разумного, не превращать же home/bin в подобие /usr/bin!!).

Зачем транзакции? Разве пакетный менеджер не может проконтролировать установку и в случае неудачи её отменить?

Потом, это отдельное дерево пакетов или даже в каталоге пользователя! И что, терминал уже не в моде? всё запускаем с помощью ярлычков на десктопе? здравствуй виндолинукс? А как же $PATH?

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

P.S. Самолично пользуюсь aptitude, до этого был pacman.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено sarbash , 24-Ноя-12 21:19 
>Это не транзакция?

Если это - транзакция, то пакетный менеджер без неё - не пакетный менеджер.

>Не вижу логики. Как каталог связан с терминалом и ярлыками?

Логика была в возможности запуска любого приложения из любого места (меню, gmrun, строка терминала, mc, something else...).

Как я понял, проблему *.so они решили прописыванием зависимостей. Интересно, а где общие либы будут лежать? У каждого приложения по своему экземпляру либы? Ибо независимость от системного окружения. Не понимаю, как вообще этот вопрос решили?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 24-Ноя-12 21:42 
>Если это - транзакция, то пакетный менеджер без неё - не пакетный менеджер.

тогда пакетных менеджеров намного меньше, чем ты думаешь.

>Логика была в возможности запуска любого приложения из любого места (меню, gmrun, строка терминала, mc, something else...).

ну есть же $HOME/bin и симлинки.

>Как я понял, проблему *.so они решили прописыванием зависимостей. Интересно, а где общие либы будут лежать? У каждого приложения по своему экземпляру либы? Ибо независимость от системного окружения. Не понимаю, как вообще этот вопрос решили?

незнаю как они решили, но в man ld.so много переменных интересных переменных окружения. Например: LD_LIBRARY_PATH. Можно использовать симлинки :D


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено sarbash , 24-Ноя-12 22:16 
> ну есть же $HOME/bin и симлинки.

Когда я размышлял над темой, у меня проскальзывала такая мысль, что, вероятно, будет 100500 симлинков. При таком раскладе, это первое очевидное решение проблемы.
Ладно, пусть велосипедят, в свете последних событий, вообще уже ничего не удивляет.
Даже не приходит в голову, что ещё не успели навелосипедить... система инициализации? графическая система? стандарт файловой иерархии?


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Crazy Alex , 26-Ноя-12 15:47 
шелл ещё вроде держится, тьфу-тьфу...

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 22:14 
>Интересно, а где общие либы будут лежать?

на самом деле вообще не интересно.
важно в где и в какой последовательности их будет искать ldd при запуске конкретного приложения.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 22:10 
>>Разве не пакетный менеджер решает проблему зависимостей и dll-hell?
>пакетный менеджер не решает проблему dll-hell. У него не достаточно для этого информации.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 24-Ноя-12 22:33 
какая связь между разрешение зависимостей(по имени пакеты или имени файла) и ABI библиотеки? Ну нету этой инфы в пакете. Она даже не всегда доступна людям собирающим эти пакеты. Ты, что думаешь, я не смогу собрать пакет, который заменит libx264.so.120 на libx264.121? Всего то один mv, и всё... всё в руках вменяемого мейнтейнера.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 22:56 
>какая связь между разрешение зависимостей(по имени пакеты или имени файла) и ABI библиотеки? Ну нету этой инфы в пакете.

правильно. никакой. :D
>Ты, что думаешь, я не смогу собрать пакет, который заменит libx264.so.120 на libx264.121? Всего то один mv, и всё... всё в руках вменяемого мейнтейнера.

правильно, можешь. :D
как и вындусовый ливапдэйт может сделать формат ц.
как андроидовский гуглплай может… и тд, и тп.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 24-Ноя-12 23:04 
>и тем не менее пакетный мэнеджер не перезапишет библиотеки одного пакета библиотеками другого.

а ты пробовал?

>нет. а его вообще нет.

100%-ного нет, зато...
1) можно ввести информацию по интерфейсам, которые обеспечивает либа(привет .net)
2) повесить заботу об этих либах на специальный механизм, который сам будет давать им уникальные имена(например: рандомные)
3) использовать БД с ключами интерфейс:либа, или <имя либы><мажорная версия>:либа


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 23:32 
>а ты пробовал?

а ты нет?
>100%-ного нет, зато...
>1) можно ввести информацию по интерфейсам, которые обеспечивает либа(привет .net)
>2) повесить заботу об этих либах на специальный механизм, который сам будет давать им уникальные имена(например: рандомные)
>3) использовать БД с ключами интерфейс:либа, или <имя либы><мажорная версия>:либа

4) использовать бандлы (аля мак и, частично, сабж)
5) просто грамотно устанавливать ПО и предоставить такой механизм для динамического загрузчика, чтобы он мог быть грамотно прозрачно настраиваться для запуска приложений с нужной именно им библиотекой.

при этом первый приводит к регистрихэлл, а первый/второй/третий/четвёртый к дополнительным расходам ресурсов (в винде вон несколько гигов под это дело).
если перфразировать задачу с «избавиться от dll-hell окончательно» на «предоставить такие истструменты в системе, чтобы можно было разрулить потенциальный dll-hell», то линух для этого отлично подходит — можно любой блоб (!!!) заставить работать установив и переконфигурировав необходимое. исключение составляет привязка к glibc/ но и это обходится.
а в винде этого сделать нельзя (разве что на дотнете :D)


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 24-Ноя-12 23:39 
1-3 -- это не 'или', а 'и'.
Ну гарантия, конечно, всё ещё никакая.

Про всё остальное: офигеть ты фанатик. В винде -- тоже самое и всегда было. Просто, положить либу в директорию проще всего.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 24-Ноя-12 23:58 
с одной стороны — все твои 1/2/3
с другой — добавить пару строчек в окружение программы.
>В винде -- тоже самое и всегда было. Просто, положить либу в директорию проще всего.

да-да!! :D
именно так там и появился dll-hell (1с 2.0 отлично в него попадала с установкой ole.dll)
потом пошли ком, с регистрацией и прочими плюшками (а как их удобно программировать! :D)
потом манифесты интерфейсов, потом гигабайтные кэши http://en.wikipedia.org/wiki/Side-by-side_assembly
>Microsoft Visual C++ 2005 and 2008 employ SxS with all C runtime libraries. However, runtime libraries in Visual C++ 2010 no longer use this technology; instead, they include the version number of a DLL in its file name
>Disadvantages
>* Only supported on Windows XP and later. In Windows XP, a bug in sxs.dll causes heap corruption, leading to application crashes. This issue is not fixed by any XP service packs. Users must manually install a QFE (Quick Fix Engineering).
>* Considerably higher disk space consumption. The winsxs directory typically starts at several gigabytes

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 25-Ноя-12 00:02 
вот чёрт. Мне теперь писать в какую директорию положить? Я имел ввиду НЕ systemXY

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 25-Ноя-12 00:03 
а длл-хэлл в НЕ systemXY НЕ наступает.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 25-Ноя-12 00:13 
Я знаю это.
Вот тут http://www.opennet.me/openforum/vsluhforumID3/87443.html#139 написано:
>/usr/libXX

А там я написал про директорию потому, что ты сказал(http://www.opennet.me/openforum/vsluhforumID3/87443.html#169):
>если скайп, опера, жопера идёт со своими библами для внутреннего использования, то >единственное с чем она может столкнуться, то это с совпадением имени файла при бедной >фантации разработчиков. но поскольку в линухе можно легко строить структуры каталогов, то >это не вызывает проблем

но и в винде в ProgramFiles можно и не такое сделать.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 25-Ноя-12 00:17 
поэтому говорим о систем32

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 25-Ноя-12 00:03 
с остальным спорить сложно. Но в линуксе от этого хелл не исчезает, а что там в винде не так важно.

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено ананим , 25-Ноя-12 00:12 
хелл исчезает из-за 2-х факторов — 1) гибкое окружение (теперь даже глибс можно через контейнер другой пустить) и 2) пакетные мэнеджеры, не допускающие установки вручную (аля setup.exe и вопросом «а вы уверены?». вот у кого они спрашивают? у пользователя? чтобы на него ответственность переложить не более)

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено sarbash , 25-Ноя-12 01:25 
http://ru.wikipedia.org/wiki/DLL_hell

Нет в Linux никакого DLL-hell. Возможен Dependency-hell, решить который и призван пакетный менеджер. И вполне себе решает.
А то, что вытворяет объект обсуждения - либо сплошная статика (память нынче дешёвая), либо "атака кло(у)нов", либо - выкрутасы с симлинками и помойка в файловой системе.

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Michael Shigorin , 25-Ноя-12 20:20 
>>и тем не менее пакетный мэнеджер не перезапишет библиотеки одного пакета
>>библиотеками другого.
> а ты пробовал?

Я -- да; rpm откажется производить установку по причине файлового конфликта.

>> нет. а его вообще нет.

Можно и 100%, только накладные расходы становятся заметными.

> 100%-ного нет, зато...

#230


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 25-Ноя-12 00:12 
> какая связь между разрешение зависимостей(по имени пакеты или имени файла) и ABI
> библиотеки? Ну нету этой инфы в пакете. Она даже не всегда доступна людям собирающим эти пакеты.

Дану? Эта инфа в major version number в SONAME, а так же в имени бинарника и в имени пакета.

> Ты, что думаешь, я не смогу собрать пакет, который заменит libx264.so.120 на libx264.121? Всего то один mv,
> и всё... всё в руках вменяемого мейнтейнера.

От дурака майнтейнера никто конечно не застрахован. Тем не менее твоего mv совсем не достаточно, чтобы устроить dll-hell.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено filosofem , 25-Ноя-12 00:22 
> И чем он лучше аттрибутов(или как там их) у файлов в винде?
> таже самая филькина грамота

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Michael Shigorin , 25-Ноя-12 20:18 
> какая связь между разрешение зависимостей(по имени пакеты или имени файла)
> и ABI библиотеки? Ну нету этой инфы в пакете.

Где как, в альте уже несколько лет как есть (google:rpm set-versions).

PS: когда не знаете, лучше и не утверждать.
PS: а когда утверждаете глупости вроде "у кого есть soname, кроме openssl" (#188) -- временно увеличиваете количество мусора, не более.


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 25-Ноя-12 20:41 
ах, ну да. Нет других дистров кроме altlinux

"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено arisu , 26-Ноя-12 02:57 
> ах, ну да. Нет других дистров кроме altlinux

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


"Проект GNU начал развитие нового пакетного менеджера Guix"
Отправлено Kolya , 26-Ноя-12 11:07 
>«нет дистра кроме того, у которого нет такой инфы в пакете»

фишка в том, что я не говорил этого. Я спросил у filosofem, есть ли такие пакеты. Но он, к сожалению, не ответил. А эта моя ошибка(а это ошибка) связана с тем, что в slackware я напарывался на "ошибку" в задании имени именно у openssl.

Мой ответ шигорину был про rpm, и пакетный менеджер в слаке именно перекрывал. По карайней мере в 12 версии.