Форум проекта PuppyRus Linux
Остальные обсуждения => Разговоры обо всём => Тема начата: for_wov от 21 Февраль 2015, 15:44:36
-
Вопрос меню поднимается на форуме в каждом 20-м сообщении. Либо не так пояснено, либо порог вхождения слишком разный, либо разные источники запуска и загрузчики, либо политика разработчиков очень либеральная. От того и желание поменьше всего там писать но иметь возможность гибко управлять процессом.
Что касается привычки работы с параметрами - то можно и не запоминать ничего - один раз сделать меню для наиболее распространенных вариантов использования и все.
можете описать эти "наиболее распостраненные варианты использования" в вашем понимании?
- целевое назначение дистрибутива: ремонт и восстановление, мультимедия, учеба, [веб]разработка, программирование, игры и т.д. Под назначение - соответствующие конфирурации(ini-файлы) и возможность расширять/сужать функционал по мере надобности(на ходу подключение/отключение [наборов]модулей). И все это учитывая источники запуска.
Понимаю что ваше задача - охватить спектр дистрибутивов и иметь возможность ими всеми гибко управлять на всех компьютерах. Здесь ИМХО пытаются из этого спектра выбрать максимально подходящий вариант для одного компьютера, к сожалению, не учитывая целевого назначения, или неосознавая что целевое назначение можно менять за счет модульности.
-
мои варианты схожи с вашими.
-
мои варианты схожи с вашими.
практические шаги по реализации? оффтоп?
-
практические шаги реализации в MagOS - это подобрать софт.
отчасти было реализовано в свое время примерно так: http://magos.sibsau.ru/repository/modules/2011/optional/
да. оффтоп.
надо пару сообщений отрезать в отдельную тему.
-
отчасти было реализовано
что помешало полностью тогда? что сейчас мешает?
-
полностью - невозможно.
софт меняется и поэтому задача была решена до какой-то степени.
главным образом развитие может давать только потребность пользователей.
в данном случае потребность практически полностью была реализована и запросов на добавление чего бы то ни было уже не было.
сейчас снова будет аналогичная подборка, но с учетом 2 лет развития софта и обновлений. :)
-
главным образом развитие может давать только потребность пользователей.
потребности сильно изменились? в какую сторону? предпочтения по DE? баланс console & gui?
сейчас снова будет аналогичная подборка, но с учетом 2 лет развития софта и обновлений. :)
на чьей пакетной базе планируете остановиться? чем обусловлен выбор?
-
Магос основана на Роса. Выбор обусловлен тем, что это продолжение Мандривы на которой изначально была основана магос.
Ну а сейчас Роса собирается весьма и весьма качественно, что не вызывает потребности выбрать что-то другое.
А так по своему опыту одни из качественных дистров - это Альтлинукс и Роса. Они какие-то ламповые для десктопа в отличие от других, которые являются просто дистрибутивами линукс ничем не отличающимися друг от друга.
Ну и плюс для меня очень важным является принадлежность отечественному в силу специфики организации в которой работаю.
Потребности не изменились. Конечно предпочтение gui.
-
Магос основана на Роса. Выбор обусловлен тем, что это продолжение Мандривы на которой изначально была основана магос.
ABF (Automatic Build Farm) на ваше усмотрение имеет явные преимущества перед AUR?
Немаловажный вопрос - багтрекинг (ошибки были и будут всегда вопрос лишь в системном, своевременном и качественном исправлении).
Какой формат багтрекинга выбрали бы вы для модульного дистра?
Они какие-то ламповые для десктопа в отличие от других
что конкретно подразумеваете под "ламповостью"?
-
Багтрекинг может быть любым, главное, чтобы разработчику было удобно видеть ошибки, а пользователю о них сообщать.
Aur - я не знаю. Abf - нравится и внешне и результат, который получается.
-
Под ламповостью подразумеваю такой набор факторов, что работая в системе получаешь удовольствие. Одним из успехов Росы считаю очень удачная разработка simplewelcome, которая многое заимствовала из OSX от эпла.
Считаю для себя практически идеальным интерфейс Mavericks.
-
arch (cpu-dependant:x86_64,ix86)
platform (distro-specific:)
repo(package-system-model:git,hg)
package-managers(pip{python},npm{nodejs})
package-compyling(gcc,[q]make=>devx)
package-porting(/opt,ld_path=>mkport)
package-testing(ldd,find-dep)
package-meta-data(ini,config,/etc/package,~/.package)
package-containers(deb,rpm,xzm,pfs=>sfs->to_web)
можете изменить(подчистить где надо/полностью переделать) схему как ее видите вы?
Какое место в ней может занять DE? systemd?
Просто интерес и хочется общую картину составить.
Как думаете лучше всего добиться портативности модулей? возможно ли? откинув в сторону контейнеры и принимая во внимание систему инициализации чтобы было удобно для разработчиков/администраторов/пользователей.
-
Я вижу систему, которая собирает себя сама по сети.
То есть изначально на машине пользователя может ничего не быть. В процессе работы пользователь запускает программы и они постепенно закачиваются в локальный кеш на машину пользователя. Спустя какое то время у пользователя получается полностью настроенное под его повседневные задачи окружение.
DE может быть любым.
За системой наподобие systemd будущее. Если systemd не забросят, то у нее есть все шансы стать системой запуска приложений в изолированном пространстве виртуальных контейнеров.
Файловая система будущего - btrfs.
-
Была тема типа: "Зачем мне нужен Puppy?" Для меня, за исключением игрушек дома - для всего (почти полная замена WinXP, минус антивирус, плюс Вайн). И не только PRA, а любой Puppy.
P.S. Если нет потребности в особо специализированном софте, то чем Puppy в этом плане отличен от "больших" Linux-ов?
-
Вопрос не в том для чего нужен паппи или роса или любой другой линукс (виндовс, мак, миникс и т.д) а в том как реализовывать модульность/портативность на практике. Ведь благодаря модульности есть (даст Бог появится полноценная) возможность грузиться по сети и грузить только то, что нужно на данный момент или под конкретные задачи. Думаю многие согласятся что с более слабым (на худой конец с жпрс-ным) интернетом выкачивать весь образ ~600(даже 200)mb для того, чтобы ,например, ответить на почту и пообщаться в чате/скайпе/и т.д все эти мегабайты - лишнее. Интернета может и не быть под рукой вовсе (щасливчики те у кого с этим нет вопросов). Мне лично паппи и подобные дистры нравятся за их размер и шустрость работы т.к. модуль весит мало и получить его локально это не то же самое, что скажем, в убунте пол системы зависимостей утащить. Плюс старое железо (ох как бы хотелось его заменить) добавляет ко всему свою ложку дегтя в бочку меда.
Все же кроме как помещения программ в /opt и прописывания в PATH есть реально рабочие методы не нарушая целостности системы (знать бы где границы минимальной ее части) портировать программы/[наборы]модули? До какой единицы можно/нужно дробить систему чтобы иметь возможность гибко подключать/отключать только то что необходимое на конкретном железе в конкретный промежуток времени для решения конкретных задач? Миникс вообще в этом плане молодцы есть только микроядро и остальное ПО (даже драйвера) каждая часть из которого в отдельной изолированной среде.
-
Я думаю, что самым наиболее идеальным вариантом является подход применяемый в mac osx. Где есть базовый набор библиотек, а каждая программа поставляется в своем контейнере. В нашем случае контейнер еще сделать модулем и будет сказка.
В магос мы это пробуем делать разделив систему на 2части : базовая(определенный набор поставляемый и ежемесячно обновляемый) и пользовательский (варьируется от задач). Весь пользовательский уровень сделан так, что в зависимостях у него только базовый уровень. Если две программы в пользовательском уровне имеют общие библиотеки, то они дублируются внутри каждого модуля, что утолщает их размер. В системе используется один из вариантов в более приоритетном слое aufs.
То есть я для себя однозначно делаю выбор в пользу функционала, а размер уходит на второй план. Если сделать наоборот, то будет некомфортно. Искать середину в роллинг дистрибутивах - бессмысленно, а если взять lts, то функционал устаревший.
-
Что касается сетевой загрузки, то squashfs позволяет подключив образ в несколько гигабайт, загружать только те блоки, которые содержут необходимую информацию. Это позволяет тоже не думать о занимаемом объеме. Я уже практически не использую системы на флешках или других носителях. Практически всегда загружаю систему по сети.
-
Я вижу систему, которая собирает себя сама по сети.
То есть изначально на машине пользователя может ничего не быть. В процессе работы пользователь запускает программы и они постепенно закачиваются в локальный кеш на машину пользователя. Спустя какое то время у пользователя получается полностью настроенное под его повседневные задачи окружение.
Но это же вылитый Richy. ;)
За системой наподобие systemd будущее. Если systemd не забросят
То на Linux можно поставить крест.
Почему вы стараетесь сделать сложным простое? Чтобы повысить порог вхождения? Последнее время Linux перестал быть простым, логичным и понятным. 10 лет назад в Mandrake не имея никакого опыта я запросто компилировал драйвер к модему (configure && make && make install). Попробуйте это сделать сейчас, и вам придётся обновить полсистемы, но результата не будет, будет "процесс завершён с ошибкой 2, symbol *** не установлен". А оно мне надо, тащить в систему gtk3 и прочие "прелести"?
-
это конечно не мое дело, но сеть компов есть не у всех, это хорошо для предприятий, вузов и т.д
А я флешочник, очень удобно пользоваться системой на любом компе, не затронув систему на харде,
очень удобно использовать несколько систем как основные, так и для всяких тестов и извращений, только rw сохранека на харде
имеем безопасность не повредить что то на харде, да и сам хард не заносиловать, можно быстро установить/удалить любую систему или программу, можно быстро подключить/отключать флешки с системами
Именно гибкая работа на флешках фругал системи и практически полный фкнкционал держит меня
Виндовс сейчас для меня это скайп, кантасимо(видеомоньаж), стим(бесплатных игр по больше и работает без сбоев)
все остальное на pra, опять же играю в игры, видеомоетаж(опеншот), скайп тоже, просто на моем компе уже микрофон не работает, стим на фругал еще требует жестких тестов, war thunder играю в портеусе
-
как реализовывать модульность/портативность на практике.
Чем не устраивает реализация в pra?
У портабельности есть плюс- не надо (или это просто и безопасно) переделывать модуль, но есть и минусы - по итогу в системе в /opt окажется несколько одинаковых либ разных версий
Так что оптимально все-таки не лениться и придерживаться хотя бы среза репы (извегать повторов либ). Иначе про "маленький и быстрый придется забыть". Быстрый - если Вы запустите 2 портированных приложения с разными версиями одной либы - в ram будет 2 копии этой либы
Загрузка по сети дома - оно Вам надо?
Скачали pra-конструктор (можно и его выложить распакованным) докачали нужного в /optional
Надо ли дома что-то еще?
Можно было бы загружаться из инета... но где тогда хранить сохраненку... Если есть хотя-бы флэшка - нужен этот сетевой гемор?
Надо ориентироваться на флэшку. Что и делаем. Это наиболее просто и универсально. Причем с copy2ram даже лучше sdd
До какой единицы можно/нужно дробить систему чтобы иметь возможность гибко подключать/отключать только то что необходимое
До больших функциональных модулей типа mesa qt gtk3 perl python
Создание маленького фругала из большого линукса - это поиск оптимальных приложений и оптимальный раскрой на модули
Если мельчить дальше - тогда просто юзать ПМ
systemd вообще - читайте в инете. Для маленького домашнего фругала - из пушки по воробъям. Кроме Х и сети в пупиподобном дистре запускать особо нечего. Останавливает отсутствие хорошей альтернативы. Дядя Шурик вселил надежду (http://forum.puppyrus.org/index.php/topic,16653.0.html), но там еще надо много работать и как бы цена отказа (частичная потеря совместимости с арчем) не оказалась слишком высока
-
на флешках лучше использовать уже настроенные окружения, например базовые и даже расширенные (с кучей софта для повседневного использования).
можно всегда скачивать такие окружения разово, если не получается работать по сети непрерывно.
прелесть в systemd я вижу лишь в уменьшении фрагментации между дистрибутивами.
что касается качества кода - то это уже вещь непрерывно изменяющаяся.
насчет зависимостей для сборки тех или иных программ - это результат снижения уровня образования у тех, кто пишет программы и тут даже не столько вина мантейнеров, сколько авторов программ.
в последнее время все чаще можно встретить когда ради одной строковой функции разработчики добавляют библиотеку, которая тянет за собой целую систему.
и одна из причин - большая фрагментация. systemd хоть чуточку эту фрагментацию уменьшает. можно ли ее уменьшить по другому? конечно можно! но получилось и получается это теперь у systemd и разработчики переходят на эту систему. много идей там красивых, реализация местами не очень, но большинство разработчиков все таки с этим соглашается.
systemd уже выросла далеко за систему инициалиации сервисов, теперь она вот вот будет системой контейнерного запуска приложений в изолированном пространстве. безусловно в этом случае приложения будут от нее зависеть почти полностью, если не совсем полностью, но разработчики с этим согласятся и будут развивать эту идею, как давно забытое старое в новом порождении.
-
С точки зрения стандартизации - лучше плохой стандарт (systemd), чем хороший разнобой (upstart system5 runit ...)
Но пупиподобные дистры - по замыслу нестандартны. Поэтому для достижения цели "маленький и быстрый" логичнее что-то более легкое. Динамика развития systemd все больше говорит за отказ в пупиподобных. Появляется все больше функций, которые и не нужны и не вырезать
-
Загрузка по сети дома мне удобна тем, что я в одном месте храню самую актуальную версию и могу ее загружать на разных машинах.
Я чаще всего загружаю дома linux системы в виртуальной машине. С флешкой возиться неудобно. Гораздо проще загружать систему по сети (у меня это кампусная городская сеть 100мбит и скорость загрузки по сети даже больше, чем с флешки), а данные подключать носителем (виртуальный диск, жесткий диск, флешка и тд). Можно в режиме copy2ram копировать избранные модули или всю систему - это если прям совсем хочется шустрости.
С uird все больше склоняюсь к реализации удаленной сетевой home, чтобы на работе и дома иметь всегда свое окружение. Пока в разработке гибкое универсальное решение, которое можно тиражировать, использую локальные носители. В принципе уже решение почти проработано, осталось только сетевые сервисы настроить под это и решить возможные проблемы, которые на практике возникнут.
-
Маленький и быстрый - это еще лет 5 только актуально.
Уже сейчас правильнее даже говорить: большой и быстрый :)))
Более того - если бы не желание некоторых обогащаться и наживаться, то сейчас уровень технологии был бы гораздо больше.
Сейчас общество потребляет технологии примерно на 7-10 лет из прошлого. Просто пока сливки не собрали на старом, новые технологии не пускают в общество. Поэтому современные технологии - это технологии реально устаревшие. На пике науки и разработок сейчас технологии настолько уже сказочны, что их реально обществу давать невыгодно. Потому что люди начнут использовать то, что не ломается, то что работает стабильно и десятилетиями и жить будет более счастливо. Это никому не надо, потому что общество тогда станет более свободным.
-
прелесть в systemd я вижу лишь в уменьшении фрагментации между дистрибутивами.
до сих пор Linux развивался по принципу естественнгог отбора, как в живой природе. Унифицировав все линуксы (как телевизоры УДПЦТ-61 в СССР) мы обречём их на вымирание.
что касается качества кода - то это уже вещь непрерывно изменяющаяся.
Ага, и как правило в худшую сторону.
systemd уже выросла далеко за систему инициалиации сервисов
Вот это и пугает
как давно забытое старое в новом порождении.
Отбрасывают и забывают ненужное и неудачное. Стоит ли "гальванизировать труп"?
-
кампусная городская сеть 100мбит - это очень частный случай. Универсальный - флэшка
Маленький и быстрый - это еще лет 5 только актуально.
Я был сказал - самопальная сборка уходит в прошлое, как в свое время пайка АОНов и цветомузык
Все уходит в продукты и сервисы
Новые технологии - на примере эволюции ms office 2000 - 2010 можно подумать и поспорить
-
Это никому не надо, потому что общество тогда станет более свободным.
Разве systemd делает кого-нибудь свободнее? По моему наоборот.
-
systemd уже выросла далеко за систему инициалиации сервисов
Вот это и пугает
Пугает именно это. Особенно с свете неделимости и описанного выше качества кода и авторитарности
-
забытое старое - как качественное и работающее, которое в век зарабатывания денег, как кость в горле.
systemd уменьшив фрагментацию приближает людей к свободе, потому что есть возможность сделать систему очень стабильной и отточенной.
но попытка "рубить деньги" будет неизбежно прельщать и поэтому на определенном этапе мы получим то, что сейчас происходит с ядром, где в каждом дистре какие-то примочки, где будут уже индивидуальные патчи для самого systemd.
При унификации стирается грань между дистрибутивами и коммерчески это становится невыгодным. Весь линукс основан на том, что деньги зарабатывают на поддержке, но поддержка станет настолько доступной и непривязанной к конкретной компании, что компании начнут терять доход, а значит платить разработчикам будет нечем и качество кода начнет падать.
Поэтому ниша тут только одна - разработка приложений и их продажа в виде сервиса - appstore, google market, и т.д. А операционная система будет бесплатной. Скорее всего microsoft вслед за apple тоже скоро сделает свою систему полностью бесплатной. Рынок меняется.
И если в Linux не уменьшат фрагментацию, то он проиграет эту гонку полностью.
Писать софт под фрагментированный линукс - это ад прибитый к конкретному DE. Уж лучше писать его к единственному и стабильно проработанному API той же винды или мака.
-
systemd уменьшив фрагментацию приближает людей к свободе
??? Это не свобода, а "наркозависимость"
И если в Linux не уменьшат фрагментацию, то он проиграет эту гонку полностью.
А если уменьшит - "сдуется" как FreeBSD.
-
Давайте вернёмся к теме.
Как должна использоваться система? Как телевизор, включил - работает, остаётся только переключать каналы. Что "под капотом" пользователю без разницы. Если вам нравится - молитесь своему божку systemd и его пророку Пёттерингу, но лично моё мнение - в frugal системах был, есть и будет скриптовый запуск, systemd не умеет создавать aufs, и вряд ли будет. Спорить будете?
-
Откуда инфа, что freebsd уменьшал и сдулся... Развивается в своем (не дектоп) направлении. И кстати systemd там нет и не планируется
systemd не умеет создавать aufs, и вряд ли будет. Спорить будете?
Недопонял - что значит "создавать"
Дядя Шурик - спорить без фактов бесполезно. Давайте добъем тему pra nosystemd
-
systemd уменьшив фрагментацию приближает людей к свободе
??? Это не свобода, а "наркозависимость"
И если в Linux не уменьшат фрагментацию, то он проиграет эту гонку полностью.
А если уменьшит - "сдуется" как FreeBSD.
смотрите мои пояснения после фраз, которые вы цитируете.
-
Как должна использоваться система? Как телевизор, включил - работает, остаётся только переключать каналы. Что "под капотом" пользователю без разницы.
именно! без разницы, главное - четкая безглючная работоспособность.
systemd не умеет создавать aufs, и вряд ли будет.
для создания фругал на aufs вполне подходит uird.
в systemd aufs скорее всего не будут использовать, там будут использовать overlayfs + снапшоты btrfs + cgroups. Это будет с лихвой покрывать потребность во фругал на aufs.
-
для создания фругал на aufs вполне подходит uird.
init - скрипт?
-
для создания фругал на aufs вполне подходит uird.
init - скрипт?
скрипт на bash.
-
init - скрипт?
скрипт на bash.
Во-от. Что и требовалось доказать. Для инициализации системы достаточно bash-скрипта. А Лёнчик со своим поделием своё начальство дурит и вас всех заодно. Лохотрон это однозначно.
-
Чего бы точно не хотелось так очередного файтинга на тему systemd OR not systemd (шекспир молодец)
Все же поскольку индивидуальность линукса - его неотъемлемая(исключительная) черта. Как этой штукой правильно пользоваться чтобы было комфортно всем?
Мое понимание системы: система может существовать только там где есть структура(централизованная или децентрализованная) и соблюдаются общие правила/договоренности(они такими должны по крайней мере стать). Желательно пользователям линукс собрать в особенности для фругала все то что объединяет, а не приводит к конфликту. Общим у разных программ[модулей] может быть только область применения(за редким исключением).
Может спорное решение но вопрос интерфейса(взаимодействие: машина-пользователь) у cups решен достаточно интересным способом.(не под все программы и секции системы подойтет но все же вариант). Какие еще могут быть варианты?
-
Ну я понимаю, что это тема на "просто поболтать", тем не менее, где мысли о "Вариантах использования..." :)?
Я использую Puppy, как основную систему. Мне наплевать на "религиозные войны", комфортную работу в этой системе для себя я создал 8). А все остальное - вне этой темы :)
-
Чего бы точно не хотелось так очередного файтинга на тему systemd OR not systemd (шекспир молодец)
Приходится :(. Беда не в самом systemd и даже не в его скандально известном авторе. Беда в том, что многие программы имеют systemd в зависимостях.
Желательно пользователям линукс собрать в особенности для фругала все то что объединяет, а не приводит к конфликту.
Модули от Slax, Richy, PRA, PR и MagOS теоретически подходят друг к другу, но на практике это довольно часто неосуществимо из-за различного набора библиотек, который нельзя сделать стандартным, ибо всё развивается и библиотеки не исключение. Круг замкнулся.
-
попытка из разговоров обо всем извлечь конструктив
Конкретный вопрос как реализовать например при загрузке/по ходу использования при вводе(консоль)/выборе(графика) работу определенных программ(выбранных пользователем по предпочтению) указывая лишь на тематическое применение (тоесть при указании email/почта - запускается индивидуальная программа[sylpheed/geary/mutt]. Как добиться этой индивидуальности и учесть сохранность пользовательских данных?
хотябы применительно к pra, richy. Уровень системы или уровень отдельных блоков модулей? Базы данных(sqlite) или списки(ini) не без скриптовой составляющей? или определенная структура конфигурационных файлов, самих модулей?
Макосовцы активно исользуют теги (правда только для файлового менеджера). От зависимостей никуда не деться и дополнительная запись в пакете много места не съест.
P.S. DdShurik вы пробовали сделать портированный модуль с помощь pacman2pfs? Насколько правильным может получится подход если доработать скриптовую часть?
-
Со временем все больше и больше будет зависеть от systemd и это после стагнации активной разработки приведет к стабилизации и вычищению ошибок.
В итоге всем будет проще. Ну это в случае коммерциализации будет эффективным способом вынуждать пользователей платить. Но это жадный капиталистический мир и с ним можно только сосуществовать и частично мириться.
-
Со временем все больше и больше будет зависеть от systemd
И это очень плохо, потому что там где начинается зависимость кончается свобода, а без свободы это уже не линукс.
P.S. DdShurik вы пробовали сделать портированный модуль с помощь pacman2pfs?
Не пробовал и не буду, это не мой метод.