да и потом пока лазиишь по форому в поисках решения актуальной проблемы невольно натыкаешься на темы на которые так и подмывает ответить...
Не, ну я понимаю, если встречаешь нерешенную проблему 3-х летней давности, с которой ты тоже столкнулся на днях, пусть и с новым ядром и прочим, и успешно решил.
А отвечать владельцу ядра 2.2.х как прикруть флешку (условно говоря): "Да ты че гонишь, все в ядре уже включено!" (еще бы, в 2.6.2х ) - это даже не смешно.
Целый день пытаюсь установить Virtual Box (до сих пор устанавливаю), еле сообразил откуда брать rtld(GNU_HASH) неужели никак нельзя собирать пакеты, чтоб "все в одном" было?
Граждане линуксоиды, вот уже на протяжении нескольких лет я с завидной периодичностью устанавливаю линуксы новых версий (начинал с RedHat 7.2, сейчас FreeBSD 6.0), и через неделю удаляю из-за жуткого неудобства и полной несовершенности логики системы. Или может быть я что-то недопонимаю во всех прелестях *nix?
Вот скажите, пожалуйста, почему в *nix нет подобия Program Files? Куда по умолчанию ставятся все приложения? Приложения в *nix могут находиться где угодно и быть разбросаны по множеству каталогов: /usr, /usr/local, /usr/local/share, /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin и т.д. и т.п... Взяв любую линуксовую программу можно с уверенностью сказать, что только ее создатель знает, где находятся все ее части.
Почему нельзя сделать, например, так: для плейера XMMS это папка /local/xmms, для KDE это папка /local/kde, GNOME - /local/gnome, Apache - /local/httpd, MySQL - /local/mysql и т.д. Почему все приложения в *nix должны быть раскиданы по всем каталогам, начиная от /etc и заканчивая /usr/local/share/etc? Какой "гений" сказал что так будет удобнее? Безусловно, для серверной ОС это будет удобно, что не нужно лазить по каталогам и искать настройки - все складировано в /etc, но линукс же безуспешно пытается вытеснить windows с рынка пользовательских систем! А этого никогда не будет, если сохраниться такая же "продуманная" логика построения системы!
При чем, части приложения точно так же раскиданы по всей системе. В чем такие огромные преимущества раскидывания файлов приложения по всей системе от централизованного, логичного хранения всех программ в одном каталоге?
Полный бред с совместимостью программ и библиотек. Абсолютное отрицание обратной совместимости приложений. Если приложение было написано с использование какой-либо библиотеки версии 1.1, то оно не сможет использовать библиотеку 1.2, потому что они абсолютно не совместимы. И приходится держать вместо одной библиотеки - целый зоопарк библиотек разных версий.
"Преимущества" распространения в исходных кодах? ГДЕ?! Когда пытаешься собрать какое-либо приложение оно требует (см. про обратную совместимость) старую или новую (тут понятно) версию тех или иных библиотек, которые нужно лезть и качать, а они так же в исходниках поставляются. Начинаешь собирать эти библиотеки - они также что-то требуют, вплоть до компилятора другой версии...
И начинается, вместо того, чтобы запустить setup.exe и провести установку - появляется куча непонятных проблем. RPM? Не выход, т.к. снова наблюдается несовместимость с теми библиотеками, что есть на компьютере и все замыкается в круг из которого порой не выйти в принципе. На Red Hat 7.2 тот же FireFox вообще не встал, потому что вежливо попросил накачать ему библиотек на пару сотен мегабайт.
Я согласен в одном - *nix это отличная система для серверов. Но для обычного пользователя - это страх. Из-за понятной только одним разработчикам логики построения системы. И *nix такими темпами никогда не вытеснит Windows.
Кто-то может возразить, что такое построение позволяет добиться максимальной производительности... Да, позволяет. На серверах. Где кроме демонов ничего не установлено. А теперь подсчитайте, как тормозит пользовательскую систему:
1. Несколько версий одной библиотеки (практически для каждой библиотеки), потому что иначе приложения не будут работать: 1.1, 1.2, 1.2.3, 2.0, 2.0.0.1 и т.д. Вместо одной библиотеки 2.0.0.1, которая совместима с предыдущими.
2. Множество исходных кодов также для каждой версии библиотеки, иначе нельзя будет собрать то или иное приложение - тут уже счет идет на сотни, если не тысячи файлов-"паразитов".
3. Огромное количество конфигурационных файлов для каждого приложения, которые заботливо складируются в один и тот же каталог /etc, при чем в корень, редко когда даже в подкаталоги.
И даже такие варианты как Suse, Mandrake, Red Hat и им подобные никак не могут избавиться от того, что все приложения раскидывают свои файлы "где придётся". Все дистрибутивы хвастаются своим "количеством поставляемого софта", где опять же счет идет на тысячи... Но ни одно приложение, тем не менее, нельзя сразу найти в системе - потому что оно может быть где угодно - постарались разработчики. И проблема в том, что нельзя точно сказать, что приложение поставилось именно в каталог /local/xmms, потому что оно, как паразит, разрослось по всем возможным каталогам... И так с каждым приложением. Даже поиск не помогает, потому что ему приходится перелопачивать тысячи файлов одних и тех же библиотек разных версий и т.п. А как часто при установки можно наблюдать подобную картину: Выберите устанавливаемые пакеты: gcc, gcc-1.1, gcc-1.1.1, gcc-2.0, gcc-2.0.1 (версии взяты от балды, для примера). Еще и при этом, самым правильным будет выбор всех пакетов, иначе результат будет плачевным. И после этого кто-то ругает windows за размер дистрибутива в половину DVD, когда дистрибутивы *nix уже давно не влезают на пару DVD, не говоря уже о занимаемом месте. Но самое плачевное - невозможность ориентации на компьютере с *nix.
Вот может мне кто-нибудь ответить, откуда такая бредовая анти-пользовательская концепция построения логики системы "одно-везде"? Даже Windows-приложения по сравнению с *nix-приложениями - "чистюли", которые все держат в одном каталоге и иногда что-то "забывают" при удалении в системных каталогах. В то время, когда *nix приложения "располагаются" повсеместно.
Какой баян? Я серьёзно спрашиваю? Есть ли у такого подхода к построению системы будущее в качестве настольной ОС? В том что это идеальная серверная ОС - сомнений нет. А пользовательская?
Вообще, в идеале, можно было бы собрать группу, которая бы на основе какой-либо ветки *nix собрала нормальную, удобную настольную ОС. А не эти монстры, что есть сейчас, переделанные из серверной ОС без изменения логики системы.
попробуй PC-BSD: http://ru.wikipedia.org/wiki/PC-BSD
Цитата:
PC-BSD имеет оригинальную систему пакетов PBI. Отличительной особенностью является то, что все PBI пакеты устанавливаются в отдельную директорию. Таким образом каждый пакет становиться относительно независимым, и происходит чёткое разделение между пакетами и основной системой. В PC-BSD имеется графическая программа установки и удаление пакетов. В то же время в PC-BSD есть и система портов (ports) и пакетов (packages) FreeBSD.
получается это-то, что тебе нужно.
в linux бинарные файлы находятся в директории bin/, исходные тексты в src/, библиотеки в lib/ т.е всё находится по стандартным путям и когда программист пишет програму он точно знает где ему искать файл библиотеки например.
А куда и какие файлы программы установились пользователь смотрит по логу установки.
В Windows же каждая игра считает своим долгом поставлять СВОЮ версию msvcr70.dll и 71.dll и иногда dxd3d_3*.dll потому что 1 их может не быть у пользователя и 2 они могут быть новее чем у пользователя, а игра не работает со старыми версиями.
Вопрос поставлен немного непочеловечьи!
Я узнаю себя несколькими летами раньше!:-)
Распологать любую программу в какой хочешь папке это глупо.
Сам забудешь где что находится!
А на счет простоты я соглавен - LINUX нельзя просто поставить и им пользоваться.
Надо знать как ОН работает. А это заставляет учиться !
Многие пакетные менеджеры могут "рассказать" где лежат файлы данного пакета например pacman в arch или в женте можно даже наоборот узнать какому пакеты принадлежит файл...
Даже Windows-приложения по сравнению с *nix-приложениями - "чистюли", которые все держат в одном каталоге и иногда что-то "забывают" при удалении в системных каталогах.
И ещё они содержат статические либы , притом разным приложениям зачастую нужны одни и те же и сколько приложений столько и копий одной и той же либы находится в "специально заведённой и аккуратно туда сложенные файлы программы", директории.
И насчёт чистоты это не совсем так, вынь так же пишет в реестр дофига инфы, что после удаления программы, становится мусором. И ещё создаёт директории и файлы в "Documents end Settings" которые зачастую не удаляются а остаются там валяться после анинсталяции программы.
попробуй PC-BSD: http://ru.wikipedia.org/wiki/PC-BSD
Цитата:
PC-BSD имеет оригинальную систему пакетов PBI. Отличительной особенностью является то, что все PBI пакеты устанавливаются в отдельную директорию. Таким образом каждый пакет становиться относительно независимым, и происходит чёткое разделение между пакетами и основной системой. В PC-BSD имеется графическая программа установки и удаление пакетов. В то же время в PC-BSD есть и система портов (ports) и пакетов (packages) FreeBSD.
в linux бинарные файлы находятся в директории bin/, исходные тексты в src/, библиотеки в lib/ т.е всё находится по стандартным путям и когда программист пишет програму он точно знает где ему искать файл библиотеки например.
А куда и какие файлы программы установились пользователь смотрит по логу установки.
В Windows же каждая игра считает своим долгом поставлять СВОЮ версию msvcr70.dll и 71.dll и иногда dxd3d_3*.dll потому что 1 их может не быть у пользователя и 2 они могут быть новее чем у пользователя, а игра не работает со старыми версиями.
В том то и проблема, что этих bin - несколько каталогов. И куда поставится конкретное приложение - сложно сказать. Не смотрев те же логи. А если подойти с пользовательской точки зрения? Чтобы установить приложение надо его установить, а потом еще разобраться как оно и куда установилось. Ну не бред? Или только мне так кажется?
Про игры согласен, есть такой прикол. Но что лучше: программа сама ставит библиотеки, какие ей нужны, пускай и дублируя. Или пользователю самому нужно найти библиотеки, при чем именно той версии, которую требует программа, потому что никакая другая не подходит? Это все равно что поставить windows без каталога system32 и каждый раз предлагать пользователю скачать ту или иную библиотеку с сайта microsoft. В этом-то и огромный плюс windows - если не хочешь разбираться с системой - не разбирайся, просто работай. А *nix, на мой взгляд подходит иначе - если хочешь работать, сначала пойми как работает система, а потом уже пытайся что-либо сделать.
2tarktus: вот и я задаюсь тем же вопросом, что мешает делать именно так? А не "вот мы это все раскидаем по всей системе, а если кому-то что-то понадобится - пускай читает мануалы". При чем, у всех программистов логика разная и все по разному раскидывают приложения. никакой структуры.
2(asper: согласись, в любом случае это все подразумевает каких-то специальных знаний о системе. при чем на каждой системе это будут разные пакетные менеджеры. пересаживаясь с одного дистрибутива, казалось бы той же ОС, сталкиваешься с тем, что нужно заново учить всё для этого дистрибутива.
Или может быть я что-то недопонимаю во всех прелестях *nix?
Именно
Вот скажите, пожалуйста, почему в *nix нет подобия Program Files? Куда по умолчанию ставятся все приложения? Приложения в *nix могут находиться где угодно и быть разбросаны по множеству каталогов: /usr, /usr/local, /usr/local/share, /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin и т.д. и т.п... Взяв любую линуксовую программу можно с уверенностью сказать, что только ее создатель знает, где находятся все ее части.
У обоих методов есть плюсы и минусы.
При чем, части приложения точно так же раскиданы по всей системе. В чем такие огромные преимущества раскидывания файлов приложения по всей системе от централизованного, логичного хранения всех программ в одном каталоге?
Преимущество в том, что каждый тип файла находиться в определенном месте ФС и программа, умеющая его
обрабатывать, легко его находит. Например, просмотр документации: man <команда> выведет документацию по
программе, совершенно, не интересуясь, что за команда и кто и куда ее ставил.
В винде же приходится каким-нибудь эксплорером лазать непонятно по каким каталогам в поисках мануала.
Минус же в том, что при ручном поиске нужного файла приходится достаточно точно знать его имя.
Полный бред с совместимостью программ и библиотек. Абсолютное отрицание обратной совместимости приложений. Если приложение было написано с использование какой-либо библиотеки версии 1.1, то оно не сможет использовать библиотеку 1.2, потому что они абсолютно не совместимы. И приходится держать вместо одной библиотеки - целый зоопарк библиотек разных версий.
Где бред, так это в винде, когда те же несколько несовместимых версий, но плюс к этому, многие программы
хранят их еще и у себя в папках (А которые не у себя, а в сисдир, организуют старый добрый длл-хелл).
И в итоге получаются десятки одних и тех же библиотек.
Даже Windows-приложения по сравнению с *nix-приложениями - "чистюли"
А про чистку реестра, конечно не слышал. В то же время, как rpm -e удаляет все под ноль.
"В мире есть случайность, есть предопределенность и есть то, что ты планируешь совершить."
Полный бред с совместимостью программ и библиотек. Абсолютное отрицание обратной совместимости приложений. Если приложение было написано с использование какой-либо библиотеки версии 1.1, то оно не сможет использовать библиотеку 1.2, потому что они абсолютно не совместимы. И приходится держать вместо одной библиотеки - целый зоопарк библиотек разных версий.
Интересно, почему у меня стоит .NET 2.0 и .NET 1.1?
Всё очень просто... программам, написанным для .NET 1.1, .NET 2.0 не подходит.
2Георгий: простой пример. ставлю вчера под freebsd midnight commander. вроде собрался без проблем, make install тоже прошел красиво... пишу: mc... Command not found. Что за фигня? Начинаю метаться по всей системе, по всем известным путям, нахожу каталог этого mc (/usr/local/share/mc) - там пустота... какие-то файлы локализации и т.п... В конце концов нашел таки его в /usr/local/bin... В конечном итоге оказалось, что чтобы он запускался из любого места, а не только по полному адресу... нужно было выйти и снова войти. хотя в переменной path был прописан путь до /usr/local/bin, но он никак не находился.
Возьмум windows, ставим Far, забываем установить ярлык на рабочий стол. Лезем в C:\Program Files\FAR и, о чудо, видим там far.exe! Создаем ярлык и тащимся от осознания собственной значимости. А не начинаем лезть в C:\Windows\, C:\Windows\System32, C:\Documents and Settings или еще куда, в поисках бинарника.
В том то и проблема, что этих bin - несколько каталогов. И куда поставится конкретное приложение - сложно сказать. Не смотрев те же логи. А если подойти с пользовательской точки зрения? Чтобы установить приложение надо его установить, а потом еще разобраться как оно и куда установилось. Ну не бред? Или только мне так кажется?
После установки программы я выбираю в меню эту новую программу или в консоли набираю её имя и она запусается?
Про игры согласен, есть такой прикол. Но что лучше: программа сама ставит библиотеки, какие ей нужны, пускай и дублируя. Или пользователю самому нужно найти библиотеки, при чем именно той версии, которую требует программа, потому что никакая другая не подходит?
2Георгий: простой пример. ставлю вчера под freebsd midnight commander. вроде собрался без проблем, make install тоже прошел красиво... пишу: mc... Command not found. Что за фигня?
sudo apt-get install mc
./mc
это сложно?
сборка wine из исходных текстов.
./configure
make depend
make make install
./winecfg
это тоже очень сложно?
Где-то у нас была прикреплена в юморе папочка для подобных опусов. Туда бы эти "перлы"
Читаю вслух с выражением маны - $50/ч + стоимость звонка. Настраиваю сервисы за Вас - $100/ч + стоимость выезда и проживания. И восемь строк матом...(бесплатно)