[отговорите-тред]Debian

Ставь дебиан

//Тред не читал

ставь дебиан

либо ставь дебиан, либо ставь дебиан

Рпм дистрибутивы принципиально выбросил из выборного листа?

>Т.к. на Ubuntu не охота

Правильно, главное не ставь Убунту. Это самое важное.

Забей на все и поставь windows 7 Ultimate.

Рпм дистрибутивы принципиально выбросил из выборного листа?

Когда-то почти счастливо жил на OpenSUSE 10.3, но потом просто ужаснулся 11.0 x86_64 и ушел на Arch. Пробовал какую-то Mandriv'у(2007 вроде), но некоторая перегруженность и фееричные зависимости пакетов отпугнули. Fedora 7 тоже была со своими приколами, от чего rpm-based дистрибутивы мне как-то не приглянулись :)

Дженту.

Сквизи подох(не удаётся восстановить профиль юзера) после заполнения раздела под завязку. ФС - ext4.

Забей на все и поставь windows 7 Ultimate.

своих кровных жалко, интернетов нет, а на работе iso'шки хоть и лежат открыто, но боюсь после установки оно залезет в интернеты, и настучит MS, что я использую нелицензионную версию, после чего начальство меня отправит на вольные хлеба :}

наивный

наивный

я же хз, как и все остальные, какое бинарное говно могли всунуть в версии, распространяемые по MSDN подписке, вдруг там действительно есть шпионская фиготень? :)

Дженту.

она же слила по производительности Ubuntu :}

Debian скатился в сраное говно. Если и ставить, то только unstable: testing в этом сезоне глюкодром, stable - всегда был говном мамонта.

у меня Debian Etch. штук 5 программ я изредка пересобираю сам. на Lenny так же, но там кое что можно обновлять и не пересобырая а просто добавив репо разработчиков (qutim напрмиер)

>Debian скатился в сраное говно. Если и ставить, то только unstable: testing в этом сезоне глюкодром, stable - всегда был говном мамонта.

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

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

В общем, пробуй сквизи.

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

Такие и C:\WINDOWS поковырять будут очень довольны.

> В сквизе наутилус багнутый,

В testing пакеты обновляет автомат (до заморозки) - и тут уже как получится,
а nautilus в testing давно должен быть уже 2.28.1 из Sid - ан нет, снова срез вчера testing вышел c глючным nautilus 2.26.3.

И что прикольно - Иранский Parsix на основе Debian вышел строго по заветам мантейнеров Gnome Debian : Gnome 2.26.3 + nautilus 2.28:))

>> Дженту.

>она же слила по производительности Ubuntu :}

Кто тесты проводил? Пусть руки из жопы вынут: мои предвзятые тесты всегда показывают превосходство Дженты!

>уверен что такие пользователи дебиану не нужны. вам лучше проследовать на арч
Не надо мне на арч, я на Lenny сижу с тестинга и по сей день, а до этого etch стоял - тоже с тестинга и до полугода после стабилизации.
Просто ТС же с арча уходит, а с него переход на стабильный Debian - сильный шок :)

>Пусть руки из жопы вынут: ...

это особо ценное замечание в свете:
> Сквизи подох(не удаётся восстановить профиль юзера) после заполнения раздела под завязку. ФС - ext4.

>>Пусть руки из жопы вынут: ... >это особо ценное замечание в свете:

>> Сквизи подох(не удаётся восстановить профиль юзера) после заполнения раздела под завязку. ФС - ext4.

Именно. Им нужно качественнее собирать пакеты.

Сиди на своей семёрки.

угу , что бы у тебя ext4 не забивалась пакетами ...
Ох эти гентушные потные басенкии ...

кстати, как-то провернул тоже такой финт : утопил хомяк копированием с другого винта через mc - перегруз и капут . Пока не появилось живое место в /home - ни гугу.:)))
А что завалил то, Gnome ?

>угу , что бы у тебя ext4 не забивалась пакетами ... >Ох эти гентушные потные басенкии ...

На деле я сказал поставить LyX, и включил фильм. На середине фильма винт пошуршел, и плазма скопытилась(место закончилось). Снос профиля(оставил сперва только ~/.opera и содержимое /etc/skel) не помог, пересоздание пользователя с тем же именем и uid'ом не помогло.

А В Дженте при установке того же ООо система установки сама проверяет доступное место! :) Ну, я просто не ожидал что пары гигов не хватит.

Гном таки самая удобная среда, что я знаю. Жутко нравится. Но там нет Амарока, и виджеты крупноваты в некоторых приложениях. Плюс, мне нужно определение кодировок в GEdit'е. Потому я ушёл на уже стабилизировавшиеся(кстати, в Дебьяне их оченьт медленно обновляют) кеды)

> пересоздание пользователя с тем же именем и uid'ом не помогло.

Создание нового юзера регенирерует дефолтные настройки Gnome - это уже как стандартный прием, по кедам не скажу.

>Плюс, мне нужно определение кодировок в GEdit'е.
geany
>Но там нет Амарока,

Ой бида какая ... Ж))

>и виджеты крупноваты в некоторых приложениях.
Вообще, это настраиваемо.

> в Дебьяне их оченьт медленно обновляют) кеды)
если посмотреть на входящие пакеты
http://incoming.debian.org/
то постоянно дрючать там кеды , + много архитектур и много всего вообще.

>Создание нового юзера регенирерует дефолтные настройки Gnome - это уже как стандартный прием, по кедам не скажу.

Дык, тоже. Но kdm(или kinit, не знаю где именно) в _Дебьяне_ на этом месте вешался. Т.е. в других дистрах это сотни раз проходило без особых проблем.

>>Но там нет Амарока, >Ой бида какая ... Ж))

Конечно! Ты не поверишь: мой КПД прослушивания музыки вырос на 5-6%!

>>и виджеты крупноваты в некоторых приложениях.

>Вообще, это настраиваемо.

Таки где кнопочка?

Батенька, у меня в Дженте 4.3.3 появились раньше, чем 4.3.2 в Сквизи. Ну вот как так можно? Только не говори что собирать долго. Хоть бы в экспериментале поактивнее шевелились. Ну и да, несколько веток на Дебьяне держать ради новых версий неудобно.

Ну еще раз ...
Сквизи - это testing , и обновляет пакеты там автомат под кодовым именем мантейнера (Britney).
Если так неймется - юзайте Sid.

> Таки где кнопочка?

как для начала

$gconftool-2 --type string --set /desktop/gnome/interface/toolbar_style "icons"

$gconftool-2 --type int --set /desktop/gnome/interface/toolbar_icon_size 24

Таки я с нвидивскими дровами под Сквизи возился, а в Сиде x-server 1.7, нвидия с ним, емнип, и не должна работать. Собственно, я не хочу чтобы обновлённая система сломалась - я хочу стабильные кеды в стабильной системе)

>$gconftool-2 --type string --set /desktop/gnome/interface/toolbar_style "icons"

Мне для определённых приложений нужно. Вот бы Гном умел ресайз кнопочек прямо во время работы... :)

Толстим, не?

вообще ,xorg sid == xorg testing:
http://packages.debian.org/sid/xserver-xorg xserver-xorg (1:7.4+4)
в experimental:
xserver-xorg (1:7.5~1)
что за проблемы ?

Таки где пакеты под .30 ядро? Пришлось руками собирать.

> Таки где пакеты под .30 ядро? Пришлось руками собирать.

Не понял, и это спрашивает гентушник ?

#m-a prepare
#m-a a-i nvidia

>Не понял, и это спрашивает гентушник ?

Да хоть LFS'ник.

>#m-a prepare >#m-a a-i nvidia

Не похоже на aptitude install nvidia-glx.

это сокращенна форма для вызова утилиты сборки ядерных модулей module-assistant
apt-get install module-assistant

он сам все доустанавливает для сборки пакета модуля,собирает пакет и устанавливает. Также,module-assistant устанавливает (как правило) необходимые файлы для работы пакета ( и nvidia-glx тоже).

fixed: сокращенна -> сокращенная

Какой шутник) Я так и emerge -q nvidia-drivers могу запустить. Как уже написал, проблема решена. Только телодвижений слишком много для унифицированного и автоматизированного Дебьяна. Причём для стандартного ядра(а о тестерах позаботиться?).

>Пока не появилось живое место в /home - ни гугу.:)))

Уточню значение слова "под завязку". Это то что наутилус говорит? Или совсем под завязку? (Вопрос про зарезервированное место).

И еще вопрос, что значит "живое место".

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

Сразу после установки системы запрещать обновление всех установленных пакетов (через секцию IgnorePkg в /etc/pacman.conf). После этого разрешать обновление тех пакетов, с которыми есть проблемы - до тех пор, пока проблема не будет решена (после решения снова заносить пакет в черный список). Обновлять пакеты только тогда, когда в этом есть необходимость (например, ты увидел в ченджлоге, что новое ядро лучше работает с какой-то используемой тобой железкой, или же что в программе появилась новая фича) или на багфикс-релиз (хотя по большому счету, если ты не натыкаешься на баги - зачем тебе багфикс-апдейт?) или когда это стоит в зависимостях для обновления другой программы (обновить которую опять-таки по какой-то причине нужно).

У каждого пакета помимо апстримовой версии есть и внутренняя версия от мейнтейнеров. Потому, как только выходит мажорное обновление к программе (и ты знаешь, что есть причины, по которым это обновление тебе нужно), ты не ставишь пакет как только он покинет /testing, а ждешь, пока внутренняя версия пакета несколько раз сменится уже после его перехода в текущий раздел. Еще лучше - если ты дождешься выхода нескольких багфикс-релизов в апстриме, а потом - еще и нескольких смен внутренней версии (грубо говоря, вышел GNOME 2.28.0, ждешь GNOME 2.28.1 как минимум - а потом ждешь, чтобы его еще несколько раз пересобрали мейнтейнеры Арча). И цикл повторяется. То есть по сути, это и есть суть работы мейнтейнера - только ее выполняешь ты) И это то, что в Debian сделали бы за тебя. Именно поэтому выше народ писал, что в Debian testing не попала новая версия nautilus. А в Арче ты на собственном опыте понял, почему она не должна была попасть)

Если же тупо обновлять пакеты как только они попадают в текущий раздел Арча, то ты наткнешься на главный провал организации этого дистрибутива. Делается следующее: как только выходит мажорный релиз программы, он попадает в /testing. Там его пробуют, на него пишут багрепорты, его пересобирают, ждут багрепортов. И так, пока багрепортов (по крайней мере, критичных) не станет. После этого его отправляют в текущий раздел дистрибутива. Почему это не работает? Так много ли идиотов будет сидеть на тестовом разделе Арча? Потому может и не быть багрепортов, пока пакет в тестовом разделе - не потому, что нет проблем, а потому, что некому их найти (или просто не успели). Пакет попадает в текущий раздел, там он предстает перед большинством пользователей - но уже поздно.

В принципе, эти проблемы не светят тем, кто использует максимально простые программы с изначально высоким качеством кода (например, dwm какой-нибудь) - тут мейнтейнерам и делать-то почти ничего не надо. Но любая сложная программа автоматически не может иметь такой же уровень качества - GNOME, XFCE, KDE, OpenOffice. И вот они автоматически влетают. Туда же попадает и X.org (который в принципе является кошмаром мейнтейнера, см. соответствующие доклады Тео Де Радта). Какой-нибудь vim (или на худой конец, ядро) входят в /core, тут мейнтейнеры в принципе максимально осторожны.

Таким образом, вот тебе и выбор: либо использовать мое решение по полуручному обновлению (и выполнять работу мейнтейнера самому), либо переходить на легкие программы (отказаться от GNOME в пользу чего-то проще) - и все равно выполнять ручное обновление X.org и тому подобного. Это все если тебе критичны особенности Арча (вроде конфигурирования через /etc/rc.conf, ABS, AUR, netcfg). Либо же переходить на Debian Testing (или Stable + Backports, где подход еще ближе к тому, что я описал), где все проблемы по управлению версиями пакетов решат за тебя. Считай, что если философия Slackware - ручное управление зависимостями дает гибкость, то философия Arch - ручное управление обновлениями дает гибкость.

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

Да, и еще: если все пользователи Арча будут пользоваться подобным подходом (не обновлюсь, пока другие не набьют шишек), то дистрибутив просто умрет)

Такие дела. Еще раз пардон за очень много буков (сам не ожидал). Ваш Кэп =)

>и виджеты крупноваты в некоторых приложениях.

Отключи подписи под значками, делов то...

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

> Какой шутник) Я так и emerge -q nvidia-drivers могу запустить.

Ну и вперед ... зачем спрашивать тогда ?

Вообще,это стандартная метода сборки ядерных модулей в Debian и используется в DKMS.

.30 ядро уже слито, есть уже 31 - хотя не очень рвутся с ним тоже.

Похоже таки ждут как-то 32 ведро ,и не очень морочат голову дурными обновлениями ...

>Только телодвижений слишком много для унифицированного и автоматизированного Дебьяна.

ню ню, ставь бубунту ... там оберегают хрупкие мозги от напрягов.

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

В Дженте у меня есть возможность обновить пару нужных пакетов, сохраняя нужные версии у других. И нравится возможность не использовать NM и PA. Хотя и приходится иногда ковыряться руками.

>Ну и вперед ... зачем спрашивать тогда ?

А я ничего не спрашивал, это всё твоя фантазия)

>ню ню, ставь бубунту ... там оберегают хрупкие мозги от напрягов.

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

>.30 ядро уже слито, есть уже 31 - хотя не очень рвутся с ним тоже.

О том и речь: пока они очередной месяц подряд меняют очередное ядро, пользователям приходится делать лишние телодвижения. Зачем называть выпуск "тестируемым", если они ограничивают возможности для оного тестирования?

И это, потоньше, а то скучно становится.

Я не считаю, что в этом подходе есть смысл в случае Арча (если нет крайней необходимости в том, что в Арче уникального), но это единственный выход в данной ситуации. И сама дотошность дает понять, что разработчики неправильно организовали процесс. По всей видимости, путь пакета от ~arch в arch в Gentoo происходит удачнее, чем путь из /testing в /extra в Арче. Об этом я и говорю)

>О том и речь: пока они очередной месяц подряд меняют очередное ядро, пользователям приходится делать лишние телодвижения. Зачем называть выпуск "тестируемым", если они ограничивают возможности для оного тестирования?

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

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

также если сидеть под стейблом, то через определенное время становится скучно ибо всё работает, не падает и отконфигурено как надо

блобы есть в отдельных подрепах