M>> TBG>Проблема коммерческих организаций в том, что опакечиванием занимается один человек (или группа) и наступает последовательно на все грабли и жалуется. Для опенсорса это будет недействительно, потому что опакечиванием будут заниматься мейнтейнеры дистрибутивов. M>> Не будут. Потому что это тоже люди и их ресурсы тоже ограничены
S>Мамут, с такой уверенностью как в этой фразе можно посреди города мет варить и никто пальцем не тронет S>Только вот блеф все это. в обоих случаях. S>Мейнтейнеры опакечиванием всетаки занимаются и надо быть несколько тугодумом, чтобы оспаривать не просто очевидные факты, а реальные факты.
Где поисковый движок sphinx в Убунту? Почему perl-байндинг к нему есть, а самого движка нет? Ах, он будет только в следующей версии? Можно ли надеяться на бэкпорт в предыдущую (которая всего на полгода старше)? Нет.
Это — очевидные и реальные факты.
Такие же, как и то, что мейнтейнеры — это тоже люди и тоже с ограниченными ресурасми. Так же, как и то, что мейнтейнеры никому ничего не должны.
M>> К чему это я? А, к тому, что последнее время BSOD'ами можно веселить только старперов, кто эти BSOD'ы еще помнит. S>Мамут, ну то-ж ты Ты какбы специально обученный человек, который знает "какая кнопка на компутере что значит"
При чем тут это? Ели слдовать твоей логике, то как раз наоборот — у меня должны БСОДы по пять раз в день вылазить именно из-за того, что я,в принципе, насилую систему поактивнее, чем простой пользователь, которому только бы в игрушки поиграться да в manroulette... то есть chatroulette посидеть.
S>Собственно и я уже мало то помню что с этими синими экранами делать в силу того что их не видел уже пару лет. S>А вот знакомый у меня в ремонте так тот коды ошибок наизусть знает, ибо раз в 2-3 дня стабильно попадается "синячащий" комп
Если он работает в ремонте, то да, это специфика его профессии. Если в городе 10 000 компов, то один BSOD в 2-3 дня как раз и подтверждают мою статистику.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Mamut, вы писали:
M>> TBG>Проблема коммерческих организаций в том, что опакечиванием занимается один человек (или группа) и наступает последовательно на все грабли и жалуется. Для опенсорса это будет недействительно, потому что опакечиванием будут заниматься мейнтейнеры дистрибутивов. M>> Не будут. Потому что это тоже люди и их ресурсы тоже ограничены
S>Мамут, с такой уверенностью как в этой фразе можно посреди города мет варить и никто пальцем не тронет S>Только вот блеф все это. в обоих случаях. S>Мейнтейнеры опакечиванием всетаки занимаются и надо быть несколько тугодумом, чтобы оспаривать не просто очевидные факты, а реальные факты.
Насколько я понял из изучения Дебиана, мейнтейнер выполняет тестирование на совместимость различных версий пакетов. Опакетить KDE или тот же GIMP по либам мейнтейнеру без нормального знания как оно внутри, это, поверь мне, на "п" начинается на "ц" заканчивается. Пакеты как правило готовят сами разрабы, причём мейнтейнеру пофиг что там, rpm или deb или ещё что. Задача мейнтейнера не в опакечивании, а в том чтоб после установки софта из пакета он начал работать без доп телодвижений, в Дебиане ещё и гарантируют стабильную работу, полагаю RHEL и SLES тоже, но я с ними не знаком. Ну и кроме того смотрит чтоб конфиги/логи/прочее лежали в нужных местах.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Приветствую, Mamut, вы писали:
M> Где поисковый движок sphinx в Убунту? Почему perl-байндинг к нему есть, а самого движка нет? Ах, он будет только в следующей версии? Можно ли надеяться на бэкпорт в предыдущую (которая всего на полгода старше)? Нет.
Еще покопайся, найдешь еще много недоделанного.
M> Это — очевидные и реальные факты.
Вполне.
M> Такие же, как и то, что мейнтейнеры — это тоже люди и тоже с ограниченными ресурасми. Так же, как и то, что мейнтейнеры никому ничего не должны.
Поэтому у них ресурсы и ограничены, изза того что они опакечиванием занимаются. Невозможно объять необъятное.
Здравствуйте, Sheridan, Вы писали:
S>А откуда у тебя такая святая уверенность что "в ремонте" == "старье"? Я там неоднократно видал и топовое железо.
"Топовое" не значит "исправное"...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Он просто несмышлёный. Понятно же, что в винде каждая секунда может стать последней.
Ох, иди читай мою нелюбимую М&М что ли... Там тема каждой секунды, которая может стать последней раскрыта хорошо
Кстати, ты уже написал завещание?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
TBG>>Он просто несмышлёный. Понятно же, что в винде каждая секунда может стать последней. E>Ох, иди читай мою нелюбимую М&М что ли... Там тема каждой секунды, которая может стать последней раскрыта хорошо E>Кстати, ты уже написал завещание?
У меня нет такого имущества, которое не поделилось бы нормально в порядке, установленном законами РФ.
Приветствую, Erop, вы писали:
E> TBG>Он просто несмышлёный. Понятно же, что в винде каждая секунда может стать последней. E> Ох, иди читай мою нелюбимую М&М что ли... Там тема каждой секунды, которая может стать последней раскрыта хорошо E> Кстати, ты уже написал завещание?
Тоесть по существу ты согласен, просто тему дополнил?
Turtle.BAZON.Group: Для опенсорса это будет недействительно, потому что опакечиванием будут заниматься мейнтейнеры дистрибутивов.
Mamut: Не будут. Потому что это тоже люди и их ресурсы тоже ограничены
Sheridan: Мейнтейнеры опакечиванием всетаки занимаются и надо быть несколько тугодумом, чтобы оспаривать не просто очевидные факты, а реальные факты.
Mamut: Вот очевидные факты того, что опакечивается не все
Sheridan: Поэтому у них ресурсы и ограничены, изза того что они опакечиванием занимаются. Невозможно объять необъятное.
Приветствую, Mamut, вы писали:
M> Шеридан, у тебя с логикой, как. Все в порядке?
угу.
Turtle.BAZON.Group: Для опенсорса это будет недействительно, потому что опакечиванием будут заниматься мейнтейнеры дистрибутивов.
Mamut: Не будут. Потому что это тоже люди и их ресурсы тоже ограничены
Sheridan: Мейнтейнеры опакечиванием всетаки занимаются и надо быть несколько тугодумом, чтобы оспаривать не просто очевидные факты, а реальные факты.
Mamut: Вот очевидные факты того, что опакечивается не все
Sheridan: Поэтому у них ресурсы и ограничены, изза того что они опакечиванием занимаются. Невозможно объять необъятное.
Здравствуйте, Sheridan, Вы писали:
A>> S>Дело в том, что больше половины "починок" — переустановка винды. A>> а, ты про это... и на кой чёрт тогда знать наизусть коды ошибок? S>Чтобы диагностировать — нужно винду переставить или всетаки железо виновато.
думаю, многим тут было бы интересно узнать, как *по коду ошибки на бсоде* отделить аппаратные проблемы от софтовых
M>> Шеридан, у тебя с логикой, как. Все в порядке? S>угу.
Незаметно
S>
S>Turtle.BAZON.Group: Для опенсорса это будет недействительно, потому что опакечиванием будут заниматься мейнтейнеры дистрибутивов.
S> Mamut: Не будут. Потому что это тоже люди и их ресурсы тоже ограничены
S>Sheridan: Мейнтейнеры опакечиванием всетаки занимаются и надо быть несколько тугодумом, чтобы оспаривать не просто очевидные факты, а реальные факты.
S>Mamut: Вот очевидные факты того, что опакечивается не все
S> Sheridan: Поэтому у них ресурсы и ограничены, изза того что они опакечиванием занимаются. Невозможно объять необъятное.
Это не художественное цитирование. TurtleBazon утверждает, что в опенсорсе поют цветы и поют птички, что там опакечиванием (видимо всего и вся) занимаются специальные люди и проблем с опакечиванием чего-либо вообще в опенсорсе нет (вот это — художественное цитирование).
Я указал на абсолютно очевидный факт, который до тебя, например, не доходит абсолютно.
Ментейнеры вообще не обязаны ничего опакечивать. Они тоже люди и их ресурсы так же ограничены, как и ресурсы любых других людей. Потому сказки про то, что в линуксах надо делать все опенсорсно, потому что кто-то другой озаботится опакечиванием твоей софтины — это именно сказки, за примерами далеко ходить не надо.
При этом ты один в один повторил мои слова, но при этом умудряешься думать, что споришь со мной
Приветствую, Antikrot, вы писали:
A> думаю, многим тут было бы интересно узнать, как *по коду ошибки на бсоде* отделить аппаратные проблемы от софтовых
Ты не поверишь, но мне тоже бы хотелось. Но увы вам, я в той конторе не работаю, да и бсод то видел уже непомню когда в силу того что винду то видел не помню когда...
Здравствуйте, dr.Chaos, Вы писали:
V>>Есть еще рынок библиотек, он посередине.
DC>Посередине чего? В чём принципиальная разница? Мне для либы намного проще ЮТ-ов написать и тестирование под разные дистры ещё быстрее и проще. Понятно что туда не всё можно запихнуть, но намного больше чем для приложения с UI и прочими радостями. Тестирование только дешевле. Проблема с либами в том, что продавать их сейчас довольно не просто, т.к. море открытых бесплатных аналогов, но это проблема уже другая, под вин она ничуть не меньше.
Для рынка заказных библиотек продать не проблема, но возни много, ибо под конкретного клиента надо среду компиляции воссоздать, забилдить и оттестировать. А воссоздать среду, как уже говорил, это не просто некий линух из дистрибутива, это желательно со всеми изменениями и дополнениями, которые нагородил себе клиент. Геммор, короче. Почему так?
Просто все эти зависимости в RPM — одна большая фикция. Несколько примеров:
1. указана зависимость libsome>=1.2.3, самая нубская и самая частовстречающаяся зависимость, грабля на ровном месте. Где гарантия, что со следующими версиями именно твой софт будет работать неплохо? Нету гарантии, что и наблюдается во время постоянных обновлений зависимых продуктов после обновления библиотеки.
2. сами эти бесконечные и детальные списки зависимостей от версий возможны только при наличии большого коммьюнити. Неужели ты не понимаешь, что суммарная общая трудоемкость тестирования пакетов этим коммьюнити может на 2-3 порядка превышать трудоемкость собственно разработки продукта?
3. но даже бардак внутри прямых зависимостей ничто, по сравнению с наведенными эффектами: какой-то пакет проставил свежую свою версию чего-то там, перекинул симв. линк в другое место, и твой софт может умереть, ибо он аккуратно обходил баг предыдущей версии, а без бага... не работает. Да-да, в коммерческом исполнении это был бы старый добрый до-winXP DLL hell, и обязательный саппорт старых багов ввиду требований совместимости... это опенсорсу хорошо — он на все эти "мелочи" ложит с прибором, как ломает не спеша, так не спеша и чинит.
Как ты представляешь себе разруливание 2-го пункта? Опен сорс, который ни за что не в ответе, может позволить себе выпускать бесконечные версии и допиливать их по мере фидбэка от коммьюнити, а у коммерчесских заказчиков и коммьюнити-то не будет, т.к. за деньги люди не стремятся улучшить твой продукт, они будут на компанию-разработчика материться и спрашивать — за что заплачены деньги. Поверь, добровольно искать причины несовместимости и репортить готовые решения, как это делается в opensource-коммьюнити, никто не будет. (пусть тебя не смущает абсолютность заявы, даже если и найдутся пару чел, "по привычке" помогающих бесплатно любимым юниксам, то они погоду не сделают).
В общем, никакая адекватная массовая коммерческая модель тут не выживает. Выживают лишь конкретно-заточенные решения. И когда заказчик апгрейдится (по софту или железу, рано или поздно), то он периодически обращается к разным поставщикам для устранения вновь приобретенных проблем. Поэтому и общеизвестно, что по итогам эксплуатации юнихи и линух в т.ч. очень дорогие, потому и не ставят на рабочие системы никаких обновлений обычно... и речь не о "самых свежих версиях ядра", коммерческие системы по 5-10 лет работают без апгрейда, выжимают из них все соки, ибо опытные начальники IT-отделов прекрасно знают цену этих игр в апгрейды на юнихах.
-----------
Продолжая про классический dll hell. Как указывать зависимости от самого себя, т.е. как себя декларировать для окружающих? На момент выпуска неизвестно, в каких будущих версиях будут ломающие изменения, тем не менее разработчик хочет оставить за собой право делать текущие обновления (меняя версии, разумеется). В виндах, начиная с 2001-го эту проблему красиво решили с помощью манифеста, там можно ориентироваться на public token key, т.е. указывать зависимость по смыслу так: libsome>=1.2.3, p/t/key="abcd0123". И тогда, в случае ломающих изменений, надо просто сменить p.t.key в следующей версии, он служит идентификатором этой "группы совместимости", и загрузчик по манифесту определяет, какую версию DLL лучше всего загружать.
Короче, цель этих манифестов была — добавить еще один признак к номеру версии, отвечающий за совместимость (еще зависимости с конкретным бинарником сопоставлять, а не со всем абстрактным "пакетом", ибо это проще на порядки). Мне, как разработчику, прописывать зависимости в виндах — одно удовольствие, и я достоверно знаю, что однажды прописанную зависимость не надо будет постоянно корректировать. На фоне этого, нынешние системы зависимости "пакетов" в линухах — это прошлый век и фундаментально непреодолимый головняк для отдельно взятых разработчиков (помним о кол-ве необходимого тестирования).
Здравствуйте, Mamut, Вы писали:
M>Это не художественное цитирование. TurtleBazon утверждает, что в опенсорсе поют цветы и поют птички, что там опакечиванием (видимо всего и вся) занимаются специальные люди и проблем с опакечиванием чего-либо вообще в опенсорсе нет (вот это — художественное цитирование).
Не нужно перевирать мои слова. Я утверждаю, что опакечиванием занимаются нужных вещей, которые нужны дистрибутиву. А не всего и вся. Всего и вся никто заниматься не будет и дистрибутива на все случаи жизни тоже не будет.
Здравствуйте, Antikrot, Вы писали:
TBG>>Для опенсорса это будет недействительно, потому что опакечиванием будут заниматься мейнтейнеры дистрибутивов. A>отсюда делаем вывод, что опенсорсом является только то, что в дистрибутивах?
У тебя с логикой всё в порядке?
TBG>>По одному человеку (группе) на пакет. Эта распределённая разработка и сборка идёт в разрез с коммерческим программированием, поэтому эти компании и люди не смогут не находить проблем. Тут даже спорить не стоит, надо только посочувствовать им и посоветовать дождаться коммунизма. A>конечно не будем, ты фигню написал. а я ответить не могу, сам понимаешь по каким соображениям
Да, не всё ладно в королевсте датском. Но если говоришь, что "фигня", то логично ждать обоснования.
Здравствуйте, Mamut, Вы писали:
M>Не будут. Потому что это тоже люди и их ресурсы тоже ограничены
Это не мифические мейнтейнеры, которые за нулевой промежуток времени опакечивают бесконечное количество пакетов. Но если пакет востребован обществом — на него ресурсы найдутся.
Здравствуйте, Antikrot, Вы писали:
A>где ты про сказки прочитал? Тебе просто сказали, что то же самое в винде проще. а ты начал несоглашаться. A>что до меня, (и я это уже говорил), то чем линукс сложнее и глючнее, тем мне лучше. но факты это всё равно не отменяет.
Я уже говорил. Для коммерческих компаний винда явно проще. Но это не делает линукс глючнее и сложнее. И разнообразие пакетных систем при открытой модели вообще не замечается. При закрытой да, грабли, но это уже проблемы коммерческих дистрибуторов. Пусть делают пакеты только под винду. Так нет же — им жадность спокойно спать не даёт. А потом стандартная схема — вентилятор и всё такое.
