Debian Etch 4.0 Released!

как вы достали с этим гномом :))) у вас что есть релизы в gentoo ? gentoo нормально хоть раз ложилось на диски самой командой ? с таки успехом выкачайте себе Gnome 2.16.3 из bp или Gnome 2.18 из experimental - или это только в gentoo можно делать ? И почему ,бы вам не рассказать про дурацкие размеры файлов openoffice в gentoo ? - мы бы и по сочуствовали :)))

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

Как раз решение для пользователей - нету кучи багов (сужу по Сусе 10.1 amd64). Выбрал AMD64 то и работай с AMD64. Ты же не требуешь работы i386 для sparc ? С какого перепугу ты требуешь работу i386 для _другой_ архитектуры AMD64.

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

Правильная идея freeze, с вашей точки зрения, это и есть debian testing, gentoo. Команды debian, rhel и администраторы этих систем считают по-другому.

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

А если на всех этих серверах работают совершенно различные сервисы? И ваша задача - обновить системы, и при этом обеспечить неизменную работоспособность обновленных версий сервисов.

> И я, кстати, никогда не говорил, что Генту - это универсальный подход. Я говорил, лишь, что багов меньше.

По поводу багов - смотрите мой предыдущий пост.

>Amd64 в режиме 64 бита быстрее работает чем i386 вариант

Тесты сестра. Что я вижу - amd64 работает медленее чем i386.

>В дебиане извращена идея freeze ...

Прекратите бредить, уже даже не смешно.

>Какой смысл иметь в свежем релизе гном 2.14

Мальчег! Почетай топег! Пошукай слово GTK-2.10 - и не задавай дурацких вопросов!

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

Freeze нужен для того, чтобы залатать наконец баги в старой версии, не мудохаясь с новыми багами в новой.

Клоуны размножались почкованием...

это не доказательство , .. ну скажите еще что 16 бит быстрее - и шас все кинутся опровергать :)))

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

Надеюсь это вы не меня имели ввиду ? :)

>это не доказательство, .. ну скажите еще что 16 бит быстрее - и шас все кинутся опровергать :)))

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

Нет конечно :)

Dell latitude d820, полет нормальный.

для корректности нужно, будет обождать - пока есть только свжепоставленный релиз Etch amd64, есть и iso релиза etch i386 - но нужно зачистить место на HDD для установки :)))

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

имхо вам на лоре делать нечего :)

>В убунту они менее консервативные, что не всегда хорошо.

Такая консервативность особенно хороша на кладбище. Чего этой поделке и желаю.

юбунте-то?

Раз больше размеры регистров то и больше потребление памяти. Это раз.

Два. Что касается оптимизации, никто не мешает оптимизировать точно так же, но с расчетом на 32 разрядные регистры. Это два.

Что касается ускорения, то это спорно, т.к. стек растет, за счет изменения адресации памяти.

Пробовал я. И пробую. Домашний десктоп работает на 64битах уже года 3. А то и 4. Т.е. с момента появления первых amd64 и поддержки оной в gentoo.

Все что могу сказать, так это, что памяти кушает он больше, работает немного медленнее.

Так что, если не нужна адресация больше 4х Гб, я бы не стал уходить с 32 битов ;)

Кстати, не первый раз именно гентушники утверждают подобное. Но, для debian все иначе (возможно влияет и характеристики железа) ,хотя последнее время вариант для i386 стал и быстрее шевелится - amd64 быстрее будет в Debian Etch.

УРА!!! дождался таки...

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

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

+1

Хе-хе... :)
kagor@darkstar:~$ cat /etc/debian_version
lenny/sid

>как вы достали с этим гномом :)))

+1000 :))))

Однако, самым важным оказалось хиганутое гномоподелие - "лопата без рукоятки", гномерам видимо так нехватает фич, что они молятся на каждый новый релиз, а не включили - все, начинается стон ;)))))

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

Это, если что, тестинг.

И хватит заражать нас красноглазием!!!

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

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

Это всего лишь говорит о том, что ищите дистрибутив для себя, вот и все. Меня это например полностью устраивает. :)

Начитался-начитался и поставил себе на ноут йентот Этч.

Тошиба Сателайт А110-293. Все работает, полет пока нормальный, как будет дальше посмотрим.

Слез с Сузи и буду сравнивать, пока нравится :)

Дебиану на десктопе быть!

Тестинг рулед ;)

> Раз больше размеры регистров то и больше потребление памяти. Это раз.

Оп-па. Ну и логика! Раз _больше_ регистров, то меньше потребление памяти! Потому что больше информации можно сохранить непосредственно в регистрах, имея к ней быстрый доступ и экономя память и место в кэше.

> работает немного медленнее

У меня (на федоре) ровно обратные впечатления.

> я бы не стал уходить с 32 битов ;)

По приколу решил сейчас потестить элементарный код на пару страниц, считающий sha1-сумму. Без оптимизаций, специальных ухищрений, без использования 64-х битной арифметики. Компилил gcc -O3 -mtune=generic -m32 и -m64 соответственно, потом прогнал на 150мб файлик.

Прогнал раз десять. Стабильно получаю время выполнения 2.90-2.91 с -m32 и 2.17-2.20 с -m64. Железка - core 2 duo (на athlon64 разница должна быть заметнее). Вы действительно считаете, что видя подобный прирост практически в любой маленькой подзадаче можно получить общие тормоза, описываемые вами при переходе на x86-64?

Вот код, на всякий случай: http://uguu.org/src_belldandy_c.html

Памяти кушается несколько больше - согласен. Да, если памяти совсем в обрез и из-за нее уже тормозит, на 64-х би итах будет тормозить еще больше. Ну тут уж вы ССЗБ...

> Оп-па. Ну и логика! Раз _больше_ регистров, то меньше потребление памяти! Потому что больше информации можно сохранить непосредственно в регистрах, имея к ней быстрый доступ и экономя память и место в кэше.

Я не о их колличестве, а о размере. Он вырос, значит и вырос стек, не думаете?

> По приколу решил сейчас потестить элементарный код на пару страниц, считающий sha1-сумму. Без оптимизаций, специальных ухищрений, без использования 64-х битной арифметики. Компилил gcc -O3 -mtune=generic -m32 и -m64 соответственно, потом прогнал на 150мб файлик.

угу, а то что включает m32 и m64 вы не учитываете?

Первый CD скачал, ситему поставил. Нормалёк. Доволен.

> Я не о их колличестве, а о размере. Он вырос, значит и вырос стек, не думаете?

Да все я думаю. И кэш теперь расходуется не так эффективно и все такое. Но дело в том, что выйгрыш окупает эти расходы.

> угу, а то что включает m32 и m64 вы не учитываете?

*устало* Я же привел все флаги. Попробуйте у себя, если не верите. -m32 и -m64 только переключают тип выходного кода, не более того.

/me ушол искать статьи про поизводительность в режиме х86-64

>А с чего ты взял, что кого-то должно интересовать, чего ты там своим изъеденным вендой мозгом хочешь? Почему ты вообще решил, что Debian делается для тебя и подобных тебе мальчеков-хачу

Ты думаешь, что его делают для таких как ты? тогда ты себе явно льстишь.. В любом нормальном дистре должны быть свежие версии популярных десктопов, поэтому дебианщики вместо того чтобы дрочит все это время, могли бы и сделать нормальную версию гнома.

Мучаюсь дилеммой: использовать etch с нестандартым ядром (встроенная GMA X3000 с 2.6.18 не дружит) или перейти gentoo. В связи с чем есть пара вопросов:

1. Когда в testing появится хотябы 2.6.20?

2. Как в тэстинге обстоят дела с security фиксами ядра?

> то я вижу - amd64 работает медленее чем i386.

Это наверно был EM64T :)

А так, посмотри в инете - gzip, например, показывал 2х кратное ускорение.

> 1. Когда в testing появится хотябы 2.6.20?

Через пару недель, думаю все будет. Может даже меньше. В sid прогназирую скоро, очень скоро.

> 2. Как в тэстинге обстоят дела с security фиксами ядра?

Хорошо :)

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

Приятно, конечно... Да только ничего нового это не дало))

dima@notebook:~$ less /etc/debian_version 4.0 Стоит уже 4 месяца... Жалоб и нареканий нет...

По правде сказать, Деба - любимый дистрибутив... Стабильность, удобные инструменты управления пакетами, огромный репозиторий. Лично мне больше ничего и не надо.)) До этого использовал RedHat\Fedora\ASP. Федора не понравилось своей нестабильностью. АСП, также не впечатлил. Старая Шапка нравилась, кстати до сих пор на работе стаит (причем 7.2).

вместо "стаит", следует читать "стоит" ))))

Прошу прощения, за мой албанский;)

Судя по тому, что тема про ALT обогнала тему про Debiana по количеству постов почти в два раза, российский производитель пользуицца большей популярностью. :-D

отличная новость

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

Никто тебе ничего не должен, особенно дебианщики. Возьми и сделай 'нормальную версию гнома', покажи всем как ты быстр и умён, кто тебе мешает? А впрочем можешь свой дистрибутив создать и воплотить все свои идеи и мысли. Или только лаять можешь про желание "свежего" гнома? А дрочишь ты сам довольно регулярно и судя по твоим высказваниям выбираешь в качестве фантазии перделки на экране своего монитора.

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

Блин, ну почему я всегда забываю об авторитетности мнения сраных^W анонимусов с ЛОРа....

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

Ты тоже мог бы не дрочить, а сделать хоть что-то. Но ты (в отличие от них) предпочитаешь первое.

>Судя по тому, что тема про ALT обогнала тему про Debiana по количеству постов почти в два раза, российский производитель пользуицца большей популярностью. :-D

Сдаётся мне, что "популярность", выражающаяся в количестве постов на ЛОРе --- это популярность со знаком минус :)

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

Да-да это полный гон. Ядро в стейбле со сломанным fuse и проблемами с глючащим ext3(гонки в менеджере памяти) - два. С UTF8 - жопка. trafshow если собирать без особого бубна(-slang) на UTF8 системе перекосячивает. В новом glibc поменяли LC_NUMERIC для локали ru_RU на символ U+2002, для которого нет глифов, так что wget печатает квадратики. man с UTF8-манами не работает, печатает кракозябры вместо русских сообщений. groff для поддержки UTF8 не пропатчен. Даже в федоре этих проблем нет, не говоря уже про Debian. Багов мля нету... как обновишься так и прут проблемы изо всех щелей. Щас еще про надежность stable ветки генты байку расскажи. - Все вышеперечисленные проблемы - как раз со стейбл веткой.

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

Тот, в котором фильтруют бажный софт, следят за совместимостью и где отфильтрованный кривой софт лучше обработан напильником. Пример выше: у Gentoo есть проблемы, а у Debian, Ubuntu, Fedora их нет.

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

хз-хз. Уязвимость в tar фиксили несколько недель и гента и дебьян, обновления вышли с разницей в сутки, а вот насчет недавней баги http://www.frsirt.com/english/advisories/2007/0998 генту уже давно пофикшена, зато прошло уже три недели после того как я отписал в security@debian.org - ни ответа ни привета, дыра до сих пор стабильно эксплуатируется на стабильном debian sarge.

Sarge вообще-то oldstable. В etch дыра есть?

Ядро 2.6, glibc без NPTL :(

> Да все я думаю. И кэш теперь расходуется не так эффективно и все такое. Но дело в том, что выйгрыш окупает эти расходы.

Какой выигрыш? Регистры стали в два раза жирней, требования к памяти, соответственно, выросли в два раза. Частные случаи, когда данные не влезают в 32 бита (16, 8...) - это настолько частные, что можно не считать. А всякие векторные расширения для перемолачивания однотипных данных уже давно есть, если что.

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