Форум проекта PuppyRus Linux

Разработки проекта PuppyRus => Разработка PFS и Initrd => Тема начата: betcher от 28 Май 2019, 08:33:30

Название: стоит ли базу дробить и делать псевдомонолит?
Отправлено: betcher от 28 Май 2019, 08:33:30
стоит ли базу дробить и делать псевдомонолит? Да, это удобно сборщику, не тратить время на перепаковку большого модуля, но имея pfs-utils нетрудно разобрать монолит на составляющие, отладить в режиме псевдомонолита и собрать обратно.
База в виде pfs контейнера мне кажется идея хорошая. Я и в магос такое предлагал, но Михаил был против. Он идеей контейнеров вообще как-то не проникся :)
Название: Re: Порядок слоев AUFS
Отправлено: DdShurick от 28 Май 2019, 08:39:23
База в виде pfs контейнера
В Puppy была изначально.
Название: Re: стоит ли базу дробить и делать псевдомонолит?
Отправлено: sfs от 28 Май 2019, 08:58:31
База в виде pfs контейнера
Не понял - имеется ввиду, что базовый модуль - составной и в нем каждый пакет - отдельный подмодуль как было у нас в PR (почему и родилась идея pfs-util)
Или что...?
Название: Re: стоит ли базу дробить и делать псевдомонолит?
Отправлено: betcher от 28 Май 2019, 09:02:13
Не понял - имеется ввиду, что базовый модуль - составной
Я так понял.
Название: Re: стоит ли базу дробить и делать псевдомонолит?
Отправлено: sfs от 28 Май 2019, 09:09:04
Ну если что-то забыл и чтобы и далее не забыть - прилепил и получил составной - это одно
Т.е. по сути монолит. его удобно собирать ПМ донора
Далее подключив базовый модуль в низ - так же ПМ (хотя смотря что собирать - иногда удобнее руками) собираем ТК ДЕ и т.п.

Каждый пакет - отдельный подмодуль - совсем другое... Только как такое собирать , как разруливать зависимости и хватил ли в ядре aufs слоев....
И главное - чем это лучше....
Название: Re: стоит ли базу дробить и делать псевдомонолит?
Отправлено: neobht от 28 Май 2019, 17:38:57
Смысловой уровень по тематике должен быть в базовой поставке.
Да и пользовательский не мешало бы также делать.

А вообще тут ИИ должен работать и проводить кластеризацию на уровне зависимостей библиотек и пересечений файлов. По хорошему необходимо сделать ldd для всех бинарей как минимум и кластеризовать на составные части. На втором уровне отследить зависимости на уровне данных - конфиги и скрипты, но это уровень уже слишком умного анализа - так умеют делать только в диссертациях и на практике таких решений наверное нет. За решение этой задачи дают много денег в виде премии за решение задачи тысячелетия :)))
Название: Re: стоит ли базу дробить и делать псевдомонолит?
Отправлено: betcher от 28 Май 2019, 18:25:50
Антон, ты с нами из будущего разговариваешь? :)
Название: Re: стоит ли базу дробить и делать псевдомонолит?
Отправлено: knn от 28 Май 2019, 18:45:21
ИИ
  "офтопный вопрос" по случаю (если не откажете в ответе, то по-возможности как можно проще [вопрос почти аллегоричный, и возможно некорректный]):
  где граница между Программой(набором программ) и ИИ?
Название: Re: стоит ли базу дробить и делать псевдомонолит?
Отправлено: krasnyh от 28 Май 2019, 18:57:44
Тест Тьюринга (https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D1%81%D1%82_%D0%A2%D1%8C%D1%8E%D1%80%D0%B8%D0%BD%D0%B3%D0%B0)
Если тест пройден, то ИИ. )
Название: Re: стоит ли базу дробить и делать псевдомонолит?
Отправлено: knn от 28 Май 2019, 19:12:00
Тест Тьюринга
Если тест пройден, то ИИ. )
спасибо.
  )  относительно аллегорично:
  Пример -  ситуация, с наличием "конфликта интересов двух сторон ". Причем с одной стороны один человек, с другой - трое. Все четверо "примерно равны". Просто разговор/беседа за отстаивание мнения/интереса.
   Если беседа затягивается - 99,999999999% - "1 vs 3" - "без вариантов". )
Название: Re: стоит ли базу дробить и делать псевдомонолит?
Отправлено: neobht от 28 Май 2019, 20:56:01
Антон, ты с нами из будущего разговариваешь? :)
:)
Название: Re: стоит ли базу дробить и делать псевдомонолит?
Отправлено: DdShurick от 29 Май 2019, 09:44:08
 При разработке базы,  как и любого другого модуля, несомненно удобнее псевдомонолит из нескольких слоёв, для релиза лучше монолит.
Судя по количеству модулей, у нас всё в стадии "вечной" разработки.