LINUX.ORG.RU

Gentoo анонсировали бинарную сборку gentoo-kernel-bin

 , ,


0

2

Проект Gentoo Distribution Kernel опубликовал новые пакеты Linux-ядра. Конфигурация ядер взята из Fedora Linux (до версии 5.7.9 использовался Arch Linux).

  1. Ядро с примененными genpatches, построенное с использованием менеджера пакетов, с настройками по умолчанию, либо пользовательской конфигурацией
sys-kernel/gentoo-kernel
  1. Предварительно собранная (бинарная) версия gentoo-kernel
sys-kernel/gentoo-kernel-bin
  1. Немодифицированное «ванильное» ядро
sys-kernel/vanilla-kernel

Главным отличием использования Distribution Kernels является возможность обновления до новых версий в процессе общего обновления «мира», без дополнительных ручных действий.

По умолчанию эти ядра поддерживают большинство оборудования, но они могут быть дополнительно сконфигурированы в /etc/portage/savedconfig.

>>> Подробности

★★★★

Проверено: alpha ()

А ещё говорят, что «генту непопулярна» - вон какие срачи вокруг неё до сих пор.

grem ★★★★★ ()
Ответ на: комментарий от grem

Срачи, не потому что Gentoo популярна, а потому что она небезразлична. Gentoo пришел CRUX в 2010 году. Gentoo в таком состоянии, в котором она сейчас есть, - труп.

bryak ★★★★ ()
Ответ на: комментарий от bryak

Не понимаю...

зачем мне на Raspberry Pi2, одном из «домашних» серваков, который я только что перезагрузил после обновления ядра, это ваше «стандартное ядро Debian». Для десктопа Ваше ядро годно. Для «сервера» нет. Задачи-то разные. И ядра, соответственно, тоже. А там кроме ядра ещё туча параметров, которые надо подкрутить.

Впрочем, ладно. Главное чтобы Вам это всё нравилось. =)

Moisha_Liberman ★★ ()
Ответ на: комментарий от bryak

Срачи? Срачи вокруг генточки...

просто потому, что подспудно «норот» понимает что что-то классное (генту) в этом мире мимо них проносят. И понимают что они слишком слабы чтобы нежно, но настойчиво подчинить себе достаточно сложную систему. Они понимают что живут в мире, где они ни на что не могут повлиять. Сказано – ststemd, вот и сиди с systemd. За вас всё уже выбрано и решено. Я же могу с systemd, могу и с OpenRC и elogind. Всё в моих руках. Та самая «швабодка», о которой тут на ЛОРе столько копий сломано.

Moisha_Liberman ★★ ()
Ответ на: Re: Вообще-то, да. от anonymous

Re: Вообще-то, да.

Сколько я раз повторял лицам либерального направления,

Либеральных методов Путина и Единой России не разделяю. Не либерал.

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

К геноциду проводимым Единой Россией под руководством Путина никакого отношения не имею. Людей СВЧ не облучаю, изотопами излучающими нейтроны не травлю.

Так что людей в погонах пусть боятся преступники с Единой России и Путин, за проведение геноцида людей на территории РФ им всем грозит вышка.

anonymous ()
Ответ на: комментарий от grem

Я тебе даже больше скажу, автор бинарного ядра и gentoo-kernel тоже я (mgorny просто команду из этого сделал). Мне в двойне забавнее читать данный топик ;)

Если кто-то когда-либо наткнётся на мой ответ:

  • да, я считаю что ядро компилировать нужно не всегда
  • нет, я не фанат -O3, -march=native и прироста производительности в 3%
  • нет, если я использую бинарные пакеты это не значит, что мне не нужна гента, это значит, что я компилирую когда вижу необходимость
  • нет, я не считаю что «умение тыкать кнопочки в menuconfig» это скилл обязательный для гентушника, а также не считаю что неумение это делать это признак отсутствия мозга
  • у проекта есть критики, это нормально. Это отнюдь не означает что он свернётся, этого не будет
  • тут многие забыли, что гента == свобода выбора, а не свобода сборки из исходников
Zlogene ()
Последнее исправление: Zlogene (всего исправлений: 1)
Ответ на: комментарий от Zlogene

в бинарном много что включено? есть ли возможность изменить нужные опции, типа 'governor', возможность подгрузки 'intel-microcode', или только драйвера лишние выключить?

spawn_sp ★★ ()
Ответ на: комментарий от Zlogene

автор бинарного ядра и gentoo-kernel тоже я

Я помню об этом по предыдущим темам ;)

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

grem ★★★★★ ()
Ответ на: комментарий от Zlogene

1. Дай мне ответы по каждому пункту: Gentoo анонсировали бинарную сборку gentoo-kernel-bin (комментарий) почему потребовалось отключать опции безопасности? Отдельный ответ по каждому пункту, чем и где мешала конкретная опция безопасности. Я помогу и скажу как обойти.

2. Дай ответ на эти вопросы: Gentoo анонсировали бинарную сборку gentoo-kernel-bin (комментарий) и Gentoo анонсировали бинарную сборку gentoo-kernel-bin (комментарий) у тебя вообще есть понимание, что при распространении ядра Linux в бинарной форме «свобода выбора» есть между:

а) Моя дверь закрыта на замок и ключи находятся у них. Они никогда мне не дадут ключи от моей двери и полностью контролируют кого впускать через мою дверь.

б) Дверь без замка, никакой защиты вообще нет.

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

anonymous ()
Ответ на: комментарий от Zlogene

не считаю что «умение тыкать кнопочки в menuconfig» это скилл обязательный для гентушника

Уже писал об этом неоднократно, `make menuconfig` при обновлении ядра использовать НЕЛЬЗЯ и умение тыкать кнопочками гентушника не спасет!

При обновлении ядра Linux каждый гентушник, всегда, должен использовать `make oldconfig` только так можно дать гарантии сборки корректного ядра.

Это прихоти Линуса Торвальдса, он умышленно, регулярно херит что-то в конфигах ядра и оставил единственный путь для обнаружения и исправления: `make oldconfig`. Следуя любым другим путем получите некорректное ядро, где что-то отвалилось, то сетевой экран, то какие драйвера...

Как написать скрипт с ИИ который ответит на вопросы `make oldconfig` - не знаю, в этом даже я помочь не смогу.

anonymous ()
Ответ на: комментарий от Zlogene

Да и слава Богу!

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

При установке лучше бы никогда. Но после установки лучше бы да, скомпилить. Резоны выше изложены, но тут уж каждому своё.

нет, я не фанат -O3, -march=native и прироста производительности в 3%

Лучше бы -О2 для С-кода, -О3 это больше к С++, наверное. К -march= лучше бы ещё и -mtune=, да и указать конкретный тип проца нехудо было бы. Но это всё так, мелочи. =)

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

Главное – не убивайте, если можно, возможность компилировать всё из исходников.

Но вот что мне лично не нравится, так это несколько вещей.

тут многие забыли, что гента == свобода выбора, а не свобода сборки из исходников

Да вот как раз этой самой свободы выбора и всё меньше остаётся, к сожалению. От той santa simplicata, которая была декларирована Роббинсом, к сожалению, остаётся хрен да маленько.

Судите сами:

  • Все пишут на питоне! Давайте и мы зафигачим portage на питоне! Чё мы как дураки без подарка? Зафигачили. И как? Полегчало? Сильно полегчало? Теперь я делаю eselect python list и сижу-в репе чешу на кой хрен мне аж три питона, да ещё и на какой-нибудь Raspberry Pi2. Нет, я не собираюсь отковыривать его из системы, хотя, глобально и стоит -python, но я в состоянии его поставить при необходимости. Один. Для «общесистемных» вещей, кмк, bash больше «к лицу» будет. Всё таки, для того и писался, а не как язык-коей непонятно для чего…

  • Профили. Поставьте профиль developer и удивитесь тому, сколько всего прилетит. А что, нельзя сделать разные профили? Ну, предположим, тот же python-developer, c++-developer, c-developer, а кому-то и (свят, свят, свят!) ruby-developer. Зачем всё что нужно в один профиль пихать? Да поставлю я себе ruby, если не дай Бог он мне понадобится. Нахрен он мне по дефолту?

В результате, ставиться приходится с одного профиля, не понимая зачем все остальные. Либо так оставить. Типа, вот вам метадистрибутив, гните как хотите (хотите, под сервер, хотите под С-разработку, да хоть подо что), ну либо распедалить разные профили под разные нужды.

Ну это так, чисто навскидку… Что накипело.

Moisha_Liberman ★★ ()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Ответ на: комментарий от anonymous

Я бы Вам ответил, но...

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

Я не буду этого делать, пока Вы сами не объясните мне где у Вас корень доверия (и существует ли он вообще) и где у Вас доверенный контур (и существует ли и он вообще).

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

Moisha_Liberman ★★ ()
Ответ на: комментарий от spawn_sp

На десктопе я гномовод...

недавно тоже на elogind переключился, новость как то пропустил

Так что, новость обрадовала. Ну а на серверах… а там-то systemd зачем? OpenRC в разы проще.

Moisha_Liberman ★★ ()
Ответ на: Да и слава Богу! от Moisha_Liberman

Re: Да и слава Богу!

Сделали бы они базовую систему как в FreeBSD, установил её за считанные минуты, а дальше пересобирайте, собирайте как хотите эту базу и прочие пакеты.

anonymous ()
Ответ на: Re: Да и слава Богу! от anonymous

Зачем?

Всё можно сделать проще.

Сделали бы они базовую систему как в FreeBSD, установил её за считанные минуты, а дальше пересобирайте, собирайте как хотите эту базу и прочие пакеты.

Если не модифицировать сильно make.conf сразу, на старте, то и пересобираться будет немного. Можно да, пересобрать потом.

Если модифицировать make.conf и делать по уму, то тогда проще сделать emerge -uDN @ system и только потом emerge -uDN @ world. Потому что первым шагом мы пересобираем общесистемные вещи и сам по себе тулчейн, а потом этим тулчейном пересобираем уже мир.

Другое дело что в общесистемные накидали всякого гуано так, что не разберёшься. Перл (зачем-то?), какие-то перловые модули, которые на первоначальной сборке системы на фиг не прибились… Про питон уже даже и не говорю. Вот почему и сборка базовой системы такая долгая.

Moisha_Liberman ★★ ()
Ответ на: Да и слава Богу! от Moisha_Liberman

Теперь я делаю eselect python list и сижу-в репе чешу на кой хрен мне аж три питона

Действительно, зачем ты сам поставил 3 (сейчас 4) версии третьего питона?

grem ★★★★★ ()
Ответ на: комментарий от grem

Ok.

eselect python list

Available Python interpreters, in order of preference:

[1] python3.7

[2] python3.9 (fallback)

[3] python3.8 (fallback)

[4] python2.7 (fallback)

Вывод echo $PYTHON_TARGETS и echo $PYTHON_SINGLE_TARGET пустой. В системе глобальный флаг указан -python, для отдельных пакетов только стоит в локальных разрешениях.

Возможно я туплю. Согласен. Но как убрать лишнее?

Moisha_Liberman ★★ ()
Последнее исправление: Moisha_Liberman (всего исправлений: 2)
Ответ на: Ok. от Moisha_Liberman

Если ты специально ничего не делал, то сейчас у тебя в системе не должно быть ничего кроме версий питон 2.7 и 3.7. Версию 2.7 уже сейчас очень активно выпиливают из gentoo и если у тебя нет пакетов, которые от него зависят (таких почти не осталось), то от него можно избавиться при желании.

Процесс выпиливания такой: если нет возможности удалить зависимость от питон 2.7, то пакет удаляется из репозитория. Если есть, то в новой ревизии поддержку удаляют и отправляют запрос о стабилизации новой ревизии, если есть стабильные ревизии, зависящие от питон 2.7. После стабилизации новой ревизии, всё зависящие от py2 удаляют.

На вывод eselect python list можешь не обращать внимания.

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

Насмешить?

Если ты специально ничего не делал,

Конечно нет. Дефолт. Вот я и тихо ху… «недоумеваю», в общем.

сейчас у тебя в системе не должно быть ничего кроме версий питон 2.7 и 3.7.

Если бы! Внимание на экран (лишний вывод поскипан):

$ python2.7
Python 2.7.18 (default, Sep 13 2020, 10:11:31)

$ python3.7
Python 3.7.9 (default, Aug 20 2020, 11:40:17) 

$ python3.8
Python 3.8.5 (default, Jul 22 2020, 15:40:40)

$ python3.9
Python 3.9.0rc2 (default, Sep 19 2020, 03:24:52)

Вон они, все как живые.

Moisha_Liberman ★★ ()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Ответ на: Насмешить? от Moisha_Liberman

Не знаю что у тебя случилось, но версии 3.7 и 3.8 я ставил специально, т.к. нужно было тестировать пакет, зависящий от python в том числе и с ними. А 3.9 у меня не установлен.

То есть я тогда для ряда пакетов добавлял python_targets_python3_7 и python_targets_python3_8.

make.conf у тебя они нигде не прописаны? В world не добавлены?

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 3)
Ответ на: комментарий от grem

Дык!

В том-то и проблема что я специально оставил $PYTHON_TARGETS и $PYTHON_SINGLE_TARGET пустыми. По идее, если я не просил ставить пистоны определённых версий, то я должен получить максимум одну-две версии этого кала. И то непонятно – как так я на С обхожусь одной версией библиотек и компилятором-линкером, а на питоне вынь да положь аж как минимум две версии этого кала. Потому что тупенькие не осиливают свой быдлокод, которым они «осчастливили» мир, перенести на самую свежую версию? А другие тупенькие, которые пилят этот говноязычок, не осиливают не обламывать обратную совместимость?

Видимо, логика здесь сходная с Вашей. 2.7 активно выпиливают, но ещё не выпилили, 3.9 слишком новый, а давай ещё накатим для гарантии пользователям и 3.7-3.8 чисто «для гарантии», а то вдруг что не заведётся. Ну вот и результат…

Подчеркну – я не ставил дополнительно никаких питонов, я их вообще не ставил.

Moisha_Liberman ★★ ()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Ответ на: Дык! от Moisha_Liberman

Re: Дык!

С теориями заговора не ко мне.

cat /etc/portage/package.use/python_targets.use 

dev-libs/libxml2 python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/certifi python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/cython python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/docutils -python_targets_python2_7
dev-python/iniparse python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/matplotlib -python_targets_python2_7
dev-python/numpy -python_targets_python2_7 python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/setuptools python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/six python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/lxml python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-util/scons python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
media-libs/opencv -python_targets_python2_7 python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
# move sci-libs/scipy dev-python/scipy
dev-python/scipy -python_targets_python2_7
sci-visualization/veusz -python_targets_python2_7
dev-python/reportlab -python_targets_python2_7
dev-python/PyQt5 python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/PyQt5-sip python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-vcs/mercurial -python_targets_python2_7 python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/sip python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/qscintilla-python python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/dbus-python python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/zstandard python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/cffi python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/pycparser python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/ply python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
dev-python/pygments python_targets_python3_7 python_targets_python3_8 python_targets_python3_6
>=dev-python/setuptools_scm-4.1.2 python_targets_python3_8 python_targets_python3_6

grem ★★★★★ ()
Ответ на: Re: Дык! от grem

Это не теория заговора.

Это его практика. =)))

Проверяю на малинке второй. Свежеустановленная гента, используется как сервачок, т.е., пистон может быть включён разве что в libxml2 как локальный use-flag. Как глобальный, там -python. Больше ничего не ставилось, я имею в виду отдельные версии питона.

eselect python list меня не удивил. Всё ровно тоже. Переменные окружения – тоже пустые. Проверяем наличие:

$ python2.7
Python 2.7.18 (default, Sep 14 2020, 11:02:59)

$ python3.7
Python 3.7.9 (default, Sep  4 2020, 01:57:12)

$ python3.8
Python 3.8.5 (default, Sep  4 2020, 03:49:11)

$ python3.9
Python 3.9.0rc2 (default, Sep 20 2020, 21:18:43)

Провести отдельно установку заново на какую-нибудь машину?

Moisha_Liberman ★★ ()
Ответ на: Это не теория заговора. от Moisha_Liberman

Посмотри, что записано из python в /var/lob/portage/world

У меня он пустой, т.к. я всё держу в /etc/portage/set/

Так небось конфиги тащишь со старых. Профиль какой?

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

Да пусто там.

Посмотри, что записано из python в /var/lob/portage/world

cat /var/lib/portage/world|grep python – на выходе ноль. Пусто. Нет ничего. Говорю же – питон выпилен через глобальный USE – -python.

Профиль какой?

Ну вот на ноуте – eselect profile list[21] default/linux/amd64/17.1/desktop/gnome (stable)

Так небось конфиги тащишь со старых.

Нет.

Moisha_Liberman ★★ ()
Ответ на: комментарий от grem

Как раз здесь всё ясно как Божий день.

Логику я изложил выше. Ну и да. Тупенькие детишки с апломбом не понимают что погроммировать на языке с непредсказуемой обратной совместимостью, это нарываться на грабли. Можно на убунточке проверить, но сомневаюсь что результат будет отличаться. Так что, у тупеньких есть возможность кодерасить, но грабли из-за этого у всех без исключения (разве что в LFS полегче). Зато бизапасный езыгжи! Вот так бы взял и… «сильно ударил» бы в общем.

Только что прилетел 3.8.6. Радости полны штаны. =)))

Moisha_Liberman ★★ ()
Ответ на: комментарий от Zlogene

Пипец ты крутой. Мой респект и уважуха тебе, парень.

anonymous ()
Ответ на: комментарий от anonymous

Все сделали:

echo "sys-kernel/gentoo-kernel
sys-kernel/gentoo-kernel-bin" >> /etc/portage/package.mask/denylist
anonymous ()
Ответ на: комментарий от Zlogene

За труд спасибо!

Вы в кулуарах Gentoo не рассматривали модель сродни FreeBSD с его базой и портами. Модель достаточно удобна. Захотел поставил бинарники, захотел собрал из исходных кодов.

Готовая собранная база значительно облегчила путь новеньким пользователям.

anonymous ()
Ответ на: комментарий от anonymous

Спасай генту от "убунтологов"!!!

в кулуарах Gentoo не рассматривали модель сродни FreeBSD с его базой

В Gentoo надо вернуть сборку только со stage1, а stage2, stage3, stage4 выкинуть. Так сообщество Gentoo очистится от «этих специалистов» и дистр станет опять пригодным для серьезного использования. А иначе: Gentoo анонсировали бинарную сборку gentoo-kernel-bin (комментарий)

anonymous ()
Ответ на: комментарий от grem

Ага...

Значит, это тебе в наказание.

За грехи это всё… За грехи тяжкие… =)

На самом деле, нет, не всё у меня так уж и плохо. В общем, я честно подождал пока кто-нибудь хоть что-нибудь умное скажет, но нет, не судьба. =)))

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

Надо в том же make.conf прописать:

PYTHON_TARGETS=«python2_7 python3_7» PYTHON_SINGLE_TARGET=«python3_7»

С 2.7 всё переходят, да ни как чёт не перейдут, а 3.7 это «наше новое всё». Тогда это говно будет ставиться только в двух версиях – 2.7 и 3.7. Тоже плохо, но не четыре же!

Если по недосмотру поставили кучу питонов, то тогда выставить эти переменные, дальше:

eselect python list; выставляем через eselect python set нужный
emerge --changed-use --deep @world
emerge --depclean dev-lang/python
eselect python cleanup

Но тут вот вопрос возникает – это что за «свобода» такая, если хочешь-не хочешь, а разгребай это говно, которым я, например, не пользуюсь как правило вовсе, ну или ладно, пару раз в году? Уж больно меня напрягает непредсказуемая обратная совместимость…

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

Moisha_Liberman ★★ ()
Ответ на: Ага... от Moisha_Liberman

PYTHON_TARGETS=«python2_7 python3_7»

У меня они были закомментированы, я их добавил и оставил только 3.7

Скорее всего 3.8 прилетел из-за стабилизации, а почему 3.6 не удалялся …

eselect python cleanup

Хе-хе. Я уж было хотел предложить замаскировать 3.6 и 3.8.

Уж больно меня напрягает непредсказуемая обратная совместимость…

Ты на нём напишешь и не сопровождаешь код. Тебя это не должно напрягать.

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

Несогласен.

Ты на нём напишешь и не сопровождаешь код. Тебя это не должно напрягать.

То, что я не пишу и не сопровождаю на нём код, вовсе не означает того, что система без него не функционирует. Общесистемные вопросы «от Бога» решались без него. С/реже С++/bash’ик всегда были джентельменским набором системщиков.

По идее, python это язык для всяческого приклада. Зачем его затащили в систему, мне не ясно. И, собственно, последствия этого мы каждый раз при запуске emerge или аналогичного софта для обслуживания portage видим. Тормоза… тормоза… тормоза…

Всерьёз задумываюсь о миграции на paludis/cave. Хочу и pkgcore посмотреть.

Moisha_Liberman ★★ ()
Ответ на: Несогласен. от Moisha_Liberman

Re: Несогласен.

  1. Портаж делает обсчет достаточно быстро. Часть времени он читает с диска. И эта б0льшая часть времени его работы, нежели просчет. Если ты поставишь ссд, то ты увидишь, что стало быстрей. Но учти, что хенду может в ссд сделать дырку быстрей, чем аконади в кедах. Менять яп из-за 5 секунд ускорения и получить более дорогое сопровождение. Это не целе со образно.

  2. Еапи написал чувак, который сейчас не в команде генты. Кроме него никто дупля не отстреливает. Были попытки переписать портаж на го плюсы и даже раст, но никто не осилил. Паладис мертв лет 7.

Ваш бряк

anonymous ()
Ответ на: Re: Несогласен. от anonymous

И да и нет.

Менять яп из-за 5 секунд ускорения и получить более дорогое сопровождение. Это не целе со образно.

Я бы просто хотел убрать питон с уровня «часть системы, ставить обязательно» на уровень «кому надо, тот себе и поставит», где ему, собственно, и место. И вернуть генточку к тому виду, как это было от создания UNIX-систем заповедовано. К простоте, то есть. Ну не дело это приклад тащить на уровень системы. Добром это не кончается, впрочем, это даже обсуждать нечего, и так всё видно.

Я бы хотел получить что-то типа LFS, частично на баш-скриптах и с более удобным разруливанием зависимостей, с базой пакетов типа как в eix, том же sqlite или berkeley db… Ну вот как-то вот так, в общем и целом. «Что-то типа LFS» подразумевается как «базовая система», котрую в дальнейшем можно превращать во что угодно. Хочется в сервер? Значит, сервер. Хочется в десктоп? Значит, десктоп.

Понятно что с диска читать дольше, чем посчитать в памяти. Вот я и думаю что надо как-то к этому делу no-sql (ту же bdb) прикрутить, она как раз как embedded db работать умеет.

Еапи написал чувак, который сейчас не в команде генты. Кроме него никто дупля не отстреливает. Были попытки переписать портаж на го плюсы и даже раст, но никто не осилил. Паладис мертв лет 7.

Да я уже понял что там мало кто и что отдупляет. Честно. В основном «улудшайзинг» типа «а давайте создадим вот такой профиль и накидаем туда чё может понадобиться». Один профиль developer отбивает охоту называться разрабом, в этом профиле чего только нет, и нужного и ненужного… Приходится брать профиль gnome (без systemd), дальше emerge gnome-light, а дальше уже набивать обойму до нужного состояния по отдельности.

Сейчас через catalyst запилил себе live-usb с нескучными обоями, ведёрком софта и кучкой скриптов. Полностью и сразу русифицированный. Видно, так же надо и профили запилить под свои задачи. Иначе спасения нет и не ожидается.

Moisha_Liberman ★★ ()
Ответ на: комментарий от grem

Да я тоже сомневаюсь...

Это тебе не поможет.

Сама по себе система portage превращается в рак. Тут надо вырезать по максимуму, оставляя только реально рабочий минимум.

Moisha_Liberman ★★ ()
Ответ на: И да и нет. от Moisha_Liberman

Re: И да и нет.

Раньше Perl совали куда только можно, теперь вот питоны Того и гляди сварганят какой-нибудь gllibpy.

anonymous ()
Ответ на: Re: И да и нет. от anonymous

Да, перловые артефакты...

по сию пору заметны.

Раньше Perl совали куда только можно, теперь вот питоны

Ага… Мода… Она такая… переменчивая. И вот только сишечка на пару с bash’иком как были, так и есть. «Не модные» то есть… «Просто работают», что называется.

Moisha_Liberman ★★ ()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Ответ на: комментарий от grem

Ну это с какой стороны посмотреть...

Какой ещё минимум? И так куча вещей во внешних утилитах висит.

Если это про «экосистему» питона, то да. А так-то прилетает более чем до фига всего ненужного. И сам по себе питон и уже упомянутый выше перл и некоторые модули к нему. Прямо при установке. Зачем?

Moisha_Liberman ★★ ()
Ответ на: Ну это с какой стороны посмотреть... от Moisha_Liberman

Затем, что они используются средствами управления пакетами.

А переписывателей portage с питона на C++ в каждой пчихлечебнице уже чуть меньше чем Наполеонов.

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 2)
Ответ на: комментарий от grem

Ну вот мы и пришли к тому...

о чём я и толкую. Средство управления пакетами всё больше и больше начинает напоминать плоскостопого импотента. Т.е., ни в пи… (ни куда), в том числе и не в Красную Армию. Поэтому оно и работает в общем и целом. Вроде, работает, но как-то хреновато.

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

Moisha_Liberman ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.