Debian Etch 4.0 Released!

Вернее http://my.opera.com/desktopteam/blog/2007/04/06/hotfix

>_Внимание_ релизы дебиана приводят к обильным снегопадам!

А в Новосибирске наоборот, +12 :)

Кстати, насчет нового софта и Ubuntu.

64-битная убунта (которую юзал) тот еще глюкодром. Плюс косяки с установкой 32-битных приложений, некоторые из которых вообще ставиться не хотят, хотя вроде в репозитарии есть (например wine был нужен для дела). Скорее всего конечно у меня руки кривые, и можно воткнуть, на крайний случай из исходников собрать, но некоторые вещи просто добивали... например как после очередного обновления в том же гноме стала панель отваливаться, как firefox течет (и до сих пор не поправили), и еще куча раздражающих мелочей.

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

Мораль: Debian для тех, кому нужно работать. Ubuntu для тех, у кого времени вагон, и нет другого занятия, кроме бесконечного обновления и настройки внешнего вида рабочего стола. Конечно прикольно похвастаться всякими спецэффектами, которые в Feisty пытаются сделать "искароппки", но не для работы оно (использование дома -- тоже какая-никакая работа).

Все вышесказанное это конечно IMHO.

Best regards, Zumz (пароль забыл...)

> 64-битная убунта (которую юзал) тот еще глюкодром

Имхо, 64-х битную можно использовать исключительно федору (на декстопе, на сервере, где i386 не нужно или нужно совсем чуточку, вариантов полно). multilib там, вообще говоря, тоже не идеальный (исключительно из-за бага в rpm, точнее из-за искуственного созданного костыля, без которого проблемы у машин с небольшим количеством памяти), но проявляется это только во время сноса i386-версии пакета с оставлением x86_64. В остальном же ситуация на голову выше убунты - и wine, и любой другой i386-софт, и разработка под i386 на x86_64 машине не представляют никакой проблемы, все работает как часы. Конечно, за это пришлось платить - тем же отказом от apt-get и окончательным движением в сторону yum, т.к. apt-get так и не сумели допинать на предмет качественного multilib'а..

Переходя на x86_64, я долго вертел убунту, плевался-плевался от этих хаков для поддержки i386-софта и в итоге понял, что федора значительно беспроблемнее в этом плане. Как бы мне не нравились некоторые фичи убунты, но к 64-х битам она пока хорошо не готова. Если только не хочется возиться с ней вместо того, чтобы работать - но такие люди выбирают совсем другие дистрибутивы..

У меня тоже Федора 6_64, согласен что все работает но сравнить не с чем поэтому поставлю Etch AMD64. Посмотрю можно ли с ним работать. Может кто то уже поставил, как все работает?

народ, у меня вопрос появился. сайт distrowatch.com сообщает, что в дистрибутиве содержатся драйверы ATI и NVIDIA 8.28.8 и 1.0-8776 соответственно. Только они же не свободные и не опенсорс. проясните ситуацию плиз.

>Обновился, блин... Господа, а как теперь Оперу запустить, кто подскажет?

Поставить отсюда (хоть и не очень кошерно в плане идеологии, зато работает отлично): http://snapshot.opera.com/unix/Weekly-636/intel-linux/

Они в non-free секции.

>> 64-битная убунта (которую юзал) тот еще глюкодром
>Имхо, 64-х битную можно использовать исключительно федору (на декстопе, на сервере, где i386 не нужно или нужно совсем чуточку, вариантов полно). multilib там, вообще говоря, тоже не идеальный (исключительно из-за бага в rpm, точнее из-за искуственного созданного костыля, без которого проблемы у машин с небольшим количеством памяти), но проявляется это только во время сноса i386-версии пакета с оставлением x86_64. В остальном же ситуация на голову выше убунты - и wine, и любой другой i386-софт, и разработка под i386 на x86_64 машине не представляют никакой проблемы, все работает как часы. Конечно, за это пришлось платить - тем же отказом от apt-get и окончательным движением в сторону yum, т.к. apt-get так и не сумели допинать на предмет качественного multilib'а..

>Переходя на x86_64, я долго вертел убунту, плевался-плевался от этих хаков для поддержки i386-софта и в итоге понял, что федора значительно беспроблемнее в этом плане. Как бы мне не нравились некоторые фичи убунты, но к 64-х битам она пока хорошо не готова. Если только не хочется возиться с ней вместо того, чтобы работать - но такие люди выбирают совсем другие дистрибутивы..

уже больше чем пол года живет etch adm64 на серваках, полет нормальный, что я не так делаю?

> народ, у меня вопрос появился. сайт distrowatch.com сообщает, что в дистрибутиве содержатся драйверы ATI и NVIDIA 8.28.8 и 1.0-8776 соответственно. Только они же не свободные и не опенсорс. проясните ситуацию плиз.

Так эти драйвера и находятся в non-free.

>У меня тоже Федора 6_64, согласен что все работает но сравнить не с чем поэтому поставлю Etch AMD64. Посмотрю можно ли с ним работать. Может кто то уже поставил, как все работает?

Я ставил, и уже пару лет, как ставлю. В принципе все работает. Но могу сказать одно - дома, в офисе, на обычных серверах - это не нужно совершенно. Абсолютно ничего (кроме всяких недоразумений) это не дает. Все процессоры у меня давно х64, но на основной машине я держу версии i686, и горя не знаю. Смысл в 64битах есть возможно только для каких-то сверх-задач - SETI, моделирование ядерных взрывов, генетика и т.д. Если вы этим не занимаетесь - то абсолютно бесполезная затея, а местами и проблемная, и бывает даже более тормознутая, как это не парадоксально.

Никакой стабильностью в Дебиане, к сожалению, нынче и не пахнет. Простой пример: Сарж, который релизили несколько лет, вышел с ядром 2.6.8, которому в ту пору уже больше года было. Официальное дебиановское ядро 2.6.8 содержало баг в коде ext3 из-за которого ядро паниковало на Атлонах при нагрузке на ФС чуть выше средней. Баг этот был известен и пофиксен уже больше года перед релизом Саржа. Вместо этого девелоперы ядра занимались, в основном, кастрацией "несвободного" кода в ядре.

К сожалению, в Дебиане так делается все.

>уже больше чем пол года живет etch adm64 на серваках, полет нормальный, что я не так делаю?

Если вы не заметили, то в сообщение на которое вы ответили, упоминается убунта и федора, а про дебиан нет ни слова... ;)

> и пофиксен

в смысле пофиксен в ядре, но не в Дебиане

>К сожалению, в Дебиане так делается все.

Ответить за козла - слабо?

> уже больше чем пол года живет etch adm64 на серваках, полет нормальный, что я не так делаю?

Как насчет wine там? А также IBM DB2 UDB? Sun JDK? Что за сервак? Интересуют сторонние приложения.

Вот сейчас и думаю, какой Debian качнуть, 32-х битный, или 64-х... Кто в курсе насчет граблей 64-х битного Etch?

Best regards, Zumz

Назовите тогда дистрибутив, по сравнению с которым "Никакой стабильностью в Дебиане, к сожалению, нынче и не пахнет".

Minix 3 ;)

> уже больше чем пол года живет etch adm64 на серваках, полет нормальный, что я не так делаю?

Невнимательно читаешь. Я говорил про проблемы качественного multilib-окружения в ubuntu (и, полагаю, debian - сомневаюсь, что они сейчас внезапно решили это проблему, слишком долго не предлагали никакого решения раньше). Это практически чисто десктопная проблема. На серверах, где нередко 100% софта x86_64 и multilib не нужен вообще (или достаточно multilib-варианта glibc), она отсутствует. К дебиану на сервере никаких претензий..

Поэтому дебиан в изначальной мессаге не упоминал вообще - имхо, дебиану на десктопе (обычно) делать нечего.

Супер!

>дебиану на десктопе (обычно) делать нечего

Что делаю не так я и мои родители? У меня и у них дебиан дома на компьютере.

>уже больше чем пол года живет etch adm64 на серваках, полет нормальный, что я не так делаю?

Как я понимаю, в Дебиан отказались от multilib. Т.е., если дистр amd64, то всё 32 битное идёт лесом. Поэтому там проблем и нету. (Если я не прав поправте :) ). И это абсолютно правильное решение (имно).

> Поэтому дебиан в изначальной мессаге не упоминал вообще - имхо, дебиану на десктопе (обычно) делать нечего.

Слишком обобщенная фраза. А давайте еще SLED и RHEL Desktop с десктопа сгоним :) У каждого дистра своя ниша.

Я бы уточнил, debian не для массового десктопа, для этого есть другие дистры.

>Никакой стабильностью в Дебиане, к сожалению, нынче и не пахнет. Простой пример: Сарж, который релизили несколько лет, вышел с ядром 2.6.8, которому в ту пору уже больше года было. Официальное дебиановское ядро 2.6.8 содержало баг в коде ext3 из-за которого ядро паниковало на Атлонах при нагрузке на ФС чуть выше средней. Баг этот был известен и пофиксен уже больше года перед релизом Саржа. Вместо этого девелоперы ядра занимались, в основном, кастрацией "несвободного" кода в ядре.

Ну, не нужно таких громких заявлений делать и так обобщать. Во-первых вами описан единичный частный случай, причем не первой свежести. Во-вторых баг этот касался далеко не всех - ширпотребный процессор, и не самая выдающаяся ФС, что еще от них ожидать? И слава богу, что существуют такие вот "Хранители чистоты свободного кода" как девелоперы Debian, и люди вроде RMS - которые не дают окончательно загадить, и в последствии извести саму идею OpenSource. И такие вот зачистки на самом деле иногда являются гораздо более важным занятием с точки зрения сохранения вида, чем исправление мелких багов (которые к слову кому надо сильно, может и сам исправить).

>Вот сейчас и думаю, какой Debian качнуть, 32-х битный, или 64-х... Кто в курсе насчет граблей 64-х битного Etch?

Позвольте полюбопытствовать - зачем вам 64 бита?

Например, Генту. Багов там - на порядок меньше. Да, да - это так.

> Например, Генту. Багов там - на порядок меньше. Да, да - это так.

Это шутка такая, да?

> И это абсолютно правильное решение (имно).

Это не правильное, а "комфортное для авторов дистрибутива" решение.. А пользовалям - опять 32-х битный chroot?! Да здравствуют костыли!!

PS и не надо говорить, что вы готовы найти 64-х битную замену для десятка используемых мной i386-only приложений. Ну для половины может и получится найти, но штук пять все равно останутся. Т.е. дебиан фактически предлагает использовать i386-версию на amd64 (это в 2007 году-то! когда даже последняя федора и то multilib осилила, а multilib'нутый RHEL3 напомнить, когда вышел?) либо.. просто не использовать дебиан.

>Поэтому дебиан в изначальной мессаге не упоминал вообще - имхо, дебиану на десктопе (обычно) делать нечего.

Ну скажите наконец - чего нет для десктопа (и всего остального) в Debian, и что есть для этого в других дистрибутивах? Чем Debian desktop отличается например от SuSE десктопа, или Федоры?

Не надо сравнивать RMS'а c дебианщиками. Одна из форм активности Дебиана в последние годы - это как раз война с GNU (по поводу GFDL). И кстати, основным release goal'ом для Etch, было заявлено удаление "несвободной документации" под GFDL. Как там, сделали, что обещали? Или 2х лет на это все же не хватило ;)

Это абсолютно серьезно.

Реальный пример: чтобы не приходилось испытывать геморроидальные неудобства при превышении процессом объема памяти 4 гига (без падения производительности). Применимо к базам IBM DB2. Конечно, оно умеет поднимать второй экземпляр сервера баз данных, но это лишний расход памяти и процессорного времени, да и к тому же создает дополнительные проблемы иногда. В серваке ведь может стоять и 8 и 16 Гиг.

Best regards, Zumz

> Например, Генту. Багов там - на порядок меньше. Да, да - это так.

Из-за специфики моей работы я имею возможность сравнивать стабильность и надежность различных *nix-систем. Я бы не назвал gentoo самой стабильной и надежной.

>... т.е. дебиан фактически предлагает использовать i386-версию на amd64 (это в 2007 году-то! ...)

Ну, и что? Предположим, что абсолютно весь софт уже переписали - дальше что? Что вы думаете это даст лично вам? Увеличение производительности программ общего назначения? Сокращение времени загрузки в два раза? Уменьшение времени компиляции ? - Я вам отвечу - ничего! Никакой разницы нет, и быть в таких задачах не может в принципе.

Если все дистрибутивы имеют тоже самое ядро Линуса и практически тот же набор софта, как какойто дистрибутив может быть стабильнее другого? Сколько дистров я не перепробовал ни разу ни один не упал, разве что изза кривизны своих же рук.

>Применимо к базам IBM DB2

А как wine относится к IBM DB2?

>Реальный пример: чтобы не приходилось испытывать геморроидальные неудобства при превышении процессом объема памяти 4 гига (без падения производительности). Применимо к базам IBM DB2. Конечно, оно умеет поднимать второй экземпляр сервера баз данных, но это лишний расход памяти и процессорного времени, да и к тому же создает дополнительные проблемы иногда. В серваке ведь может стоять и 8 и 16 Гиг.

Это все понятно - для таких задач оно и предназначено, тут и вопросов даже не возникает. Но мне кажется, что на данный момент для домашнего и обычного офисного применения такие объемы памяти несколько черезмерны. А слепо ставить 64х битную ОС, только на том основании, что - раз процессор ее поддерживает, то обязательно нужно ее поставить, а то буду чувствовать себя не полноценным... Несколько глупо мне кажется.

> Ну скажите наконец - чего нет для десктопа (и всего остального) в Debian, и что есть для этого в других дистрибутивах? Чем Debian desktop отличается например от SuSE десктопа, или Федоры?

Не берусь утверждать наверняка, просто пока Etch не ставил. Если брать 32-х битную сборку -- всё есть. Если не гнаться за версиями софта, а работать. В 64-х битной сборке: 1. Wine собрали нормально? А Wine@ethersoft ставится? (нужно ведь для бухов с их убогим 1С) 2. Flash 9-ой версии на него ставится? (сайты поставщиков на нем, некуда деваться) 3. Как насчет Skype? 4. Как насчет Gizmo?

Сам я сидел на дебе. Потом перелез на убунту, но убунта что-то несколько кривовата. Буду обратно на деб слезать.

Интересуюсь сугубо из практических соображений. Конечно с одной стороны можно и 32-х битную сборку поставить, проблем меньше. С другой -- нафига тогда все эти супер-пупер 64-битные технологии?

Насколько я помню, маркетоиды давили на ускорение обработки мультимедии всякой... кто-нибудь реально заметил ускорение? Хотя-бы 15% при кодировании-декодировании звука, видео (например в IP-телефонии)?

Best regards, Zumz.

Встанет ли он на DELL inspiron 6000? будет ли работать wifi из коробки?

> А как wine относится к IBM DB2?

Никак. Это разные задачи. Но плодить зоопарк тоже как-то не хочется. Я вполне понимаю, что AMD64 не предназначен для десктопа, где куча всякой фигни типа Flash и Wine. Просто прощупываю почву, где можно применять. Например, у кого есть опыт работы со сборками AMD64? Интересует производительность с базами данных, IP-телефония (Asterisk), работа как роутера-файрволла при высоких нагрузках (если считать конечно нагрузку высокой на скорости 100 МБит линии под завязку)?

Отличаются i386 сборки и AMD64? Если да, то насколько?

Best regards, Zumz

>Интересуюсь сугубо из практических соображений. Конечно с одной стороны можно и 32-х битную сборку поставить, проблем меньше. С другой -- нафига тогда все эти супер-пупер 64-битные технологии? Насколько я помню, маркетоиды давили на ускорение обработки мультимедии всякой... кто-нибудь реально заметил ускорение? Хотя-бы 15% при кодировании-декодировании звука, видео (например в IP-телефонии)?

Какие технологии? Вы о чем? Все 64х-битные технологии сводятся по-большому счету в расширении адресного пространства, и возможности использовать объемы оперативной памяти сверх четырех гигабайт и обработки очень больших массивов довольно специфичных данных. Для ваших задач это актуально? Если да, то ставьте 64, если нет - то тоже можете поставить, если будете чувствовать себя увереннее. Я лично пока никакого смысла для себя в этом не вижу, хотя вожусь с 64х-битной архитектурой уже пару лет, и процессоры все тоже 64х битные.

> Предположим, что абсолютно весь софт уже переписали - дальше что?

Дальше можно это использовать.

> Что вы думаете это даст лично вам?

Скорость. Совместимость с будущими системами. Сделать переход на x86_64 сейчас, и не иметь проблемы перехода потом. А потом придется, и достаточно скоро - http://catb.org/~esr/writings/world-domination/world-domination-201.html

> Увеличение производительности программ общего назначения?

Разумеется.

> Сокращение времени загрузки в два раза?

Конечно, нет!

> Уменьшение времени компиляции ?

Не знаю, компиляция под x86_64 дает новые оптимизации, утилизация их требует времени. Но у меня не генту, это меня не волнует.

Теперь факты. Перевод программ на x86_64 дает увеличение скорости на 10-20%. Много это или мало? Больше, чем дают большинство флагов оптимизации. Ворд-процессор вряд ли ускорится, а его ускорение заметно не будет вообще; ускорение работы mplayer'а или фильтра в гимпе (т.е. там, где сейчас идет борьба за ключики оптимизации) будет заметно и полезно. Бенчмарки существуют, но конечно, в линуксе в основном делались бенчмарки серверного софта; но можно посмотреть хотя бы на различные бенчмарки виндового 64-х битного софта на соответствующих сайтах.

Ускорение достигается по нескольким причинам, в частности это в два раза увеличенное количество регистров (объяснять, почему это важно, надеюсь, не требуется?) и увеличенная разрядность. У gcc неплохой оптимизатор, и он это использует. Можете проверить - скомпилировать какой-нибудь несложный код на x86_64 c -m64 и -m32 и убедится в меньшем количестве (более сложных, задействующих все 64 бита в регистре) инструкций в 64-х битном коде. Без какой-либо модификации приложения.

Наконец, просто попробуйте. И не надо брызгать слюнями, пожалуйста. Я не знаю, что вы так невзлюбили 64-х битные системы (за плохую поддержку в любимом дистрибутиве, может быть?), но утверждать, что они дают только увеличение адресуемой памяти в корне неправильно.

Ребята, переходите на Mac OS X

> Если все дистрибутивы имеют тоже самое ядро Линуса и практически тот же набор софта, как какойто дистрибутив может быть стабильнее другого? Сколько дистров я не перепробовал ни разу ни один не упал, разве что изза кривизны своих же рук.

Есть пара моментов:

1) Дистрибутивы на основе freeze стабильнее, чем дистрибутивы на основе current. В связи с чем gentoo нужно сравнивать не с debian stable, а с debian testing. К тому же сервера на основе freeze-дистрибутивов легче поддаются автоматизации при минимальном вмешательстве администратора.

2) Скорость реакции на появляющиеся уязвимости и баги, наличие не закрытых уязвимостей. В прошлом году самыми шустрыми оказались Red Hat, потом debian, а потом gentoo.

3) В случае с gentoo вам приходится быть, практически, мэйнтейнером всего дистрибутива. Идеально, если у вас всего 1-5 серверов gentoo. Но если у вас несколько десятков серверов - вы физически не сможете их адекватно поддерживать.

> Это ужасно. Гном 2.14. Хорошо, что не 2.0.

Хм, Сергей, год назад ты говорил, что Гном 2.14 -- это прекрасно.

> Какие технологии? Вы о чем? Все 64х-битные технологии сводятся по-большому счету в расширении адресного пространства, и возможности использовать объемы оперативной памяти сверх четырех гигабайт и обработки очень больших массивов довольно специфичных данных.

Да, это актуально на серверах. Судя по тестам на производительность, увеличивается вроде-бы не только адресное пространство, но и скорость обработки. Например полей string и CLOB в базах вроде-бы значительно быстрее обрабатываются... еще кой-какие улучшения.

Можно и поставить. Как говорится, дурное дело -- нехитрое. Не хочется только время терять.

У Вас лично какие впечатления от применения 64-х битных систем?

Если есть разница при работе с базами, звуком, видео, VPN, то поделитесь, очень интересно узнать, стоит оно того, чтобы ставить и разбираться с новыми багами или ну его до будущих времен.

Best regards, Zumz

типо остроумно?

Re: Debian Etch 4.0 Released!

Не догоняю, почему у меня Gnome 2.18 на FreeBSD 6.2 и даже OpenBSD младше 2.16 ничего не знает, а на *супер-современном* линуксе 2.14?!

LOL!

Amd64 в режиме 64 бита быстрее работает чем i386 вариант и весьма нормально для Debian Etch. почему из этого надо устраивать политику и меряться принципами ? Еще ни разу подобные высказывания не подкреплялись цыфрами. Да, чтобы это прочувствовать на десктопе нужно иметь RAM ~ 1 Gib двух канальной DDR и более , в случае 512 Mib RAM - "страдать или наслаждаться" - разницы нет:) В пересчете на тактовые частоты это равносильно заявлению: Так как я купил уже Athlon 3000+ и могу смотреть фильмы - то считаю не нужным выпуск моделей 3200+ , 3400+ так как мне и так хорошо с тем что есть. :)))) Просто поразительно, как же тогда произошел переход с 16 на 32 бита ? :))) Кстати ,Wine для amd64 пребывает в Sid и для моих задач хорошо работает

> 1) Дистрибутивы на основе freeze стабильнее, чем дистрибутивы на основе current.

В дебиане извращена идея freeze. Freeze нужен для того, чтобы прошло какое-то время, в течение которого были обнаружены новые серьезные баги. Софт в Дебиане в среднем настолько стар, что на его баги upstream разработчики давно забили (т.к. они исправлены в новых релизах). Один пример я уже приводил выше. Хотите другой - пожалуйста. Какой смысл иметь в свежем релизе гном 2.14, если к 2.16 вышли уже 3 багфикс релиза?

> В случае с gentoo вам приходится быть, практически, мэйнтейнером всего дистрибутива. Идеально, если у вас всего 1-5 серверов gentoo. Но если у вас несколько десятков серверов - вы физически не сможете их адекватно поддерживать.

Все ровно наоборот - чем больше у вас серверов, тем проще поддерживать Генту. Пакет компилится на одной машине и ставится на всех.

И я, кстати, никогда не говорил, что Генту - это универсальный подход. Я говорил, лишь, что багов меньше. Я с 1998 года на Дебиане, после выпуска Саржа пытался уйти на Убунту, в итоге сижу уже полтора года на Генту. Мой рейтинг стабильности: 1) Генту 2) Дебиан 3) Убунту (абсолютное глюкалово). Про другие дистры не знаю - не пробовал.