K>Загрузчик ищет в подкаталогах programs и других которые у него происаны в конфиге. Для ускорения используется слегка модифицированный ld.so.cache который должен автоматически обновлятся если библиотека не найдена или же перестала существовать. Вполне работоспособно и мало чем отличается от существующей линуксовй схемы. Только струкура каталогов другая и ldconfig будет автоматически дергатся.
Пепец... это при каждом запуске оно будет бегать? (учитывая, что запуск в unix довольно частая процедура)...
Да и поменяем шило на мыло еще и проблем огребем не меньше:
Т.е. фактически все программы расползуться по своим каталогам, а что еще на диске лежит? (понятно что данные типа бд могут быть, но они лежать отдельно в любом случае).
И еще нарвемся на проблему имен... каким образом ld.so будет определять, lib1.so из prog1 ему нужен или из prog2? И как следить за именованием? В общем не надо велосипед прдумывать, структура каталогов unix рассчитана на работу машины, а не чтобы там человек лазил (да и чего он найдет там), а вот автоматическая система помощи релизуема и без всяких реестров, достаточно просто пробежаться по /usr/share/doc и вывести все подкаталоги как названия тем.
ЗЫ: и вообще-то часто бывает когда пакет делает себе подкаталог /usr/lib/gtk-2.0
Re[34]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
D>Да хоть один самый страшный для примера приведи... D>А то достали вопли о глючности Висты от людей которые её в жизни то не видели...а всю инфу вычитали в линуховых конфах...
Падает собака иногда 2000/2003/XP на том же железе работают без проблем.
Re[34]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
K>>Загрузчик ищет в подкаталогах programs и других которые у него происаны в конфиге. Для ускорения используется слегка модифицированный ld.so.cache который должен автоматически обновлятся если библиотека не найдена или же перестала существовать. Вполне работоспособно и мало чем отличается от существующей линуксовй схемы. Только струкура каталогов другая и ldconfig будет автоматически дергатся.
A>Пепец... это при каждом запуске оно будет бегать? (учитывая, что запуск в unix довольно частая процедура)...
Пепец, для тех кто родился в бронепоезде в третий раз напишу: Для ускорения используется слегка модифицированный ld.so.cache
A>Т.е. фактически все программы расползуться по своим каталогам, а что еще на диске лежит? (понятно что данные типа бд могут быть, но они лежать отдельно в любом случае).
Вот и хорошо, ставим/удаляем/перемещаем софт простым копированием/удалением/перемещением каталога программы.
A>И еще нарвемся на проблему имен... каким образом ld.so будет определять, lib1.so из prog1 ему нужен или из prog2? И как следить за именованием? ,
Достаточно просто написать диагностические утилиты для выявления конфликтов, да и простенький пакетный менеджер на такой схеме написать гораздо проще.
A>В общем не надо велосипед прдумывать, структура каталогов unix рассчитана на работу машины,
Она вообще непонятно на что расчитана. Преимущества сомнительные, а недостатков море. Начиная от существенного усложнения пакетных менеджеров и кончая тем что иметь две копии одной программы собранные с разными опциями в такой схеме невозможн.
A>ЗЫ: и вообще-то часто бывает когда пакет делает себе подкаталог /usr/lib/gtk-2.0
... и кладет туда какойнить мусор который к lib вообще не имеет никакого отношения.
Re[35]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, aka50, Вы писали:
A>>Пепец... это при каждом запуске оно будет бегать? (учитывая, что запуск в unix довольно частая процедура)... K>Пепец, для тех кто родился в бронепоезде в третий раз напишу: Для ускорения используется слегка модифицированный ld.so.cache
Сферически подифицированный... вопрос, если он не найдет длл (она перемещена была) начнется новая переиндексация или программа не запуститься? Как быть с конкурентностью (т.е. когда происходит одновременный перенос и запуск)? В общем это все теория о том как было бы хорошо, при этом ни учитывается кучи факторов... в общем у каждого свой бронепоезд и в моем мне комфортнее...
A>>Т.е. фактически все программы расползуться по своим каталогам, а что еще на диске лежит? (понятно что данные типа бд могут быть, но они лежать отдельно в любом случае). K>Вот и хорошо, ставим/удаляем/перемещаем софт простым копированием/удалением/перемещением каталога программы.
Про расползуться — это к тому, что сканировать весь винт... и собственно тема "подгрузка dll-ки c именем lib1.so" не раскрыта.
A>>И еще нарвемся на проблему имен... каким образом ld.so будет определять, lib1.so из prog1 ему нужен или из prog2? И как следить за именованием? , K>Достаточно просто написать диагностические утилиты для выявления конфликтов, да и простенький пакетный менеджер на такой схеме написать гораздо проще.
Нуну... теоретизируем? Если уж в фиксированной струкутре unix каталогов и то проблемы, то со свободной структурой — это в разы сложнее... Да и вопрос, а когда их запускать эти утилиты, ведь директорию могут двинуть в любой момент...
A>>В общем не надо велосипед прдумывать, структура каталогов unix рассчитана на работу машины, K>Она вообще непонятно на что расчитана. Преимущества сомнительные, а недостатков море. Начиная от существенного усложнения пакетных менеджеров и кончая тем что иметь две копии одной программы собранные с разными опциями в такой схеме невозможн.
Никаких проблем иметь на машине mozilla-1.2.12 mozilla-1.3.17 + mozilla->mozilla-1.3.17 + утилита update-alternatives как в debian.
A>>ЗЫ: и вообще-то часто бывает когда пакет делает себе подкаталог /usr/lib/gtk-2.0 K>... и кладет туда какойнить мусор который к lib вообще не имеет никакого отношения.
В твоем случае вообще непредсказуемо, что и где будет лежать... Да и собственно никто туда ничего лишнего не кладет, т.к. есть _стандарт_ на файловую систему...
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Kluev, Вы писали:
K>>Здравствуйте, aka50, Вы писали:
A>>>Пепец... это при каждом запуске оно будет бегать? (учитывая, что запуск в unix довольно частая процедура)... K>>Пепец, для тех кто родился в бронепоезде в третий раз напишу: Для ускорения используется слегка модифицированный ld.so.cache A>Сферически подифицированный... вопрос, если он не найдет длл (она перемещена была) начнется новая переиндексация или программа не запуститься? Как быть с конкурентностью (т.е. когда происходит одновременный перенос и запуск)? В общем это все теория о том как было бы хорошо, при этом ни учитывается кучи факторов... в общем у каждого свой бронепоезд и в моем мне комфортнее...
Если не найдет длл или обнаружит мертвую ссылку, то будет переиндексация, а потом запуск.
И как ты себе представляешь одновременный перенос каталога и запуск из него? Это чтож за пользователь такой который одной рукой программу удаляет, а другой ее запустить пытается?
A>>>Т.е. фактически все программы расползуться по своим каталогам, а что еще на диске лежит? (понятно что данные типа бд могут быть, но они лежать отдельно в любом случае). K>>Вот и хорошо, ставим/удаляем/перемещаем софт простым копированием/удалением/перемещением каталога программы. A>Про расползуться — это к тому, что сканировать весь винт... и собственно тема "подгрузка dll-ки c именем lib1.so" не раскрыта.
Мне уже поднадоело одно и тоже по тыщу раз писать. Сканируется не весь диск, а только те каталоги которые указаны в конфиге. Что же касается подзагрузки то это элементарно, сначала берутся длл из родного каталога программы, если такой нет, то ищем снаружи. Остается утрясти всякие мелочи как загрузчик узнает что это разделяемая длл. Тут два варианта, либо каждая программа имеет определенный скелет каталогов, либо в каталоге с программой идет файлик в котором системе говорится что есть что.
A>>>И еще нарвемся на проблему имен... каким образом ld.so будет определять, lib1.so из prog1 ему нужен или из prog2? И как следить за именованием? , K>>Достаточно просто написать диагностические утилиты для выявления конфликтов, да и простенький пакетный менеджер на такой схеме написать гораздо проще. A>Нуну... теоретизируем? Если уж в фиксированной струкутре unix каталогов и то проблемы, то со свободной структурой — это в разы сложнее... Да и вопрос, а когда их запускать эти утилиты, ведь директорию могут двинуть в любой момент...
надуманные проблеммы. если будет создан неверный индекс то система от этого непострадает, в следующий раз переиндексируется. Или у вас в системе что каждую секунду каталог туда сюда?
A>>>В общем не надо велосипед прдумывать, структура каталогов unix рассчитана на работу машины, K>>Она вообще непонятно на что расчитана. Преимущества сомнительные, а недостатков море. Начиная от существенного усложнения пакетных менеджеров и кончая тем что иметь две копии одной программы собранные с разными опциями в такой схеме невозможн. A>Никаких проблем иметь на машине mozilla-1.2.12 mozilla-1.3.17 + mozilla->mozilla-1.3.17 + утилита update-alternatives как в debian.
Вот-вот. без костыля никак. А как иметь две разные копии в редхат, а в генту? Везде свой собственный костыль со своим собственным бубном. А из-за чего весь этот гемор? Из-за того что структура каталогов неудачная.
A>В твоем случае вообще непредсказуемо, что и где будет лежать... Да и собственно никто туда ничего лишнего не кладет, т.к. есть _стандарт_ на файловую систему...
Ну вот, опять двадцать пять. ...а только те каталоги которые указаны в конфиге
A>Собсвенно, что тут лишнего?
А ты в других таких каталогах поищи, я как-то рылся в федора-коре d /usr/lib нашел там очень много интересного.
Re[37]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
K>Здравствуйте, aka50, Вы писали:
A>>Никаких проблем иметь на машине mozilla-1.2.12 mozilla-1.3.17 + mozilla->mozilla-1.3.17 + утилита update-alternatives как в debian.
Кстати, вопрос на засыпку, как быть разработчикам комерческого софта под линукс? Делать пакет под каждый дистр? Или же делать универсальный инсталлятор для любых дистров? Самое простое это сделать так чтобы программа не требовала установки а запускалась из своего каталога. См. например Оперу. Ее можно развернуть в отдельный каталог и просто оттуда запускать, все её файло будет хранится там, а не в стандартных линуксовых каталогах.
Re[37]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, aka50, Вы писали:
A>>Здравствуйте, Kluev, Вы писали:
K>Если не найдет длл или обнаружит мертвую ссылку, то будет переиндексация, а потом запуск. K>И как ты себе представляешь одновременный перенос каталога и запуск из него? Это чтож за пользователь такой который одной рукой программу удаляет, а другой ее запустить пытается?
Приплыли, начинаются ограничения... А если это программа с библиотекой, нужно другой программе? С package manager — это ноу проблем, с каким-то шибко умным ld.os — это будет проблема (или опять lock-и как в винде).
A>>>>Т.е. фактически все программы расползуться по своим каталогам, а что еще на диске лежит? (понятно что данные типа бд могут быть, но они лежать отдельно в любом случае). K>>>Вот и хорошо, ставим/удаляем/перемещаем софт простым копированием/удалением/перемещением каталога программы. A>>Про расползуться — это к тому, что сканировать весь винт... и собственно тема "подгрузка dll-ки c именем lib1.so" не раскрыта.
K>Мне уже поднадоело одно и тоже по тыщу раз писать. Сканируется не весь диск, а только те каталоги которые указаны в конфиге.
Вот уже и конфиг какой-то появился... нуну, потом пойдут тулзы, для упорядочивания конфигов, потом реестр или package-manager... с чего начали тем и закончили...
K>Что же касается подзагрузки то это элементарно, сначала берутся длл из родного каталога программы, если такой нет, то ищем снаружи.
Ага. В моем usecase lib1.so аж 2 штуки... K> Остается утрясти всякие мелочи как загрузчик узнает что это разделяемая длл.
И это мелочи??? Для этого package manager и существует... именно он "утрясает" эти мелочи... K> Тут два варианта, либо каждая программа имеет определенный скелет каталогов,
Хмм... а если не имеет? K> либо в каталоге с программой идет файлик в котором системе говорится что есть что.
В deb пакете тоже идут файлики... но за счет единой структуры часто файлики эти не нужны вообще (за счет чего например checkinstall замечательно рожает их сам).
A>>>>И еще нарвемся на проблему имен... каким образом ld.so будет определять, lib1.so из prog1 ему нужен или из prog2? И как следить за именованием? , K>>>Достаточно просто написать диагностические утилиты для выявления конфликтов, да и простенький пакетный менеджер на такой схеме написать гораздо проще. A>>Нуну... теоретизируем? Если уж в фиксированной струкутре unix каталогов и то проблемы, то со свободной структурой — это в разы сложнее... Да и вопрос, а когда их запускать эти утилиты, ведь директорию могут двинуть в любой момент...
K>надуманные проблеммы. если будет создан неверный индекс то система от этого непострадает, в следующий раз переиндексируется. Или у вас в системе что каждую секунду каталог туда сюда?
Т.е. после каждого cp myprog mynewprog надо делать переиндексацию, но вот вопрос, допустим был там файлик, что типа lib1.so — разделяемая... какую из lib1.so (myprog/lib1.so и mynewprog/lib1.so) будем использовать? А если эти библиотеки порты поднимают для rpc? А если они shared memory с ключом создают (как oracle)?
Может не надо придумывать, а проще, что разработчик программ следовал правилу: все конфигурируется через конифг, а конфиг задается ключом -f? И тогда и копировать ничего не надо...
A>>>>В общем не надо велосипед прдумывать, структура каталогов unix рассчитана на работу машины, K>>>Она вообще непонятно на что расчитана. Преимущества сомнительные, а недостатков море. Начиная от существенного усложнения пакетных менеджеров и кончая тем что иметь две копии одной программы собранные с разными опциями в такой схеме невозможн. A>>Никаких проблем иметь на машине mozilla-1.2.12 mozilla-1.3.17 + mozilla->mozilla-1.3.17 + утилита update-alternatives как в debian. K>Вот-вот. без костыля никак. А как иметь две разные копии в редхат, а в генту? Везде свой собственный костыль со своим собственным бубном. А из-за чего весь этот гемор? Из-за того что структура каталогов неудачная.
Структура нормальная, но требующая следования правилам. Мне ничего не мешает поставить mozill-1.2.12.rpm и mozilla-1.3.17.rpm и руками (ведь в твоем случае вообще все руками, перенос, правка файликов) сделать линк на нужную мне mozillа (или вообще не делать ничего, запускать прям с версией). ПРи этом программы, собранные с использованием libmozilla.so.1.2.12 будут использовать правильную библиотеку и программы c libmozilla.so.1.3.17 — тоже правильную...
A>>В твоем случае вообще непредсказуемо, что и где будет лежать... Да и собственно никто туда ничего лишнего не кладет, т.к. есть _стандарт_ на файловую систему... K>Ну вот, опять двадцать пять. ...а только те каталоги которые указаны в конфиге
Каком конфиге? Если весь диск переползет в /programs и жесткой структуры у каталогов программ нет? А даже если есть, каждая установка софта требует _прав админа_! для правки этого конфига... бред какой-то (хотя в винде так есть, особенно в висте, любой запуск инсталятора выливается в черное окно, хотя многому софту админские права вообще нафиг не нужны).
ЗЫ: в никсе тоже при установке надо рута, но можно ставить свой софт в /usr/local и дать себе туда права а так же обучить ldconfig искать в /usr/local/lib, и это проще, т.к. не надо никаких кофигов, положил so в /usr/local/lib и оно работает... И при этом не создается угрозы безопасности т.к. ld первым делом найдет в прошитых /usr/lib /lib (например я мог бы подменить libX11.so поправив конфиг своей, которая например перехватывает все события типа клавиатурных или заменить libc и получить доступ ко всем программам в системе)
A>>Собсвенно, что тут лишнего? K>А ты в других таких каталогах поищи, я как-то рылся в федора-коре d /usr/lib нашел там очень много интересного.
Ну поглядел... кроме so там еще можно встретить pyc или beam... ну дык не все же на C/C++ написано, библиотеки есть и у других языков. Есть еще правда X11, вот у них да,
было раньше, сейчас все что нужно в etc или share перехало... Т.е. причешут рано или поздно...
Re[38]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
Здравствуйте, Kluev, Вы писали:
K>>Здравствуйте, aka50, Вы писали:
A>>>Никаких проблем иметь на машине mozilla-1.2.12 mozilla-1.3.17 + mozilla->mozilla-1.3.17 + утилита update-alternatives как в debian.
K>Кстати, вопрос на засыпку, как быть разработчикам комерческого софта под линукс? Делать пакет под каждый дистр? Или же делать универсальный инсталлятор для любых дистров? Самое простое это сделать так чтобы программа не требовала установки а запускалась из своего каталога. См. например Оперу. Ее можно развернуть в отдельный каталог и просто оттуда запускать, все её файло будет хранится там, а не в стандартных линуксовых каталогах.
Почему под каждый дистр? менеджеров пакетов по сути 2: deb и rpm. Если этот софт не является системным, ему фиолетово что за дистр (важнее наличие нужных зависимостей). А системный должен быть под каждый дистр (и в этом нет ничего удивительного, под win тоже утилиты бывают под nt и 95-й напрмиер). Т.е. производитель выбирает 2 дистра, ему симпатичных (suse и ubuntu например) а на остальные кладет. Желающие пределают пакет для своих дистрибутивов и пришлют патч... после этого производитель может добавит этот дистрибутив в поддерживаемые...
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Kluev, Вы писали:
K>>Здравствуйте, aka50, Вы писали:
A>>>Здравствуйте, Kluev, Вы писали:
A> Приплыли, начинаются ограничения... А если это программа с библиотекой, нужно другой программе? С package manager — это ноу проблем, с каким-то шибко умным ld.os — это будет проблема (или опять lock-и как в винде).
А вот такого быть не должно. Библиотеки которые действительно разделяются м-ду многими приложениями должны стоять в одтельных каталогах, а не в каком-то каталоге с программой. Это же элементарные вещи, зачем выдумывать надуманные ситуации? Более того в такой системе может быть простенький менеджер пакетов. Хочешь менеджер юзай, а если ты опытный пользователь нет проблем руками ставь.
K>>Что же касается подзагрузки то это элементарно, сначала берутся длл из родного каталога программы, если такой нет, то ищем снаружи. A>Ага. В моем usecase lib1.so аж 2 штуки...
А сейчас в линупсе такого быть не может?
/lib/cool.so
/usr/lib/cool.so
/usr/local/lib/cool.so
-> каталог прописаный в LD_LIBRARY_PATH:
/bla-bla-bla/cool.so
K>>надуманные проблеммы. если будет создан неверный индекс то система от этого непострадает, в следующий раз переиндексируется. Или у вас в системе что каждую секунду каталог туда сюда? A>Т.е. после каждого cp myprog mynewprog надо делать переиндексацию, но вот вопрос, допустим был там файлик, что типа lib1.so — разделяемая... какую из lib1.so (myprog/lib1.so и mynewprog/lib1.so) будем использовать? А если эти библиотеки порты поднимают для rpc? А если они shared memory с ключом создают (как oracle)?
и чего такого? между прочим при каждой установек пакета ldconfig вызывается. т.е. ld.so.cache перегенерируется и ничего работает же.
A>Структура нормальная, но требующая следования правилам. Мне ничего не мешает поставить mozill-1.2.12.rpm и mozilla-1.3.17.rpm и руками (ведь в твоем случае вообще все руками, перенос, правка файликов) сделать линк на нужную мне mozillа (или вообще не делать ничего, запускать прям с версией). ПРи этом программы, собранные с использованием libmozilla.so.1.2.12 будут использовать правильную библиотеку и программы c libmozilla.so.1.3.17 — тоже правильную...
Поставит rpm руками это как? Для полноты картины будем так же считать, что в твоем дистре другой менеджер пакетов. В этом случае прийдется тупо распаковать это файло и залить по каталогам. Особенно приятно будет потом эти программы из системы удалять.
A>Каком конфиге?
Вконфиге где будут описаны корневые каталоги для программ. Обясню на примере винды чтобы было понятно
#конфиг:
c:\Program Files
d:\Utils
e:\Bla-Bla-Bla
Каждый из этих каталогов содержит кучу подкаталогов с программами.
A>Если весь диск переползет в /programs
Всему диску то зачем туда лезть?
A>было раньше, сейчас все что нужно в etc или share перехало... Т.е. причешут рано или поздно...
Свежо предание
Re[6]: Сравнение Microsoft Windows Vista и Mandriva Linux 20
Здравствуйте, LuciferArh, Вы писали:
LA>Поработал мало-мало... Половина моего оборудования на ней просто не стала. Потому как старое. В частности, карточка пинакловская, ТВ-тюнер. Дров для них нет и не будет. И нафига мне такая система? Выложить полтыщи баксов на железо, да еще и за саму систему заплатить... Да ну ее к черту. К тому же, скачать все вышедшие к ней обновления — это тоже тот еще геморрой. Потому что они весят неслабо, и трафик у меня не дешевый. Ну и так далее...
Угу. Виста отстой т.к. не встает на IBM PC/ХТ. Это да. Это в точку, млин. В требованиях к системе, вообще-то, сказано, что ей надо для нормальной работы. Иногда сии вещи читать не помешает, чтобы потом не плакаться. Вот для примера: Мандряка значительно скромнее по требованиям. Да — это так. Имеем: ноутбук Acer Aspire 1640z WLMi. Стартанула, завлесаь. Долго размышляла на тебу драйверов. Таки настроилась. Настраиваем доступ PPPoE ч/з WiFi и тут к нам прилетает большая розовая птица абламинго. Ну никак сия ОС не считает WiFi адаптер за сетевую карту. Хотя нашла и установила оную. Никакие шаманские пляски не помогли. Далее — пытаемся переключиться в любую оболочку акромя KDE и Gnome. И что? А ничего — считает это верхом извращения и возвертает в экран логина и пароля. Хрен с тобой — выбираем KDE: опаньки! Таже фигня. Перестартуем иксы — безрезультатно. Перегружаемся. Ура! КДЕ запустилось. Раз загрузились, второй, третий... На четвертый раз мертвый висяк при старте на уровне определения HAL. Приехали. Никакие рековери не помогают — только полная переустановка. Весело до офигения.
Сьюзя 10.2 — считает, что экран у оного бука 1024х768 и звук ему не положен. SLED 10 — хорошо хоть экран дает настроить. Звук тоже не хатит принимать ни под каким соусом. WiFi — это не сетевая карта, а сплошное недоразумение по мнению сей операционки.
Федора 6 — ну эта и вставать отказалась.
Убунта — даже не загрузилась с загрузочного ДВД
Gentoo — сделала жалкие потуги на старт, но повисла к едреней фене и помогла только кнопка вырубания питания.
Другие пробовать не стал — надоело.
Вот и вопрос: ну и нафига такое юзер-френдли?
Виста — от установки до первого старта — 24 минуты. Единственно, что потребовалось — доустановить драйвер звука. Все! Система работает и не жалуется. Причем весело так работает. Все сетевые интерфейсы определились и настроились на этапе установки без каких-либо телодвижений. Тут же качнул обновки. Настроил Студию и MSSQL. Офис 2007 встал за 22 мин (ставил от души — полную про-версию со всеми пирогами). NOD 32 — качнул с сайта версию для Висты и в путь. Никаких траблов и проблем.
Вот и что лучше в этом случае?
Сложность программы растет до тех пор, пока не превысит способности программиста
Re[7]: Сравнение Microsoft Windows Vista и Mandriva Linux 20
Здравствуйте, Menestrel, Вы писали:
M>Угу. Виста отстой т.к. не встает на IBM PC/ХТ. Это да. Это в точку, млин. В требованиях к системе, вообще-то, сказано, что ей надо для нормальной работы. Иногда сии вещи читать не помешает, чтобы потом не плакаться.
Так я и читаю... Но вот вопрос: есть у меня тот же пресловутый TV-Tuner AverMedia-307. Он работает. Отлично работает. И нафига мне его менять на что-то другое, что будет работать под вистой? Ладно, не спорим. Стоит оно "копейки" примерно в 2500 рублей. А Pinnacle 500Pro? Оно уже очень даже не копейки стоит. А мне надо для работы, пусть и не профессиональной, а только для себя. А видяха моя Radeon 9600Pro? Виста говорит, что сия карта не поддерживает DX10, поэтому работать карточка не будет как положено. Итого мне надо поменять всю систему, включая мать, процессор и память, потому что под мать AGP, да еще и Socket939 "нормальной" видяхи, которая понравится висте, уже не найти.
M>Другие пробовать не стал — надоело. M>Вот и вопрос: ну и нафига такое юзер-френдли?
Ну, не знаю. Я поставил Debian. Все железо, за исключением опять же видяхи, определилось нормально и нормально заработало. Видео нормально заработало после установки родного, скаченного с сайта производителя, драйвера. Все! Все телодвижения. Тюнер пашет, видеозахват тоже. WiFi не проверял за его отсутствием, но знакомый админ "промучился" с его установкой две минуты.
M>Виста — от установки до первого старта — 24 минуты. Единственно, что потребовалось — доустановить драйвер звука. Все! Система работает и не жалуется. Причем весело так работает. Все сетевые интерфейсы определились и настроились на этапе установки без каких-либо телодвижений. Тут же качнул обновки. Настроил Студию и MSSQL. Офис 2007 встал за 22 мин (ставил от души — полную про-версию со всеми пирогами). NOD 32 — качнул с сайта версию для Висты и в путь. Никаких траблов и проблем.
И сколько обновки потянули в мегабайтах? Э? Если не секрет, конечно. Регулярное обновление моей системы — раз в месяц — тянет на 25-30 метров. Потому что качаются обновления только тех пакетов, которые реально стоят в системе. В отличие от того же Windows, который, как малое дитя, тянет в рот всяку каку... Установка системы, включая офис и средства разработки, с настройкой репозитория, чтоб потом компакты не терзать, занимает часа полтора, если не изгаляться с тонкой настройкой ядра и окружения. В итоге я получаю рабочую машину, на которой стоит все. При этом денег я трачу ровно ноль рублей. Или чуть больше, если с интернета сразу скачиваю обновления.
... << RSDN@Home 1.2.0 alpha rev. 669>>
Re[39]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, aka50, Вы писали:
A>>Здравствуйте, Kluev, Вы писали:
K>А вот такого быть не должно. Библиотеки которые действительно разделяются м-ду многими приложениями должны стоять в одтельных каталогах, а не в каком-то каталоге с программой. Это же элементарные вещи, зачем выдумывать надуманные ситуации? Более того в такой системе может быть простенький менеджер пакетов. Хочешь менеджер юзай, а если ты опытный пользователь нет проблем руками ставь.
Т.е. будет отдельно system32, а отдельно все остальные... не, спасибо, в системе должно быть просто и однообразно, иначе это будет бардак.
K>>>Что же касается подзагрузки то это элементарно, сначала берутся длл из родного каталога программы, если такой нет, то ищем снаружи. A>>Ага. В моем usecase lib1.so аж 2 штуки... K>А сейчас в линупсе такого быть не может?
K>/lib/cool.so K>/usr/lib/cool.so K>/usr/local/lib/cool.so
1. Не может, имена уникальны.
2. /lib /usr/lib и /usr/local/lib имеют разное назначение и имеют строго детерминированный алогоритм обхода. В твоем случае не понятно в myprog или в mynewprog идти
->> каталог прописаный в LD_LIBRARY_PATH: K>/bla-bla-bla/cool.so
Это ты сам себе ССЗБ если что-то в LD_LIBRARY_PATH прописываешь... при нормальной установке софта LD_LIBRARY_PATH трогать не надо (у меня он пустой).
K>>>надуманные проблеммы. если будет создан неверный индекс то система от этого непострадает, в следующий раз переиндексируется. Или у вас в системе что каждую секунду каталог туда сюда? A>>Т.е. после каждого cp myprog mynewprog надо делать переиндексацию, но вот вопрос, допустим был там файлик, что типа lib1.so — разделяемая... какую из lib1.so (myprog/lib1.so и mynewprog/lib1.so) будем использовать? А если эти библиотеки порты поднимают для rpc? А если они shared memory с ключом создают (как oracle)?
K>и чего такого?
Дык как быть с rpc, shared memory и др? K>между прочим при каждой установек пакета ldconfig вызывается. т.е. ld.so.cache перегенерируется и ничего работает же.
Но менеджер пакетов может предупредить или даже перезапустить зависимые сервисы. Да и /usr/lib и без кеша замечательно сканируется самим ld.so
A>>Структура нормальная, но требующая следования правилам. Мне ничего не мешает поставить mozill-1.2.12.rpm и mozilla-1.3.17.rpm и руками (ведь в твоем случае вообще все руками, перенос, правка файликов) сделать линк на нужную мне mozillа (или вообще не делать ничего, запускать прям с версией). ПРи этом программы, собранные с использованием libmozilla.so.1.2.12 будут использовать правильную библиотеку и программы c libmozilla.so.1.3.17 — тоже правильную...
K>Поставит rpm руками это как? Для полноты картины будем так же считать, что в твоем дистре другой менеджер пакетов. В этом случае прийдется тупо распаковать это файло и залить по каталогам. Особенно приятно будет потом эти программы из системы удалять.
Не придется, я для таких вещей использую конвертер alien (не всегда корректно, когда еще нужны какие-то скрипты запускать, но обычно нормально).
K>Каждый из этих каталогов содержит кучу подкаталогов с программами. A>>Если весь диск переползет в /programs K>Всему диску то зачем туда лезть?
А что еще кроме данных этих программ лежит на допустим системном диске С:? Да и данные программ по твоей идеологии лежат _рядом_ в том же каталоге, т.е. в program files/msoffice будет лежать все что относиться к офису (в том числе и клипарт например).
Re[7]: Сравнение Microsoft Windows Vista и Mandriva Linux 20
Здравствуйте, Menestrel, Вы писали:
M>Здравствуйте, LuciferArh, Вы писали:
M>Угу. Виста отстой т.к. не встает на IBM PC/ХТ. Это да. Это в точку, млин. В требованиях к системе, вообще-то, сказано, что ей надо для нормальной работы. Иногда сии вещи читать не помешает, чтобы потом не плакаться. Вот для примера: Мандряка значительно скромнее по требованиям. Да — это так. Имеем: ноутбук Acer Aspire 1640z WLMi. M>Вот и вопрос: ну и нафига такое юзер-френдли?
Ты сам себе противоречишь... На ноутбуке написано, что оно linux-comaptible? Нет? Ну тогда какие вопросы и при чем тут user-friendly?
M>Вот и что лучше в этом случае?
Внимательно читать этикетки... не более ни менее... Например на таких сайтах http://tuxmobil.org/acer.html, где люди делятся опытом http://ax5.com/laptops/acer_aspire_1642 (правда это немного другая модель)
[quote]
At first i tried Ubuntu 5.04, the graphics did not work. Then I tried Ubuntu 5.10 and the following happend.
* Ethernet Ok
* Wifi gives problems with kill-switch. It does not have a hardware kill-switch to disable wireless networking, and the software changes sometimes. You can change it by pressing a button but there is no led or any other indicator of its state.
* 2D Ok
* Sound does NOT work. I can only find text explaining the same problem I have. The sound card HDA-Intel produces no sound . I tried many ways, It is not the mixer. Maybe a solution
* Modem is not recognized, probably winmodem. I didn't even tried.
* ACPI doesn't work by default, it says is running on power while running on batteries. It hangs on suspend or hibernation.
[/quote]
Здравствуйте, aka50, Вы писали:
K>>>>Что же касается подзагрузки то это элементарно, сначала берутся длл из родного каталога программы, если такой нет, то ищем снаружи. A>>>Ага. В моем usecase lib1.so аж 2 штуки... K>>А сейчас в линупсе такого быть не может?
K>>/lib/cool.so K>>/usr/lib/cool.so K>>/usr/local/lib/cool.so
A>1. Не может, имена уникальны. A>2. /lib /usr/lib и /usr/local/lib имеют разное назначение и имеют строго детерминированный алогоритм обхода. В твоем случае не понятно в myprog или в mynewprog идти
->>> каталог прописаный в LD_LIBRARY_PATH: K>>/bla-bla-bla/cool.so A>Это ты сам себе ССЗБ если что-то в LD_LIBRARY_PATH прописываешь... при нормальной установке софта LD_LIBRARY_PATH трогать не надо (у меня он пустой).
Вот и в моем случае точно так же. Если все делает менеджер пакетов то проблем не возникнет, но при этом есть возможность без гемороя поставить руками, а когда ставишь руками тогда должен понимать, что делаешь. В твоем же случае если не оказалось пакета или пакет от другого дистра, то без кучи костылей ничего по человечески не сделаешь.
K>>и чего такого? A>Дык как быть с rpc, shared memory и др? K>>между прочим при каждой установек пакета ldconfig вызывается. т.е. ld.so.cache перегенерируется и ничего работает же. A>Но менеджер пакетов может предупредить или даже перезапустить зависимые сервисы. Да и /usr/lib и без кеша замечательно сканируется самим ld.so
А я что против что-ли. Я нигдене говорил что менеджер пакетов в топку. Просто на схеме в которой у каждой проги свой каталог
1) и менеждер пакетов проще сделать
2) и контролировать глазами всю эту кучу софта проще, достаточно в каталог войти
3) и управлятся ручками с софтом можно без костылей, а простыми файловыми операциями.
A>>>Структура нормальная, но требующая следования правилам. Мне ничего не мешает поставить mozill-1.2.12.rpm и mozilla-1.3.17.rpm и руками (ведь в твоем случае вообще все руками, перенос, правка файликов) сделать линк на нужную мне mozillа (или вообще не делать ничего, запускать прям с версией). ПРи этом программы, собранные с использованием libmozilla.so.1.2.12 будут использовать правильную библиотеку и программы c libmozilla.so.1.3.17 — тоже правильную...
K>>Поставит rpm руками это как? Для полноты картины будем так же считать, что в твоем дистре другой менеджер пакетов. В этом случае прийдется тупо распаковать это файло и залить по каталогам. Особенно приятно будет потом эти программы из системы удалять. A>Не придется, я для таких вещей использую конвертер alien (не всегда корректно, когда еще нужны какие-то скрипты запускать, но обычно нормально).
Опять очередная сказка про костыли. А без костылей как?
K>>Каждый из этих каталогов содержит кучу подкаталогов с программами. A>>>Если весь диск переползет в /programs K>>Всему диску то зачем туда лезть? A>А что еще кроме данных этих программ лежит на допустим системном диске С:? Да и данные программ по твоей идеологии лежат _рядом_ в том же каталоге, т.е. в program files/msoffice будет лежать все что относиться к офису (в том числе и клипарт например).
И чего плохого, что клипарт лежит в том же каталоге? при желании я его в месте с клипартом и прибью, если он мне не понадобится.
Здравствуйте, Zuka, Вы писали:
Z>Здравствуйте, alpha21264, Вы писали:
A>>Таки да. Поинтересуйся когда был написан tex и когда в нем была найдена последняя ошибка. A>>Про grep и говорить как-то неудобно...
A>>А вообще, не количеством программ надо оси мерять.
Z>А что под Windows текса и грепа нету? Есть. И вообще софта который есть под никсы и не портированного под винду очень очень мало. А софта под винду не портированного на линукс — тонны. Поэтому заявление что под Линуксом софта больше вызывает закономерное недоумение.
Я совсем не про то. Посмотри выше по треду.
Товарищ удивился, что в Линуксе/Юниксе программы по 30 используются и не устаревают.
Я подтвердил, что это именно так. И привел пример такой программы (двух).
Вот как ты думаешь, если у меня дома стоит RedHat 7.3
а) с какого года он стоит?
б) почему стоит до сих пор?
Течёт вода Кубань-реки куда велят большевики.
Re[35]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
Здравствуйте, Kluev, Вы писали:
K>Вот и хорошо, ставим/удаляем/перемещаем софт простым копированием/удалением/перемещением каталога программы.
Стоп. Если искать будет только в каталогах которые прописаны в конфиге, то как же я могу просто перемещать программу куда попало?
A>>И еще нарвемся на проблему имен... каким образом ld.so будет определять, lib1.so из prog1 ему нужен или из prog2? И как следить за именованием? , K>Достаточно просто написать диагностические утилиты для выявления конфликтов, да и простенький пакетный менеджер на такой схеме написать гораздо проще.
Меня и нынешние dpkg и apt устраивают.
A>>В общем не надо велосипед прдумывать, структура каталогов unix рассчитана на работу машины, K>Она вообще непонятно на что расчитана. Преимущества сомнительные, а недостатков море. Начиная от существенного усложнения пакетных менеджеров и кончая тем что иметь две копии одной программы собранные с разными опциями в такой схеме невозможн.
У меня стоит 2 версии одной программы. Значит возможно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[37]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
Здравствуйте, Kluev, Вы писали:
K>Если не найдет длл или обнаружит мертвую ссылку, то будет переиндексация, а потом запуск. K>И как ты себе представляешь одновременный перенос каталога и запуск из него? Это чтож за пользователь такой который одной рукой программу удаляет, а другой ее запустить пытается?
Переносим каталог с длл-кой, а запускаем программу которая её использует.
И ещё вопрос. а что будет если я захочу переместить каталог, в котором будет длл-ка используемая в данный момент? на данный момент я знаю что перемещать каталоги нежелательно, но тут ведь новая идиология, тут можно... но о последствиях то не подумали.
K>Мне уже поднадоело одно и тоже по тыщу раз писать. Сканируется не весь диск, а только те каталоги которые указаны в конфиге. Что же касается подзагрузки то это элементарно, сначала берутся длл из родного каталога программы, если такой нет, то ищем снаружи. Остается утрясти всякие мелочи как загрузчик узнает что это разделяемая длл. Тут два варианта, либо каждая программа имеет определенный скелет каталогов, либо в каталоге с программой идет файлик в котором системе говорится что есть что.
Так и сейчас программы в Линуксе имеют скелет каталогов, вот только он один на всех
A>>>>И еще нарвемся на проблему имен... каким образом ld.so будет определять, lib1.so из prog1 ему нужен или из prog2? И как следить за именованием? , K>>>Достаточно просто написать диагностические утилиты для выявления конфликтов, да и простенький пакетный менеджер на такой схеме написать гораздо проще. A>>Нуну... теоретизируем? Если уж в фиксированной струкутре unix каталогов и то проблемы, то со свободной структурой — это в разы сложнее... Да и вопрос, а когда их запускать эти утилиты, ведь директорию могут двинуть в любой момент...
K>надуманные проблеммы. если будет создан неверный индекс то система от этого непострадает, в следующий раз переиндексируется. Или у вас в системе что каждую секунду каталог туда сюда?
В винде бывает что переношу каталоги, а вот в линуксе пока не приходилось Но переиндексировать всю базу на каждый чих пользователя это не дело.
A>>>>В общем не надо велосипед прдумывать, структура каталогов unix рассчитана на работу машины, K>>>Она вообще непонятно на что расчитана. Преимущества сомнительные, а недостатков море. Начиная от существенного усложнения пакетных менеджеров и кончая тем что иметь две копии одной программы собранные с разными опциями в такой схеме невозможн. A>>Никаких проблем иметь на машине mozilla-1.2.12 mozilla-1.3.17 + mozilla->mozilla-1.3.17 + утилита update-alternatives как в debian. K>Вот-вот. без костыля никак. А как иметь две разные копии в редхат, а в генту? Везде свой собственный костыль со своим собственным бубном. А из-за чего весь этот гемор? Из-за того что структура каталогов неудачная.
Ну пользователю не важно бывает сколько у него версий, лишь бы работало. А если уж возникает необходимость в нескольких версиях, то либо будьте добры, разбирайтесь, либо ССЗБ.
A>>В твоем случае вообще непредсказуемо, что и где будет лежать... Да и собственно никто туда ничего лишнего не кладет, т.к. есть _стандарт_ на файловую систему... K>Ну вот, опять двадцать пять. ...а только те каталоги которые указаны в конфиге
А если в конфиге не указано то место в которое я перенес программу?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[41]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
Здравствуйте, Kluev, Вы писали:
K>А я что против что-ли. Я нигдене говорил что менеджер пакетов в топку. Просто на схеме в которой у каждой проги свой каталог K>1) и менеждер пакетов проще сделать
Менеджер пакетов уже сделан.
K>2) и контролировать глазами всю эту кучу софта проще, достаточно в каталог войти
Ага, захожу в каталог /programms/ а там 500 подкаталогов на каждую программу, и чем это лучше /usr/bin ?
K>3) и управлятся ручками с софтом можно без костылей, а простыми файловыми операциями.
Ага, только вот результат этого управления почему-то не всегда очевиден....
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[41]: Сравнение Microsoft Windows Vista и Mandriva Linux 2
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, aka50, Вы писали:
K>Вот и в моем случае точно так же. Если все делает менеджер пакетов то проблем не возникнет, но при этом есть возможность без гемороя поставить руками, а когда ставишь руками тогда должен понимать, что делаешь. В твоем же случае если не оказалось пакета или пакет от другого дистра, то без кучи костылей ничего по человечески не сделаешь.
Да почему? что мешает то? Ну пропиши ты каталоги с so для этой проги в ld.conf да и будет тебе счастье (ну еще PATH не забудь)... Но это будет криво и сломается система зависимостей... а если руками что-то двигать, как без костылей об этом узнает менеджер пакетов?
K>>>и чего такого? A>>Дык как быть с rpc, shared memory и др? K>>>между прочим при каждой установек пакета ldconfig вызывается. т.е. ld.so.cache перегенерируется и ничего работает же. A>>Но менеджер пакетов может предупредить или даже перезапустить зависимые сервисы. Да и /usr/lib и без кеша замечательно сканируется самим ld.so
K>А я что против что-ли. Я нигдене говорил что менеджер пакетов в топку. Просто на схеме в которой у каждой проги свой каталог K>1) и менеждер пакетов проще сделать
Не проще. Менеджеру пакетов и так проблем хватает с зависмисотями, еще и костыли прикручивать, которые позволят объяснять куда чего перенесли... K>2) и контролировать глазами всю эту кучу софта проще, достаточно в каталог войти
Что именно ты собрался там контролировать? Ты увидишь трояна? А я могу сказать, что запускаемые файлы могут быть только в /usr/bin /bin/ /lib и /usr/lib и все. Ни один троян невозможно будет запустить, т.к. система не позволит задать права выполнения даже под root... Как это в твоей схеме кроме выкрутасов с наследованием прав сделать я не знаю. K>3) и управлятся ручками с софтом можно без костылей, а простыми файловыми операциями.
Нельзя, ты же сам выше про менеджера рассказывал и конфиги...
A>>>>Структура нормальная, но требующая следования правилам. Мне ничего не мешает поставить mozill-1.2.12.rpm и mozilla-1.3.17.rpm и руками (ведь в твоем случае вообще все руками, перенос, правка файликов) сделать линк на нужную мне mozillа (или вообще не делать ничего, запускать прям с версией). ПРи этом программы, собранные с использованием libmozilla.so.1.2.12 будут использовать правильную библиотеку и программы c libmozilla.so.1.3.17 — тоже правильную...
K>>>Поставит rpm руками это как? Для полноты картины будем так же считать, что в твоем дистре другой менеджер пакетов. В этом случае прийдется тупо распаковать это файло и залить по каталогам. Особенно приятно будет потом эти программы из системы удалять. A>>Не придется, я для таких вещей использую конвертер alien (не всегда корректно, когда еще нужны какие-то скрипты запускать, но обычно нормально).
K>Опять очередная сказка про костыли. А без костылей как?
Руками поставить в /usr/local/apache например. в ld.so.conf прописать /usr/local/apache/lib в PATH /usr/local/apache/bin и радоваться жизни... (у меня так к стити некоторые java проги живут, пока я не пойму, что они мне нужны и не конвертну их в пакет)
K>>>Всему диску то зачем туда лезть? A>>А что еще кроме данных этих программ лежит на допустим системном диске С:? Да и данные программ по твоей идеологии лежат _рядом_ в том же каталоге, т.е. в program files/msoffice будет лежать все что относиться к офису (в том числе и клипарт например).
K>И чего плохого, что клипарт лежит в том же каталоге? при желании я его в месте с клипартом и прибью, если он мне не понадобится.
То, что его много и его надо будет сканировать...
В общем надоело из пустого в порожнее... в linux есть система, она реализована и позовляет урпавлять тем несметным кол-вом софта, который еще и пытается переиспользовать другой софт... и это реально работает. Твои предложения — это фантазии и рельано рабочей системы нет. Есть в винде система управления зависмостями, но ей почти никто не пользуется, ибо все привыкли тащить все за собой и жить в одном каталоге... но проблем это не решает, а прибавляет (ddl-hell, множестов копий одной библиотеки, каталог system32 — как мусорка куда кладут все подряд и хоршо если что-то зарегистрируют, только без супер костылей это вообще найти невозможно, т.е. по сути /usr/lib только безконтрольный)...
ЗЫ: к стати именно благодаря такой схеме возможно столь многочисленные LiveCD, т.к. четко известно, где может быть readonly, а где нужна возможность записи, при этом опять же четко известно, где изменения должы сохраняться (/usr/home), а где это временные...(/var). При предлагаемом тобой бардаке мне придется ставить софт на rw флешку например, ведь я не знаю чего он захочет делать в своем каталоге...