LINUX.ORG.RU

VL-HOT - легковесная альтернатива HAL

 


0

0

VL-HOT создан разработчиками дистрибутива Vector Linux и позиционируется как легковесная и менее требовательная к ресурсам альтернатива HAL (hald). В частности VL-HOT работает через udev и не использует постоянный опрос оборудования, что позволяет меньше нагружать CPU. В числе минусов отсутствие поддержки автомонтирования CDROM и автомонтирования устройств, подключённых до загрузки системы.

Поддержка VL-HOT уже имеется в оконных менеджерах JWM и IceWM и в файловом менеджере PCManFM.

>>> Обзор

★★★★★

Проверено: maxcom ()

Ответ на: комментарий от AVL2

А что делать, если железо такое, что иначе никак? С железа надо начинать изменения. А не делать решение, которое экономит электричество за счет половинной функциональности.

svu ★★★★★
()
Ответ на: комментарий от AVL2

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

И учитывая что КПК на которых можно нормально поставить тот же debian или gentoo для arm становится все больше и больше, а зависимость от hal тоже больше и больше, то это реальная проблема.

gloomdemon
()
Ответ на: комментарий от svu

> А что делать, если железо такое, что иначе никак? С железа надо начинать изменения. А не делать решение, которое экономит электричество за счет половинной функциональности.

А если все устройства монтируются и так руками? Может в этом случае HAL и не нужен?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Разумеется. Но нонешние десктопы не предоставляют такой опции. Ибо так неудобно. А на своей уютненькой машине Вы вольны ставить те пакеты, которые Вам нравятся. Начиная с twm и xterm

svu ★★★★★
()
Ответ на: комментарий от svu

> Разумеется. Но нонешние десктопы не предоставляют такой опции. Ибо так неудобно. А на своей уютненькой машине Вы вольны ставить те пакеты, которые Вам нравятся. Начиная с twm и xterm

Собственно на моих компьютерах и установлено только то, что нужно мне. Благо я красноглазый гентушник и мне мнабрать mount в uxterm под awesome совсем не сложно. Хотя до этого я использовал ivman, но теперь и он снесен.
Только что снес и hal, попутно пересобрав пару пакетов, которые от него зависят ;)

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Вот именно поэтому апстрим так относится к баг-репортам от гентушников. Потому что категория багов "кривая сборка" чаще всего ассоциируется именно с этим кошмарищем. Куда приятнее работать с предсказуемыми бинарными дистрибутивами.

svu ★★★★★
()
Ответ на: комментарий от svu

> Вот именно поэтому апстрим так относится к баг-репортам от гентушников. Потому что категория багов "кривая сборка" чаще всего ассоциируется именно с этим кошмарищем. Куда приятнее работать с предсказуемыми бинарными дистрибутивами.

Не уловил, чем сборка мэнтейнера бинарного пакета отличается от сборки пакета в генте?

andreyu ★★★★★
()
Ответ на: комментарий от svu

> Куда приятнее работать с предсказуемыми бинарными дистрибутивами.

Да, я поработал с "предсказуемыми" бинарным дистрибутивом. Больше секс меня не интересует ;)

andreyu ★★★★★
()
Ответ на: комментарий от svu

> Архитектура реализации - дело десятое

Вот с таким подходом и появляются доклады, подобные приведенному.. )))

LamerOk ★★★★★
()
Ответ на: комментарий от svu

> Потому что категория багов "кривая сборка" чаще всего ассоциируется именно с этим кошмарищем.

"Кривая сборка" - это когда программа вообще не собирается. А если она собралась, то должна работать. Иначе кривое что-то другое - либо программа, либо компилятор.

LamerOk ★★★★★
()
Ответ на: комментарий от andreyu

> Не уловил, чем сборка мэнтейнера бинарного пакета отличается от сборки пакета в генте?
Во-первых, тем, что мейнтейнер делает это постоянно - у него опыт. Как правило, адекватные мейнтейнеры в хороших отношениях с апстримом, по пустякам не беспокоят, примерно представляют как решать самые частые траблы.

Во-вторых, тем что в бинарном дистрибутиве один(!!!!) вариант сборки пакета (для данной платформу). Что сокращает пространство вариантов для кривизны, несовместимости (явной или неявной) внутри и с другими пакетами.

svu ★★★★★
()
Ответ на: комментарий от LamerOk

> А если она собралась, то должна работать
Бред. Вы программы сложнее "hello world" разрабатывали? Можно собрать программу - но она будет сыпаться внутри сама по себе, или из-за хитро поломанных интерфейсов с другими программами.

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

Если "все, что собралось, должно работать" - выкиньте 99.99% существующего кода. Теоретически - да, Вы правы. Практически - апстриму обычно совершенно неинтересно разбираться с тем, какие хитроподвыподвернутые опции Вы задали при сборке - и как это повлияло на взаимодействие с остальными программами и библиотеками (которые, очевидно, примерно столь же неидеальны, сколь и код самой "упавшей" программы).

svu ★★★★★
()
Ответ на: комментарий от svu

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

> Во-вторых, тем что в бинарном дистрибутиве один(!!!!) вариант сборки пакета (для данной платформу). Что сокращает пространство вариантов для кривизны, несовместимости (явной или неявной) внутри и с другими пакетами.


Так и запишем, мэнтейнер бинарного пакета более продвинут, нежели мэнтейнер ebuild'а.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

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

Ключевое слово _один_.

svu ★★★★★
()
Ответ на: комментарий от andreyu

> Только что снес и hal, попутно пересобрав пару пакетов, которые от него зависят ;)

Пересобрать "пару пакетов"? :O

HAL в кишках и выковырять его сложно:
> pkg_info -R hal-0.5.11_18

Information for hal-0.5.11_18:

Required by:
Terminal-0.2.8.3
Thunar-0.9.3
abiword-2.6.3_2
eclipse-3.4.1
eel-2.24.1
epiphany-2.24.3_1
evince-2.24.2
evolution-data-server-2.24.4.1
file-roller-2.24.3,1
gedit-plugins-2.22.5_1
gnome-desktop-2.24.3
gnome-keyring-2.24.1_2
gnome-mount-0.8_2
gnome-settings-daemon-2.24.1
gnome-system-monitor-2.24.4
gnome-themes-2.24.3
gnome-vfs-2.24.0
gnumeric-1.9.4_1
goffice-0.4.3_5
goffice-0.7.3
grip-3.2.0_18
gstreamer-plugins-gnomevfs-0.10.22_1,3
gstreamer-plugins-hal-0.10.13,3
gtksourceview-1.8.5_4
gvfs-1.0.3
libbonoboui-2.24.0
libexo-0.3.4_2
libgnome-2.24.1
libgnomedb-3.0.0_3
libgnomeui-2.24.0
libgsf-gnome-1.14.11
meld-1.2.1
midori-0.1.2
nautilus-2.24.2
nautilus-cd-burner-2.24.0
py25-gnome-2.22.3
ristretto-0.0.21
thunar-archive-plugin-0.2.4
thunar-media-tags-plugin-0.1.2_6
totem-2.24.4
totem-pl-parser-2.24.4
vlc-0.9.8.a_3,3
webkit-gtk2-1.0.1_6
xf86-input-keyboard-1.3.2
xf86-input-mouse-1.4.0_3
xf86-video-radeonhd-1.2.4_1
xf86-video-vesa-2.1.0
xfburn-0.4.0
xfce-4.4.3
xfce4-clipman-plugin-0.9.0
xfce4-desktop-4.4.3
xfce4-media-0.9.2_9
xorg-7.4
xorg-drivers-7.4
xorg-server-1.5.3_5,1

iZEN ★★★★★
()
Ответ на: комментарий от LamerOk

зачем нам какие-то пдфники, если есть первоисточник: http://webcvs.freedesktop.org/hal/hal/

Быстро принёс где там демон "перечитывает конфиги каждый раз при определении каждого устройства" и где там "поиск устройств методом перебора".

dk2
()
Ответ на: комментарий от svu

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

Выражение "кривое что-то другое" через чур завуалировано?

> Идеального кода не бывает.

Кто говорил про идеальный? Есть работающий, есть - не. Бывает еще частично. )))

> Если "все, что собралось, должно работать" - выкиньте 99.99% существующего кода.

Опенсурсного? Так уже. Проприетарный всё больше с оборудованием уходит.

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

Прям прокламация идеолога "works for me". В сочетании с "Архитектура реализации - дело десятое" получаем взрывной коктейльчик. ))) Коктейль svu - продолжатель традиций Молотова )))

Ваши программные планы по развитию мировой IT индустрии успешно претворяются в жизнь. Вы их сами наблюдаете в соседней ветке по иксоргу. )) С таким подходом у GNU/Linux светлое незамутненое будущее вечной сборки с волшебными флагами и крестным знамением, дабы чего не посыпалось.

LamerOk ★★★★★
()
Ответ на: комментарий от svu

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

У каждого пакета есть определенное и ограниченное кол-во USE-флагов. Флаги эти берутся не из воздуха, а определяются разработчиком того или иного пакета. Соответственно игра с флагами всего лишь включает или выключает определенную функциональность.
Мэнтейнеру нужно только прописать соответствие флагов пакетам в ebuild'е. Все остальное на совести разработчиков пакетов. Точно в таких же условиях находится и мэнтейнер бинарного пакета.

andreyu ★★★★★
()
Ответ на: комментарий от iZEN

> Пересобрать "пару пакетов"? :O
> HAL в кишках и выковырять его сложно:


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

p.s. Пошлость под названием GNOME я не использую. Разных свистелок-перделок у меня нет. Меня устраивает строго ограниченный набор приложений, которые позволяют решать ту или иную повседневную задачу. Ставить пакеты только для того, что бы он у меня был, смысла не вижу.

andreyu ★★★★★
()
Ответ на: комментарий от LamerOk

> Есть работающий, есть - не. Бывает еще частично. )))
Критерий работающего кода? Для меня "собранный поддерживаемым способом в поддерживаемом окружении выполняет заданные функции".

> Опенсурсного? Так уже. Проприетарный всё больше с оборудованием уходит.

И что остается в сухом остатке? Ядро хурда?

> Прям прокламация идеолога "works for me".

С чего б? Оно должно работать для всех. Но не "по-всякому" (в смысле - собранное как попало). Разница неочевидна?

> В сочетании с "Архитектура реализации - дело десятое" получаем взрывной коктейльчик.

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

> успешно претворяются в жизнь

Естественно. Потому что жизнь отталкивается от good enough.

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

Это не будущее, это настоящее любого сложного софта. Есть поддерживаемые комбинации продуктов (версий, сборок) - есть неподдерживаемые. Попробуйте взять какой-нибудь древний Oracle и поставить на неподдерживаемую самую свежую версию AIX ("неподдерживаемую = комбинация версий AIX/Oracle не поддерживается Ораклом"). Формально обратная совместимость у межбизмаша есть. И даже скорее всего работать будет. Но в случае любых траблов поддержка Оракла вас пошлет подальше, после первого же вопроса о версиях. И правильно сделают.

svu ★★★★★
()
Ответ на: комментарий от andreyu

> Флаги эти берутся не из воздуха, а определяются разработчиком того или иного пакета.
Сам механизм этой вариативности brain-damaged. Точнее, целенаправленно сделан против апстрим разработчиков (в том, что касается поддержки). Потому что ни один строитель ебилдов (особенно базовых библиотек, ядра, иксов, ...) не в силах просчитать все возможные комбинации USE зависимых пакетов. Следовательно, не может гарантировать их работоспособность во всех мыслимых комбинациях.

> Точно в таких же условиях находится и мэнтейнер бинарного пакета.

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

svu ★★★★★
()
Ответ на: комментарий от svu

> Но нонешние десктопы не предоставляют такой опции. Ибо так неудобно.

Знаете в чём может проявится "прелесть" HAL? Когда почти одновременно вставляете несколько removable-носителей (DVD и USB-flash), вот тут начинаются кошмарики от размножения окон файлменеджеров (а что, открыть автоматически подмонтированное устройство надо сразу же :) ) до зависаний DE с последующим ребутом. Конечно, можно списать всё на сырость/непродуманность реализации интерфейса взаимодействия HAL с другими программами и с системой, но сам факт непредсказуемости поведения настораживает.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

> кошмарики от размножения окон
Укротите свой десктоп. hal тут не при чем

svu ★★★★★
()
Ответ на: комментарий от svu

> Критерий работающего кода?

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

> Оно должно работать для всех. Но не "по-всякому" (в смысле - собранное как попало). Разница неочевидна?

Мало того, что разница неочевидна, по причине отсутствия, так еще и утвреждение противоречиво. Если у человека в системе gcc 4.2, так собранный им хэлловорд, собираемый майнтейнером gcc 4.1, должен выдавать на stdout "иди в жопу"? Или быть может сразу rm-rfить / за отличную от той, что у мейнтейнера пакета, версию компилятора?

> Естественно. Потому что жизнь отталкивается от good enough.

Это не жизнь, а разработчики открытого ПО отталкиваются от своей лени поддерживать, перепроверять и править уже существующий код в пользу сиюминутного желания получить новые "фичи" из которых добрая половина - bells&whistles. В жизни же такая стратегия может принести плоды только в очень краткосрочной перспективе. В долгосрочной - стопроцентый проигрыш.

> Есть поддерживаемые комбинации продуктов (версий, сборок) - есть неподдерживаемые.

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

LamerOk ★★★★★
()
Ответ на: комментарий от svu

> не в силах просчитать все возможные комбинации USE зависимых пакетов

Зависимые пакеты какбэ должны собираться с теми же USE, что и базовые. И _должны_ корректно работать при любых допустимых комбинациях. А при недопустимых - не собираться. Если не работают - значит глюкалово.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> Как, кем и в какую фазу луны оно собрано, в каком оркружении под какие религиозные обряды - вопрос как раз тридесятый.
Фазы луны тут не при чем. А вот опции configure - очень даже. Каждая опция минимум удваивает кол-во вариантов сборок.

> должен выдавать на stdout

Нет, не должен. Но я вполне пойму мейнтейнера пакета (сложнее хелловорлда), если он на запрос о проблемах спросит "кстати, а какие компиляторы у Вас" и при ответе "что-то от 4.1, а еще я недавно 4.2 пробовал - что-то могло остаться" пошлет багрепорт подальше. Соббсно это единственный правильный способ реагировать на такие баги.

> Это не жизнь, а разработчики открытого ПО

А разработчики закрытого ПО - чем-то отличаются? (Хинт: это большей частью одни и те же люди).

> А кто и где говорил про неподдерживаемые комбинации

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

> Речь идет про сборки отличные от сборки майненера волшебного единственно правильного бинарного пакета.

Тут как раз Вы начинаете оспаривать то, чего я не говорил. Никакого волшебства - только аккуратность. Которую гораздо легче (ерраре хуманум эст, блин!) достичь в случае одного варианта, а не Vtotal = Vlib1*Vlib2*Vlib3*...*Vn*Vapp вариантов. Да, на всякий случай - один вариант убунты будет отличаться от одного варианта федоры, так что для апстрима вариантов все равно несколько. Но (и в этом мой пойнт) - эти варианты четко определены (вместе с зависимостями), в случае конкретного баг-репорта я могу прямо общаться с человеком, ответственным за конкретный вариант (который его тестировал, и который достаточно квалифицирован, в отличие от красноглазой братии, играющейся с флажками USE).

svu ★★★★★
()
Ответ на: комментарий от LamerOk

> Зависимые пакеты какбэ должны собираться с теми же USE, что и базовые.
Пионер Криворучко не справится покорежить USE вверх по стеку?

> И _должны_ корректно работать при любых допустимых комбинациях.

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

Да, в результате разбирания такой баги могут быть выявлены реальные, настоящие проблемы в библиотеках и в приложении. Но ей-богу, сколько времени (нервов?) мейнтейнеру это будет стОить, пока он дойдет до этого. Кроме того, эти проблемы действительно могут быть актуальны ТОЛЬКО для "нестандартных" сборок. Что делает потраченное время бессмысленным - тратить кучу времени на поддержку тех, кто занимается всякого рода извращениями - это контр-продуктивно. Вспоминается анекдот про японскую пилу ("То-то!" - сказали суровые сибирские мужички).

svu ★★★★★
()
Ответ на: комментарий от svu

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

Кто-то заставляет разрабочтиков под дулом пистолета добавлять эти опции?

> Но я вполне пойму мейнтейнера пакета

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

> А разработчики закрытого ПО - чем-то отличаются?

Да. Хинт: над ними стоит менеджмент, а их творчество проходит тестировщиков. Им _приходится_ искать и править баги, даже если с одной комбинацией ключей всё работает правильно.

> А это одно и то же, только в профиль.

Интересный тезис.

> только аккуратность. Которую гораздо легче (ерраре хуманум эст, блин!) достичь в случае одного варианта, а не ...

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

LamerOk ★★★★★
()
Ответ на: комментарий от svu

> Это долженствование ничем технически не гарантировано.

Технически не гарантировано и следующее включение компьютера. Зачем доводить разумный тезис до его логического маразма?

> И устойчивость этой системы крайне хреновая

Зависит от системы. От её разработчиков.

> Кроме того, эти проблемы действительно могут быть актуальны ТОЛЬКО для "нестандартных" сборок.

Или вполне себе "стандартных" _будующих_ сборок. Типа "пофиксим, кода _у нас_ заглючит"...

> тратить кучу времени на поддержку тех, кто занимается всякого рода извращениями - это контр-продуктивно.

Я боюсь подумать, что было бы с gcc или linux, если бы _все_ руководствовались такой логикой. Ведь согласись, унылое подобие ядра выпилинное из программы-"терминала" - то еще извращение. )))

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

> речь шла про апстрим разработчиков

Виноват, неточно выразился. Я все еще о них.

> то вот разработчиков - уже нет.

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

> а их творчество проходит тестировщиков

Тестировщиками опенсорца, как мы знаем, являются пользователи.

> Им _приходится_ искать и править баги, даже если с одной комбинацией ключей всё работает правильно.

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

> отмел и ненапряжно слил в сортир

Я давно уже сделал стейтмент, что однозначного _технологического_ преимущества у опенсорца нет. Только этическое (но это про фрисофт, не про опенсорц). Так что сам с собой я вполне консистентен;)

Да, насчет комбинаций. Есть комбинации на разных этапах. Комбинации железа, комбинации условий сборки, комбинации условий использования (данные, действия пользователя). Думаю, важнейшими являются варианты использования. На втором месте - комбинации по железу. Комбинации условий сборки, хотя формально иногда помогают находить реальные баги - на практике КПД подобной работы на уровне плинтуса. Блохоискательство получается (худший вариант bug-hinting-а)

svu ★★★★★
()
Ответ на: комментарий от LamerOk

> Зачем доводить разумный тезис до его логического маразма?
Где я кого довел до маразма? Вы высказали что-то там по поводу долженствования - я всего лишь напомнил Вам, что это только пиа дезидерата, не более. Или вишфул сынкинг (в зависимости от Вашего любимого языка).

> Зависит от системы. От её разработчиков.

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

> Или вполне себе "стандартных" _будующих_ сборок. Типа "пофиксим, кода _у нас_ заглючит"...

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

> Я боюсь подумать, что было бы с gcc или linux, если бы _все_ руководствовались такой логикой

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

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

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

Практика ОС как раз показывает, что уезжают монолиты - gimp, mplayer, linux kernel, а гномы и опенофисы по прежнему пугают честных людей..

> поддержку завтрашнего стандарта надо обеспечивать завтра.

А всех, кто с устаревшим набором инструкций CPU - в бабий яр? Ибо "не стандарт"?

LamerOk ★★★★★
()
Ответ на: комментарий от svu

> который строитель ебилдов может не знать

Это проблема строителя ебилдов. И в этом случае задача разрабов строителя ебилдов просветить, если они поленились упомянуть это в доке.

> Они тоже люди. И возиться в помойке чужих машин им не интересно.

Может им еще и в "помойке" собственного кода возится не интересно? В этом и есть мой поинт. ))

> Они хотят иметь дело с проблемами своего пакета в более-менее устойчивом и проверенном окружении

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

> Тестировщиками опенсорца, как мы знаем

Ключевое слово было - "заставляют".

> Если дедлайн был вчера - сколько всего заметается под коврик?

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

> однозначного _технологического_ преимущества у опенсорца нет.

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

> Так что сам с собой я вполне консистентен;)

Ну что ж, позиция понята. )))

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> Так "работа" пакета с одними условиями ничуть не более дезерата, чем работа с другими
Ну щаз. Условия условиям люпус эст (чойта меня тут на латынь переклинило?). Попробуйте поработать, например, с эппловым иксовым сервером - где формально XKB есть, а в реальности это ночной кошмарик, все криво-косо.

> уезжают монолиты - gimp, mplayer, linux kernel, а гномы и опенофисы по прежнему пугают честных людей..

Забыли добавить "ИМХО". Тут всякая статистика есть. Кстати, внешние зависимости мплейера не ограничиваются glibc/xlibc, а уж про монолитность ядра говорить можно с большим кол-вом оговорок, да и собрать этот монолит криво можно очень легко - готов сделать это на спор;)

> А всех, кто с устаревшим набором инструкций CPU - в бабий яр? Ибо "не стандарт"?

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

svu ★★★★★
()
Ответ на: комментарий от LamerOk

> Может им еще и в "помойке" собственного кода возится не интересно? В этом и есть мой поинт. ))
Своего - интересно. Но так чтоб вокруг не "штормило".

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

Нет, конечно, кроссплатформенные де-факто не в моде (кстати, это грустно, да). Пишут в основном для платформу линух. Потом уже (если кому-то интересно) отдельно берут напильник и точат под бсд, винды, мак,... Чем дальше от линуха - тем больше напильник и больше желания нужно.

> Ключевое слово было - "заставляют".

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



svu ★★★★★
()
Ответ на: комментарий от svu

> Условия условиям люпус эст

Ну тут уж, раз пошла такая пьянка, хомо анимэ сэ ипсе люпус эст, или говоря по-русски ССЗБ.

> Попробуйте поработать, например, с эппловым иксовым сервером ...

Свят-свят-свят.

> Забыли добавить "ИМХО".

Не вижу смысла. Мой ник - "LamerOk", а не "Истина в Последней Инстанции", если что. ))

> Кстати, внешние зависимости мплейера не ограничиваются glibc/xlibc

Во время оны он зохавывал исходники родительских проектов унутря, не признавая динамической связки ни с кем, кроме как с (г)либцы. Т.е. был вполне себе монолитным.

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

Почему сразу железо? С железом, кстати, с тем что есть, ситуация вполне приличная. И опять меня не покидает ощущение, что разговор с разработчиков программы съехал на майнтенера пакета(ов) в дистрибутиве...

LamerOk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.