Каковы проблемы FreeBSD и пути их решения? Часть 2: анализ и опрос
Продолжение предыдущего поста, рекомендуется прочитать из него хотя бы введение.
...Таким образом, имеется два утверждения (подробно рассматриваемые далее), причем оба истинные и друг другу не противоречат (по второму вопросу - высказывайте в комментах ваши взгляды на то, каковы еще проблемы FreeBSD и как их можно решить.):
Часть I. Конкретно в ( Read more... )
...Таким образом, имеется два утверждения (подробно рассматриваемые далее), причем оба истинные и друг другу не противоречат (по второму вопросу - высказывайте в комментах ваши взгляды на то, каковы еще проблемы FreeBSD и как их можно решить.):
Часть I. Конкретно в ( Read more... )
Comments 249
Или помочь народу из Debian/kFreeBSD. Задачи аналогичные, большая часть работы уже сделана, вопрос лишь в смене привычек.
И да, у тебя пропущена тема мета-пакетов, которые сразу ставят нужный тебе набор софта под задачу(что приводит к единообразию и есть великое благо при большом парке серверов).
Про телекомы: сейчас есть тенденция миграции со всяких коммерческих unix на linux.
Reply
какой смысл говорить о существующем?
Reply
это должно быть штатно.
имхо, лучшая на данный момент реализация идеи портов в gentoo.
разьве что кофе не готовит.
Reply
мета-пакет тривиальным образом собирается из мета-порта посредством совершенно штатного make package
Reply
Reply
- Ребята, у нас есть проблема X, давайте её решать, мне кажется, Y будет шагом в нужном направлении, что думаете? Кстати, нам еще надо подумать и насчет Z.
- Да вы дебилы, у вас же сейчас X, никакого Z не получится!!!
Здесь принимаются конструктивные предложения, для чего надо иметь некоторую лояльность к FreeBSD и быть готовым потратить свое время на помощь ей, а стало быть, и на внимательное чтение/размышление над постом. Если этого нет, конструктив будет разве что случайно и небольшим, вот как здесь. В дальнейшем всё подобное будет, разумеется, тереться.
Reply
Reply
Reply
Например начало про упадок сообщества и прочее, пожалуй не соглашусь и вот почему. Тут логичнее бы было разделить проблему на:
1. угасание русскоязычного сообщества, которое стало весьма мощьным в 90-е начале 00-х, а сейчас всё быстрее пропадает
2. вполне нормальное хотя и не взрывоподобный рост и прогресс, сообщества англоязычного, а в последнее время и новых, та же бразилия, сейчас вот у арабов нашелся весьма активный лидер.
По проблеме того как развивать базовую систему, сейчас особо ничего не скажу, да и тема думаю слишком широкая для одного поста, те же пакеты как я понимаю, очень многие хотят переделать, причём начиная с их зарождения :) и вот вроде в этом году осенью собираются это плотно обсудить и судя по вики уже ведется исследовательский проект.
Reply
Reply
> Вопросы по модульности охватывают не только систему портов. Взять пример, что firefox - не запускается без модуля sem (POSIX семофоры), кидает bad system call. Админ на то и админ, чтобы подправить, но это ж firefox - это уже десктоп. Этим вопросы к ядру не исчерпываются. Тем не менее пересборка ядра ведется и в монолитной основе, и с раскладкой по модулям. [...] Тут бы не помешал вывод на консоль "приложение X хочет доступ к Y которое реализано в модуле Z. Сам не могу подгрузить, поэтому по человечески прошу - сделайте это для меня".Это похоже на требование зависимостей пакетов по опциям сборки, но от базовой системы, только что к этому механизму добавить автоматическую подгрузку зависимостей, разве что. Стоит учесть, ага. Про вывод на консоль - тогда уж, скорее, при установке, такая информация только в пакетах и может быть записана, кто что ( ... )
Reply
Системные вызовы записаны под номерами, и если на данный момент стоит заглушка, можно кидать сигнал совместно с однократным записью в лог файл - приложение не должно знать, должно знать ядро, что у него где, и какой модуль не подгружен.
Требования противоречивы. Пересборка всего и вся сейчас как раз из-за того, что в имя порта в зависимостях жестко включена версия. Как раз об уходе от этого в посте и ведется речь.
Противоречия уберутся, если увидеть, что "ревизия" != "версия" порта. Как сделать лучше, трудно сказать, но предположительно: если речь идет представления порта как "[portname]-[major].[minor].[little]_[revision]", то "_[revision]" по ряду широко используемых портов (не по всем), можно было бы вынести в название порта, как это делается для [major] + [minor] веток некоторых проектов (упоминаемый недавно python - к примеру).
Reply
Привязка к номеру syscall - жуткий костыль. Гораздо вменяемее записывать в пакет требование такой-то FEATURE(), а уж какой там за эту фичу отвечает модуль и разрешил ли админ автоподгрузку модулей - дело базовой системы.
> то "_[revision]" по ряду широко используемых портов
Вот это точно вносить в имя не надо. Скорее, нужно средство для указания админом политики типа "оставаться вот на этой ветке порта" - внесение [major] + [minor] как в python в имя здесь может быть хорошим подспорьем, но тоже не должно навязываться.
Reply
Reply
Вот это и плохо. Про это и писалось в посте. Это и есть те самые проблемы с комьюнити, которые имеют место быть. Только важнее во всём этом - то, что надо-то чего-то делать. Надо с какими-то уже конструктивными предложениями в arch@ идти, а не просто так, "у нас есть проблемы". Над ними, решениями я и приглашал здесь всех подумать.
> если бы меня спросили в каком месте фрю доделать нужно -- я бы сказал VFS
Оно явно относится к тем 20% проблем, которые потребуют 80% усилий, а дадут только 20% выигрыша для системы. Нужно, но не приоритетно.
Reply
Leave a comment