Вышел Red Hat Enterprise Linux 7

XXXFS

Звучит как название порносайта

По теме - ждём СentOS 7.0, красношляпа не нужна

Ну иногда ядрёные модули может тянуть. Или ещё какие заморочки.

Прикладной софт?

Бывает энтерпрайзовый софт (обычно проприетарщина), не поддерживающий x86_64.

Что, в общем-то, нисколько не мешает ему так же точно впахивать на 64-битном хосте.

Какой толчок?

Толчок к закапыванию x86.
В разных Ubuntu преобладает дефолт. Многие юзеры юзают то, что предлагается по дефолту.
Ubuntu кстати уже продвигает x86_64 по дефолту, теперь шапка.
Меня это не может не радовать

Ну... «Прослойкой совместимости» являются те же самые либы, так же точно установленные в системе, как и 64-битные, только собранные под i686.

Кто знает, почему не ext4?

Не знаю как в рхеле, а в федоре на некоторой конфигурации не очень нового железа ext4 чудит, поэтому для надёжности один хрен иногда лучше ставить ext3, а если по умолчанию ставить тестовую ФС, то почему-бы и не XFS ;)

По теме - ждём СentOS 7.0, красношляпа не нужна

Кот тоже думает, что хозяин не нужен, а хавка в холодильнике возникает сама по себе ;)

выпуск обновлений будет производится в течение 10 лет

systemd

как раз и допилят

Не зря пиваса купил, всё ж не без повода пить

Это действительно веха, на данный набор пакетов будут равняться окружающие ближайшие пять лет, если всё пойдёт нормально. Надеюсь, RH не перемудрил с количеством изменений - изменилось по сравнению с прошлым релизом буквально всё, разве что кеды сохранили мажорную версию 4 :)

Вышла новая версия Red Hat Enterprise Linux 7, выпуск обновлений для которой будет производится в течение 10 лет.

Кроме того, разработчики CentOS объявили о присоединении разработчиков CERN Linux, вовлечённых в работу над Scientific Linux, к группе CentOS Core SIG, отвечающей за выпуск CentOS.

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

По теме - ждём СentOS 7.0, красношляпа не нужна

и где бы был тот центос без шляпы?

Так выпьем!

Помянем?

Ну... «Прослойкой совместимости» являются те же самые либы, так же точно установленные в системе, как и 64-битные, только собранные под i686.

В общем да, как-то так. Но не обязательно те же самые, скорее всего более древние.

Эх, если бы в репозитории центоси были почти все и достаточно новые федоровские программы и кодеки искаропки, как в RFRemix, то это был бы...

треш, как и сама федора.

Если есть деньги на лицензию RHEL, то и на железо найдутся. Плюс ниша RHEL - далеко не рабочие станции, а всякие middleware и DB сервера, а они на 32 бита перестали влазить уже лет 10 назад.

В общем да, как-то так. Но не обязательно те же самые, скорее всего более древние.

С чего вдруг? Те же самые версии, но собранные под i686. Посмотри репозитарии CentOS.

В общем да, как-то так. Но не обязательно те же самые, скорее всего более древние.

Нет ;) Это же не какой-нибудь бздяшный Linuxulator, основанный на FC10. Multilib — это как раз совпадающие по версиям 32- и 64-битные либы. Более того, даже на уровне пакетного менеджера по умолчанию невозможно поставить разные версии пакетов обеих архитектур, обеспечивающих multilib.

треш, как и сама федора.

Трэш, это бубунта, которая ставится почти полностью из сети в самой последней версии всего. Примерно, как если бы пользователь ставил XP а после инсталляции одного и того-же ZVER DVD, в зависимости от даты в календаре, на винте получалась то виста, то восьмёрка.

XFS настолько крута? (комментарий)

Уже сказали «не нужно»? Если нет, то я первый скажу: не нужно.

С чего вдруг? Те же самые версии, но собранные под i686. Посмотри репозитарии CentOS.

С того вдруг, что что-то новое писать специально в 32хбитном варианте для x86_64 не будут, а старые сборки часто завязаны на старые версии libc, libgcc и т.п. Это обычная практика в RHEL тянуть набор древних базовых либ на такой случай.

Трэш, это бубунта, которая ставится почти полностью из сети в самой последней версии всего. Примерно, как если бы пользователь ставил XP а после инсталляции одного и того-же ZVER DVD, в зависимости от даты в календаре, на винте получалась то виста, то восьмёрка.

Убунта, конечно, тоже треш, но у неё есть хотя бы серверные сборки и подобие LTS. И совсем не понятно зачем «выбор» одного гогна опрадывать фактом существования другого.

Руками бы собрали.

У ext4 пупок развяжется на 500 Tb. Т.е. формально она столько поддерживает, но если учесть, что информация о размещении файлов хранится линейно, то забей какой объём файлом

А где встречаются фрагментированные 500Г файлы?

Бывает энтерпрайзовый софт (обычно проприетарщина), не поддерживающий x86_64.

Есть же 32-битные библиотеки и соответствующий режим совместимости процессора, позволяющий запускать такие программы. Или там вообще всё, связанное с 32 битами выпилили?

Уже сказали «не нужно»? Если нет, то я первый скажу: не нужно.

Если RH будет не нужен, на какие шиши будет линукс развиваться?

Например autogrow файл ВМ.

Использование по умолчанию файловой системы XFS с поддержкой хранилищ размером до 500 Тб;

Это по умолчанию для рута и хоума тоже?

на какие шиши будет линукс развиваться?

Есть мнение, что лучше вообще не развиваться, чем развиваться так как сейчас.

С того вдруг, что что-то новое писать специально в 32хбитном варианте для x86_64 не будут, а старые сборки часто завязаны на старые версии libc, libgcc и т.п. Это обычная практика в RHEL тянуть набор древних базовых либ на такой случай.

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

У ext4 пупок развяжется на 500 Tb. Т.е. формально она столько поддерживает, но если учесть, что информация о размещении файлов хранится линейно, то забей какой объём файлом и система встанет раком.

Какое-то месиво из дезы. В ext4 блоки не хранятся линейно. Но и чтобы напороться в теории на эти грабли нужно иметь один очень большой файл, т.е. к общему объёму фс это не имеет прямого отношения.

Если коротко, то xfs радикально быстрее.

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

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

Это не ко мне вопрос. Но вообще да, тянут что попало.

Как раз к тебе. Ты написал какую-то чушь.

И немедленно выпил. Только 32-битных сборок жаль.

А apcaccess для чего?

За Microsoft не чокаясь.

Как раз к тебе. Ты написал какую-то чушь.

Если ты чего-то не знаешь, то это ещё не значит что это чушь.

В определенном колличестве синтетических тестов, при определенном соотношении параметров и нагрузки.

В подавляющем количестве практических серверных задач. Я, знаете ли, практик.

Это какой-то пипец. Сходи до x86_64 репозитария центоси и посмотри версию i686 пакетов в нём. А потом сравни с версией x86_64. Это так сложно? Лучше на ЛОРе позориться?

Есть мнение

Нет. Это брюзжание.

Если RH будет не нужен, на какие шиши будет линукс развиваться?

У шапки доля вклада в пределах 10-12%, так что будем объективны, шиши есть. Это я не к тому что шапка не нужна )

Нет. Это брюзжание.

Отчасти да, но, с другой стороны, зачем мне systemd, например?

Откуда цифры? Линусу и большинству мейнтейнеров ядра разве не RH платит зарплату?

развиваться так как сейчас.

Экосистема линукса уже давно не развивается.

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

А во вторых она разрабатывалась для жестких дисков большого объема. Не уверен что жесткий диск при ней не будет фрагментироваться.

Это какой-то пипец. Сходи до x86_64 репозитария центоси и посмотри версию i686 пакетов в нём. А потом сравни с версией x86_64. Это так сложно? Лучше на ЛОРе позориться?

Надоел со своим тупняком. Я не пишу про различия в сете версий пакетов если вдруг этого не заметил.

Кому удалось после этого прочитать логи

Уже пол года читаю, привык уже.

интересно когда состоится релиз центоса, обещали не задерживать

аргументов больше против

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

Не уверен что жесткий диск при ней не будет фрагментироваться.

У xfs есть отличный дефрагментатор.

В подавляющем количестве практических серверных задач.

Жду повального перехода на XFS всех серверов в ближайший месяц-два )