Что Вам не нравится в Линукс? Трудности, неудобства.

Не нравится тока то, что мой модем Huawei E1550 иногда после подключения к и-нету (по крайней мере уведомляет о подключении) не работает.
А так пока что меня всё устраивает, думаю через какое то время нормально освоюсь =))

цитата nnm.ru

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

Vartonst написал:

а пока не созреешь — дрочи, дрочи, и дрочи...

...используй Windows.=))))

Что-бы там не говорили про "заводится с полпинка" и "искаропки". А проблемы с дровами были, есть, и не скоро исчезнут. Причина в том, что производители железок ориентированы на большинство пользователей, коими являются пользователи Виндоус. Я вот до сих пор не заставил как следует работать свою nvidia210, когда nouveau допилят до человеческого состояния, тогда порадуюсь.
Еще не нравится то, что каждый пишет свою программу с какими-то библиотеками, которых у меня может не быть. Мне вот нравится таймер заваривания чая в КДЕ kteatime, но не тянуть же мне ради него qt, kdelibs и все такое. Опять-таки, если сравнивать с Виндоус, то там один АПИ, если не брать в расчет какие-то сторонние библиотеки, и программы распространяются с учетом того, что они могут быть установлены на "голую" систему без всяких зависимостей (хотя есть и исключения). Но это правда можно посчитать и недостатком. Ведь мне не все из того , что идет в винде "искаропки" реально нужно. Так что тут даже и не могу однозначно сказать, так ли мне это не нравится.

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

fiZik написал:

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

Для пользователей это не плюс ни единого разу: без костыля в лице пакетного менеджера поставить софт крайне проблематично. А если пакетный менеджер начинает сбоить, то тут вообще караул. Выигрыш в дисковом пространстве все равно невелик, особенно в системах, где есть свой API (см. ниже) и где программам нужно за собой тащить лишь небольшой набор специфических библиотек.
Разработчикам тоже пользы никакой, одни проблемы с подготовкой дистрибутивов своего софта: в разных системах имеются разные версии библиотек, рассованы они по разным пакетам, так что приходится долго разбираться, что и от чего должно зависеть.
Лично я с т.з. разработки предпочитаю, когда ОС предоставляет некий единый API, реализующий большую часть нужных мне возможностей, который никуда таскать не надо, ибо он и так в составе ОС имеется. В Win и Mac такой есть, в Linux к этому все никак не придут (дальше LSB дело не пошло, да и эта инициатива, похоже, подзагнулась).

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

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

Loky написал:

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

В линухе своего API по сути нет, если не считать каких-то функций уровня ядра. Все остальное реализуется третьесторонними библиотеками (Gtk, Qt и иже с ними), состав и версии которых варьируются от системы к системе.

Loky написал:

и я так полагаю, что Вы как разработчик никогда не сталкивались с термином "dll hell"

Сталкивался, и не раз. Скажу лишь, что в линухе, имхо, эта проблема стоит острее, чем в других системах, ибо "dll hell" (или "so hell" :)) здесь возведен в статус правила: все бинарники складываем в /bin, библиотечки - в /lib, пакеты жестко друг на друга завязаны, т.е. идеальные условия для формирования этого hell'а. Пакетный менеджер, как может, частично исправляет эту ситуацию, но все равно как-то некруто.
В других же системах, в свою очередь, стараются приложения друг от друга изолировать, чтобы каждое жило себе тихо со своими библиотечками и никому не мешалось. Единственной общей частью оказывается системный API, в рамках которого никакого hell'а не образуется. Понятно, что реальная ситуация не в полной мере соответствует этому идеалу, но хотя бы к нему стремится.

Iskan Der,
В Линуксе тоже многие стараются так делать. У меня, например, все программы, которые я использую для работы и которые я скачивал дополнительно, спокойненько живут себе в директории /home/<user_name>/Tools и при этом самодостаточны.

so весьма хорошо между собой изолированы. то что они лежат в кучу совершенно не мешает. жёсткая привязка к библиотекам почти во всех случаях указывает минимальную совместимую версию, а так чтоб до 5-го знака - никогда.
Ни в коем разе не хочу Вас обидеть, но я бы хотел заметить, что у Вас почему-то весьма обывательские представления о внутреннем строении ОС.
Впрочем, я выхожу из дискуссии, вопрос перешёл почти в политику.

Loky написал:

so весьма хорошо между собой изолированы

Понятно, что две библиотечки в один кластер на винте писаться не будут. Я говорил про ситуацию, когда в системе нужно иметь две программы, каждая из которых использует какую-нибудь blablabla.so, только разных версий. Очевидно, что две версии этой blablabla.so в /lib не уложатся. Вот вам и искомый "dll/so hell" :)

Loky написал:

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

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

Loky написал:

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

Ну я как бы всего лишь пользователь и разработчик-прикладист, в кишки ОС не лазаю, говорю лишь о том, что сам вижу :)

Iskan Der написал:

Очевидно, что две версии этой blablabla.so в /lib не уложатся. Вот вам и искомый "dll/so hell" smile

4.2 же. Уложатся.
Вот пример:

flaming@gentoo ~ $ ls /usr/lib/libfusion* -l
lrwxrwxrwx 1 root root    18 Дек 12 19:24 /usr/lib/libfusion-1.2.so.0 -> libfusion-1.4.so.0
lrwxrwxrwx 1 root root    22 Фев 21 23:15 /usr/lib/libfusion-1.4.so.0 -> libfusion-1.4.so.0.2.0
-rwxr-xr-x 1 root root 34208 Фев 21 23:14 /usr/lib/libfusion-1.4.so.0.2.0
-rw-r--r-- 1 root root 46240 Фев 21 23:14 /usr/lib/libfusion.a
-rw-r--r-- 1 root root   876 Фев 21 23:14 /usr/lib/libfusion.la
lrwxrwxrwx 1 root root    22 Фев 21 23:15 /usr/lib/libfusion.so -> libfusion-1.4.so.0.2.0

Две версии. Новая 1.4, и старая 1.2 оставлена для совместимости. Ещё, помню, раньше было две версии libjpeg, потом одна удалилась за ненадобностью...

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

Iskan Der,

Понятно, что две библиотечки в один кластер на винте писаться не будут. Я говорил про ситуацию, когда в системе нужно иметь две программы, каждая из которых использует какую-нибудь blablabla.so, только разных версий. Очевидно, что две версии этой blablabla.so в /lib не уложатся. Вот вам и искомый "dll/so hell"

Вот тут я с Вами согласен. Сделаем даунгрейд половина прог могут отказатся работать.

Flaming написал:

Уложатся.

Ммм, похоже, я чего-то не понимаю. Есть две софтины, каждая из которых пользует некую /lib/blablabla.so, однако каждой из них нужна своя версия этой либы. И как же сделать, чтобы при обращении к этой /lib/blablabla.so каждой софтине подсовывалась нужная версия?

если софтине нужна какая то конкретная версия либы - она обращается к /lib/blablabla.so.1.2.3
или, что кстати бывает чаще - /opt/название_софтины/lib/blablabla.so

если использовать репозитарии то таких проблем не может быть...

komcumir написал:

если использовать репозитарии то таких проблем не может быть...

Могут, если одновременно используется несколько независимых репозиториев.

Iskan Der написал:

Ммм, похоже, я чего-то не понимаю. Есть две софтины, каждая из которых пользует некую /lib/blablabla.so, однако каждой из них нужна своя версия этой либы. И как же сделать, чтобы при обращении к этой /lib/blablabla.so каждой софтине подсовывалась нужная версия?

Я же написал. Закиньте в каталог, откуда будете запускать эту "древнюю" софтину. Если не подхватит сама(хотя должна по-моему), добавьте в переменную LD_LIBRARY_PATH нужный каталог. В neverwinter nights, кстати, так и сделано, и наверняка не только там.

davinel написал:

если софтине нужна какая то конкретная версия либы - она обращается к /lib/blablabla.so.1.2.3
или, что кстати бывает чаще - /opt/название_софтины/lib/blablabla.so

Согласен. Если программа обращается только к

Iskan Der написал:

/lib/blablabla.so

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

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

Сам столкнулся с тем, что maple-8 не запускается (даже установщик). Так как времени нет, решать не стал, но уверен, что можно попробовать установить в старый дистрибутив линукса (в ту же виртуалку), а потом оттуда скопировать вместе с нужными либами.
Если, конечно, он к ведру не привязан (не знаю, как такое возможно).

Iskan Der написал:

Могут, если одновременно используется несколько независимых репозиториев.

Flaming написал:

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

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