Группа отечественных энтузиастов начала разработку, на основе Gentoo и Slackware (в варианте Slax), нового LiveCD/DVD дистрибутива - РОД Linux (http://www.rod-linux.org/main/). Главное что бросается в глаза, то что все скрипты установки и управления написаны на PHP. Планируется создать систему администрирования через web-интерфейс, подобную webmin.
Главная цель разработки - создание удобного средства разработки для людей использующих комплект Apache, PHP и MySQL.
Отдельно стоит сказать про организацию пакетов программ. Несмотря на наличие возможности установки из пакетов rpm и deb, пропагандируется подход компоновки окружения из самодостаточных модулей (в пакет помещается не только программа, но и все необходимые для работы библиотеки и компоненты), монтируемых посредством unionFS в единую виртуальную файловую систему.
URL: http://www.rod-linux.org/main/
Новость: http://www.opennet.me/opennews/art.shtml?num=7219
затея неплохая - можно обкатать некоторые идеи.
но имхо, пхп не подходит для cli-скриптов.хотя время покажет, что из этого получится - главное организовать комьюнити
Чем же? :)
Знаю perl, sh, С/С++ но в основном все скрипты под свои задачи пишу на php, удобно. Хотя кому как :)
Во-во, и я про тоже - гипертекстовый препроцессор для скриптов самое оно, соверуют лучшее профессионалы.
к сожалению ему пока не хватает скорости.
зенд оптимайзер не спасает.
я тоже когда-то думал, что пхп и как cli неплох, но практика показала обратное.
Я тоже некоторое время писал скрипты на php, пока не узнал про gawk. Теперь всю обработку текста пишу на нем.
А я бы вообще воспользовался питоном - как никак а он вобрал много хорошего как от перла так и от пхп. Гибкость, легкость проектировки и при этом довольно шустро бегает.
Вообще-то недавно начал ради интереса (насколько красиво получиться не знаю - чисто любопытно) создавать аналог SysVInit скриптов.
По поводу статики - имхо я против - как сказали выше - получиться вторая виста.
Perl и PHP - самое оно. И PHP даже лучше. И без всякого ООП.
http://www.m0n0.ch/wall/
Уря! Свалились на обсуждение грамматики! Обожаю я эту публику! Видимо грамматику проще обсуждать :)По теме: насчет ПХП в скриптах управления - наверное вполне удобно для знающих этот язык. Учитывая цель "создание удобного средства разработки для людей использующих комплект Apache, PHP и MySQL." выглядит вполне разумно. Упростит людям процесс "общения" с ОС.
>>Разработчики PHP продемонстрируют, что это зрелый скриптовый язык и он вышел из младенческого возраста – языка писания интернет-страничек.<< - http://www.rod-linux.org/main/Знаете, есть такая старая фраза: "Человек становится взрослым тогда, когда перестает этого хотеть". Когда же сторонники ПХП перестанут пытаться доказать всем и каждому, что ПХП "тоже язык программирования"?
Ответ на вопрос "Почему нельзя везде и всегда использовать PHP вместо Perl" можно найти на cpan.orgПочему нельзя компилять всё в статику и ставить вместе со всеми зависимостями? Это конечно всё замечательно для того-же apache, но значительно хуже для Х-овых приложений. Дистр ведь юзер-ориентированный, да? Ну тогда без Хов никуда.. Минимум браузер надо, чтобы сконфигурировать систему можно было :-)
Далее - если ориентироватся на Vista по подтреблению памяти - тогда зачем вообще что-то писать? Честно говоря страшно представить ЭТО работающим на 64 битной платформе.. Оно и на 32 весьма будет прожорливое в связи со статикой, а на 64... Ну я даже слов не знаю для описания такого потребления памяти....
Идею вернуть автору на доработку :-) Из разумного - только использование unionFS для подключения бинарных пакетов.
ну я думаю что дярявость ПХП вообще отпугивает всех, кто занет перл никогда не будет даже его равнять с ПХП язык для негоров
хочешь крутой уровень-интерпрайз и секрность то ява
это все знают
>ну я думаю что дярявость ПХП вообще отпугивает всех, кто занет перл
>никогда не будет даже его равнять с ПХП язык для негоров
>
>хочешь крутой уровень-интерпрайз и секрность то ява
>это все знаютКак можно сравнивать PHP и Perl? Perl - мощный, PHP - гибкий. Это как у одного - член длинный, а у другого - толстый. В свое время точно так же спорили относительно превосходств между Си и Паскалем.
init.d скрипты - это теперь энтерпрайз уровень? :)Скатываясь к священной войне...
Согласен, что ни один скриптовый язык не годиться для энтерпрайз уровня хотя бы по причине отсутствия контроля типов. Жаба - всё бы хорошо, если бы не производительность, которая в среднем раз в 20 ниже чем у нормально скомпилированного бинарника. Чтобы получить действительно "Энтерпрайз" уровень (именно так, с большой буквы) жабы недостаточно.Иными словами java sucks, C++ rulezz, freefly forever! :)
>Жаба - всё бы хорошо, если бы не производительность, которая в среднем раз в 20 ниже
>чем у нормально скомпилированного бинарника. Чтобы получить действительно "Энтерпрайз" уровень (именно
>так, с большой буквы) жабы недостаточно.
>
>Иными словами java sucks, C++ rulezz, freefly forever! :)
Сваяйте мне на C++ портал уровня novell.com а потом уже говорите про то что C++ рулез. Все хорошо там где должно.
Сайтик сделать - это что тоже энтерпрайз уровень?
Я говорил про портал. Порталы Oracle IBM Sun Novell работают на java. Или вы хотите сказать что порталы корпораций не энтерпрайз уровень? Просто я к тому что если вы попытаетесь сделать их на C++ с аналогичным функционалом вы очень серьезно обломаетесь.
Искренне считаю, что простая публикация информации не представляет особой сложности и естественно на с++ это делать неразумно. Я говорю о системах уровня крупных биллингов, способных обрабатывать миллион абонентов, которые если использовать джаву спасает только немерянное железо.
php отлично работает как скриптовый язык в связке с мускулом. довольно сложные вещи реализуются просто и красиво. а вот если мускул не нужен то и php в скриптах выглядит странно.активно юзаем php для этих целей эмоции только положительные
>яву ф топку!
я бы не был столь категоричным. Она не имеет кучи болезней которые есть у PHP. Назову парочку. Нет абстракции обращения к СУБД, нет нативной поддержки UTF-8. Про то что в PHP 6.x будет поддержка UTF-8 будет я знаю. Просто в java она уже есть, причем была там изначально.>по делу: php отлично работает как скриптовый язык в связке с мускулом.
А теперь попытайтесь заменить MySQL PostgreSQL или еще чем-нибудь. В java и perl я поменяю одну строку. В PHP мне прийдется перелопатить весь код касающийся работы с СУБД.>довольно сложные вещи реализуются просто и красиво.
А что для вас довольно сложно ?>а вот если мускул не нужен то и php в скриптах выглядит странно.
Видимо на MySQL сошелся белый свет? Другие СУБД не пробовали ?
ЭЭЭЭЭ, товарищъ!Про pear мы конечно-же ничего не слышали?
Ну и еще, если писать не задумываясь о будущем, тогда лучше вообще не писать. Кто думал - у того изначально прсолойка работы с БД была написана
>Про pear мы конечно-же ничего не слышали?
В стандартной поставке нет. Раз нет то и суда нет.>Ну и еще, если писать не задумываясь о будущем, тогда лучше вообще
>не писать. Кто думал - у того изначально прсолойка работы с
>БД была написана
Где на уровне движка? Это должно быть на уровне стандартных библиотек. И у java и у perl это есть. Только вот у php почему-то нет.
Это конечно хорошо да... свежо предание да верится с трудом.>Хочется видеть новоявленный дистрибутив, основанный на классических, очень Unix-подобных Slackware (в варианте Slax) и Gentoo, но при этом доступных обычному пользователю.
Видимо собрать Gentoo для пользователя гараздо сложнее и видимо он будет не доступен пользователю.>Кроме того, хочется надеяться, что в будущем, в нашей стране все-таки начнут делать достойную электронику, например процессоры для пользовательских машин. В этом случае им понадобится ПО, много ПО. Вот эту проблему и должен будет решить «РОД».
Изивините но вы делаете новый дистрибутив, а не новую ОС. А раз так то насчет того что РОД сможет решить эту проблему вы загнули. Т.к. ядро у вас стандартное и окружение стандартное. Меняется только система инициализации и скриптов.>В итоге мы, с одной стороны, получаем мощное средство администрирования, а с другой – удобную пользовательскую систему. Во всяком случае хочется это верить.
Вот мне что-то не верится.>Здесь же хочется коснуться выгод, явных или косвенных, которые получат все кто примет участие в проекте.
>1. Во-первых, разработчики кроме морального удовлетворения получат классическую наиболее Unix-подобную систему, глубоко модифицируемую, настраиваемую
Думаю gentoo в этом плане гараздо лучше чем выбранный вами slackware.>но более простую в установке и обслуживании
по сравнению с чем ?
>Все сторонники Apache, PHP и MySQL получат удобное средство разработки.
В чем это удобство проявляется ? И чем это не удобнее к примеру Gentoo с установленным apache php и MySQL?>Разработчики PHP продемонстрируют, что это зрелый скриптовый язык и он вышел из >младенческого возраста – языка писания интернет-страничек.
Позволю себе процитировать сайт php.net:"PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML"
Четко написано специально разработан для web'а. Так про какой младенческий возраст идет речь?
>Пользователи получат комплекс ПО, построенный по модульной технологии, где все: >установка, настройка и удаление программ, осуществляется посредством операций с модулями.
А что такое у вас модуль?>Дистрибутив будет содержать множество прикладного софта, планируется создать удобную эргономичную систему администрирования через web-интерфейс.
В результате чего мы получим большую дыру в безопасности.>Однако при этом останутся все преимущества UNIX'овости: надежность, стабильность, безопасность.
См. выше. Не зря в php 4.x и 5.x есть переменная safe mode.>Очевидно, что все будут рады читать русскоязычную документацию и файлы справки, не ломая голову над переводом.
Это конечно хорошо. Но для этого не обязательно создавать дистрибутив.>Толковая реализация работы с кодировками, избавит от удовольствия лицезреть кракозябры в примонтированных устройствах, тегах и документах.
Хм у меня в gentoo нет никаких проблем с кодировками. Кроме этого уже существует ALT Linux там и подавно нет проблем с кодировками. Проблема надумана.>Основной принцип дистрибутива – мощная система должна быть проста и дружественна кому бы то ни было, хоть разработчику-профи, хоть админу-линуксоиду, хоть пользователю-чайнику, который совершенно не в курсе, что есть Open Sourse, и причем здесь антилопы и пингвины.
Для пользователей существуют Desktop OS к примеру Windows, BeOS Zeta Haiku.>Классический UNIX-путь для настольных компов непригоден совершенно!
Именно по этому надо опутывать *nix костылями, а взять Desktop OS. Если вам хочется открытой ОС вам на haiku-os.org эта ос крайне элегантна и продумана.>А раз так, то нужно реализовать иной подход, свой взгляд на Linux для настольных машин.
Пользователю не нужен linux ему необходимо дружественное окружение. Именно это дают Desktop OS.>Несмотря на то, что этот путь многими декларируется, мало кем он проводится в жизнь, как комплексная политика. Надо это исправить.
Пока абсолютно непонятно как вы это собираетесь реализовывать.И так а теперь пройдусь по техзаданию. Первое что хочу заметить это "техзадание общее". Вы русский человек ? В русском языке это звучит как "общее техзадание" или даже "техническое задание". Я крайне слабо представляю что такое общее техзадание. А вот что такое техническое задание я представляю хорошо.
>Изначально это LiveCD/DVD, дабы при использовании сразу попадать в стандартную, для многих уже привычную, среду.
Что такое стандартная и привычная среда ?>PHP-скрипты, как базовая оболочка; убрать Perl, как базу.
И словить кучу не совместимости. В отличии от PHP Perl создавался как скриптовый язык автоматизации различных рутинных работ системного администратора.>Системные скрипты написанные на одном языке, а не бессистемно и в разнобой на нескольких, дадут системе красоту и стройность.
Только в том случае если это подробно документировано. Плюс обычно все системные скрипты пишутся на sh. Смешения perl с sh наблюдается крайне редко.>Зная PHP можно знать систему, управлять и тонко ее настраивать.
Знание PHP не означает знания работы системы инициализации и системных скриптов. Т.к. знание реализации задачи и знание языка на котором реализована задача это два не пересекающихся множества.>Кроме того, PHP занимает намного меньше места, чем Perl.
А это тут причем? Место сейчас вроде как не проблема.>Дистрибутив должен быть открытым, элементарным в обслуживании и настройке; простым и понятным.
Дистрибутив должен быть логичным и документированным. Хороший пример такого дистрибутива Gentoo.>Заранее настроенным, чтобы при первом запуске не было, мягко говоря, проблем с распознавание оборудования, его настройкой и плясками с бубном – live cd/dvd – воткнул и работает.
Вообще такой дистрибутив есть и называется он Knoppix.>Поддержка установки ПО на модулях-виртуальных дисках a-la Slax или GoblinX.
Не сильно хорошо и удобно.>Администрирование всей системы через локальный веб-сервер на PHP, MySQL и Apache: установка ПО, настройка системы, редактирование конфигурационных файлов, управление подключениями, политикой безопасности, работа с оборудованием.
Тогда для администрирования системы потребуется браузер. До этого было необходимо всего два средства shell и редактор. Кроме этого администрирование через web будет более ограничено чем администрирование при помощи shell и редактора. GUI всегда менее гибок чем CLI.>Для начала планируется переписать все скрипты Slax на PHP – и встроить PHP в базовый модуль Slax, чтобы PHP был изначально предустановлен, и все системные скрипты на PHP могли без проблем запускаться.
До этого для инициализации требовался только shell. Теперь кроме shell еще потребуется PHP. Вам известно что увеличение деталей в системе ведет к уменьшению ее стабильности?>Кроме того, есть несколько готовых стандартных скриптов которые позволяют брать любой пакет из мощного и старейшего дистрибутива Slackware (коих там тысячи) и стандартно, одним нажатием кнопки делать модуль Slax'а.
В slackware крайне мало пакетов и он не предназначен для корпоративной среды.>Кроме того, нужно сделать на русском развернутый комментарий к скриптам для создания и модификации модулей.
Не комментарий, а документацию.>Также имеется программа на Delphi под Windows (!), которая делает автоматически то же, что и эти стандартные скрипты для производства модулей, и любой желающий может делать модули для Slax из Slackware-CD и писать или дописывать их на CD-RW, прямо под виндами! Прикольно и удобно для всех форточников.
Интересно зачем дистрибутиву Linux привязка к Windows?>К сему богатству, осталось добавить аналогичную программу или скрипт по производству модулей из пакетов для Gentoo, deb-пакетов (или из кучи пакетов, поскольку пакеты как правило, каких-то еще зависимостей хотят), rpm же перегоняется в deb средствами Debian. Тогда о проблемах с недостатком софта можно будет забыть навсегда.
Мдя... Вы забываете что у Gentoo, Debian и rpm-дистрибутивов разные подходы, разные системы инициализации. В Gentoo все сделано правильно. Используется сборка из исходников. это позволяет установить пакет согласно подходу, не надо придумывать велосипед. Кроме этого вы забываете что многие пакеты имеют привязки к другим пакетам. Если начать ставить часть пакетов из Gentoo часть из Debian часть из RedHat в результате получится не работоспособная каша.>Модуль – это кусок файловой системы, куда можно устанавливать любое ПО – в том числе системное, и потом стандартно при загрузке, или просто при работе подключать и отключать эти модули с помощью средств unionfs!
Только не понятно зачем это надо. И собственно что будет если что-то накроется в системе инициализации подгрузки модулей через unionfs.>Почувствуйте кайф: сливаете с сайта модуль, как простой бинарный пакет, потом дописываете его на винчестер, и одним кликом подсоединяете к своей системе. И все – ПО уже установлено и работает в стандартной конфигурации или с выбором из нескольких предустановленных конф. А все дополнительные настройки можно сделать уже потом – сохранив новые конфиги на винчестер в отдельной директории, в отдельный опять-таки модуль.
emerge package
Удобней. Если использовать бинарные пакеты можно достичь того же удобства.
>Подумайте об удовольствии от общения с модулями, о простоте стандартного копирования модулей, об отсутствии установок и дефолтных наладок – подключил и готово – одной кнопкой! Это ли не кайф?!
emerge крайне удобен. Да и собственно любой менеджер пакетов. Это придумано уже давно.
>И вот тут перед нами во весь рост встает проблема! Проблема зависимостей.
>Что здесь можно предложить? Есть такое решение:
>СТАТИКА!!!
Это решение НЕ ВЕРНО.>Да вы в себя от удивления придти не можете. Ну что ж привыкайте, за этим направлением будущее.
Ага я просто офигел. Вы пророк ?>Пора всему миру в конце концов закончить экономить на дисковом пространстве и оперативной памяти – поскольку эта фигова экономия тянется еще с тех времен, когда у всех было по 32 Мб рама и 5 Гб диска, а то и вовсе со времени ламповых вычислителей.
Много памяти не бывает. Запомните это золотое правило.>Народ по инерции экономит – это уже всех достало. Нахрена эта экономия, когда везде винты по 80-160 гигов – норма, а рама по 512 Мб – 1 гигу уже везде стандарт.
Не везде.>Мы утверждаем, что время пришло – массовая конфигурация железа в настоящее время достигла такого уровня, что позволит нам и всему миру работать по-новому – по-человечески.
Использование статического связывания это работа по человечески?!>Хватит тратить время на зависимости и на установку ПО!
Хе-хе. Динамическая линковка жрет процессорное время и некоторое количество памяти. Да если запускать один процесс динамическая ликовка проиграет. Но при этом она позволяет экономить память при большом количестве однотипных программ использующих динамическую линковку. К примеру возьмем OpenOffice. Программа объемная, но львиную долю этого объема жрут библиотеки. Которые при запуске второй копии OpenOffice, не загружаются в память. В результате загрузка второй копии увеличивает занимаемый объем памяти не в два раза а к примеру процентов на 10. Столько занимает исполняемый файл OpenOffice без библиотек. Вы же предлагаете ликвидировать это приемущество, т.к. считаете что у вас много памяти. Я думаю через некоторое время вы поймете как ошибались.>Статику надо в любом случае делать, потому как это поле не паханное, и никому в голову не приходит такая странная для текущего сознания мысль.
Это пройденный этап. Она была в старых системах. Т.к. памяти мало не бывает придумали динамическую линковку.>Статическая компиляция – само по себе тоже понятие непростое. Ведь можно тупо статически прикомпилить всю библиотеку размером 30 метров к маленькой программке в два килобайта, а можно умно прикомпилить статически только строго используемые программой функции, а все остальное не трогать.
Мечтать не вредно. Но если мне не изменяет память линковка просто добавляет библиотеку к программе. Далее чтобы уменьшить размеры можно использовать strip. Но и это не даст большой выгоды.>Это зависит только от качества библиотек – чтобы они это позволяли, и качества компилятора – чтобы он умел это делать. Тут придется разбираться. Под это дело нужны волонтеры.
Мартышкин труд, динамическая линковка гараздо выгоднее.>Ну, а все что не влезет в статику, например, таковым может оказаться KDE, можно разбивать >на подпакеты статические, из которых они реально состоят, и компилировать в статику >частями. Это может оказаться выходом. В любом случае, надо пробовать.
Попробовать вы можете, но вам может не хватить памяти для запуска KDE.>Если и этот путь не пройдет для объемного ПО, то нужно делать эдакие самодостаточные модули с динамической компиляцией, состоящие из нескольких связанных ПО, которые ВСЕ ВМЕСТЕ размещены в одном модуле со всеми своими зависимостями, и впихнутыми в них заранее всеми библиотеками. Чтоб они не лезли наружу и не просили еще какой модуль или библиотеку.
В результате чего обновление дистрибутива станет кошмаром для разработчиков.
>Перспективы от нового модульного стиля работы – захватывающие. Статически скомпилированная модульность БЕЗ ЗАВИСИМОСТЕЙ! На каждом модуле будет либо одно ПО, либо группа ПО, связанная зависимостями или просто рабочей задачей. Но при этом модуль сам по себе, он не тянет свои жадные руки требуя каких-то там библиотек или других модулей.
Каждый модуль жрет дофига памяти.>Модульная система – это прорыв, это кайф. Проникнитесь.
Gentoo это метадистрибутив. Он уже позволяет делать это.
>Можно модули делать на лету, шифровать их в реальном времени на уровне файловой системы. >Более того, можно делать шифрованные на лету модули без ПО – просто как место для текущей >работы человека, а потом при конце работы – на флэшку скинул ОДИН ФАЙЛ МОДУЛЯ и был таков.
Использование раздела /home вынесенного на флешку дает тот же результат но с гараздо меньшими усилиями.>И еще более потрясающий прогноз. Представьте себе: засовываем в модуль все, что связано с отдельным пользователем в системе: начиная с индивидуальных настроек, меню, почтовых ящиков, записной книжки, списка дел, и заканчивая обоями рабочего стола и хранителем экрана.
Все эти настройки давно хранятся в домашнем каталоге пользователя. Может проще использовать его ?>А то! Натворил чего-то там пользователь, и ушел продолжать работу на своем домашнем компе, выдернув флешку со всей дневной работой. Это ли не удовольствие. Мобильность как-никак.
носимая директория home дает это без вашего дистрибутива.>Сейчас время уже пришло! Уровень развития массового железа позволит сделать это легко и в массовом порядке!
Именно по этому многие используют удаленные терминалы. Это удобнее и проще.>Модуль со всеми зависимостями статически скомпилированный будет больше! Насколько в среднем, трудно сказать, но иногда серьезно больше, чем просто модуль с зависимостями. Для такого модуля будет больше места занято на диске и в памяти, возможно он будет дольше запускаться.
Запускаться статически скомпилированный модуль будет быстрее. Т.к. не требуется выполнять динамическое связывание.>Но в замен мы получаем большее быстродействие на 10-15% в работе такого модуля в среднем – это доказано большой статистикой по статике против динамики.
И черезвычайно сильную прожорливость ПО к памяти. 10 запущенных Firefox может заставить систему использовать своп. Что очень сильно скажется на быстродействии.>Плюс полное отсутствие потерь времени, нервов и сил на зависимости, непонятные настройки и битие в бубен.
Поставьте windows.>Жертва – лучшая конфигурации компа с чуть большим диском и рамом – мелочь по сравнению с удовольствием простой и легкой жизни, где не тратится самое важное и дорогое – ВРЕМЯ, а также нервные клетки, которые как известно не восстанавливаются :).
Вы не один из разработчик MS ? А то ваши лозунги очень похожи на лозунги Windows Vista.>К тому же железо бурно развивается, и то, что сегодня кажется hi-end'ом, завтра будет общераспространенной конфигурацией, а после завтра устареет. Все наверняка помнят, что не безызвестный Билли, как-то очень давно сказал, что компу вряд ли когда-то понадобится более 32 КИЛОбайт рама. Так послушаем же одного из лучших маркетологов ;).
у меня кошелек не резиновый. Да и потом билли сказал про 64кб памяти а не про 32кб. Почему 64кб ? Это вам надо матчасть почитать.>Кроме того, можно компилировать статику с оптимизацией к процессору Intel и AMD по отдельности. Ведь известно, что компиляция не gcc, а pgcc – дает оптимизацию кода и заточку под процессор Intel, в результате чего скорость выполнения выше на 10 и более процентов.
Что уже давно есть в Gentoo.>Сейчас остается понять, насколько нынешнего стандартного железа хватит под большинство самых важных пакетов – это только методом пробы с реальными приложениями.
Я считаю вам прежде чем браться за это дело стоит предварительно основательно подучиться.
>Представьте себе Linux дистрибутив с модулями любого прикладного ПО, которые свободно под/отключаются при работе системы, где есть полное управление через админ-веб-интерфейс, с полной документацией на родном языке! Причем даже устройства и вся внутренность дистрибутива управляются через веб-интерфейс, через системный веб-сервер!
Бред это.
>Webmin же тяжеловесен, в нем много лишнего, всякой воды, и не полноценный он: сам с пакетами работать не может.
CLI является наиболее полноценой средой администрирования *nix систем.>Хотелось бы создать нечто более свежее по структуре и внешнему виду. В webmin'е можно подглядеть, как решать некоторые проблемы, а потом писать все на PHP и XML. Создать что-то эдакое в стиле киберпанк, футуристическое и в то же время дружественное человеку.
Это будет точно что-то эдакое. Но дружественным оно будет только вам.>Зачем? Да чтоб всей системой можно было рулить из единого центра, а не ломиться по папкам в поисках config'ов и log'ов.
Прочитайте FHS. И запомните что любая нормальная *nix система придерживается их в той или иной степени.>Чтобы система была полной и полноценной, чтобы существовала возможность управляться удаленно.
Сейчас видимо дистрибутивы Linux не полны и не полноцены. Для удаленного управления есть ssh. Дешево, сердито и удобно.
>Выглядеть для пользователя это будет примерно следующим образом: сразу при загрузке системы, грузятся Apache, MySQL и PHP, затем X.org со всеми современными красивостями, полупрозрачностями и прочими наворотами, потом просыпается FireFox и грузит страничку локального сайта web-админ-сервера на PHP и XML. Со страницы помощи и документации летим на страницу системного веб-админ-интерфейса (через логин-пароль) для ПОЛНОГО управления машиной. Остается только залогиниться под root'ом и разруливать системой. НАСЛАЖДАТЬСЯ одним словом :))!
Работать будем тоже под root ? По вашим словам видимо да. Плюс если системе не удасться загрузить Apache MySQL и PHP пользователь будет лишен возможности управлять системой. Очень радостная перспектива.>ВОТ ТАКАЯ БОТВА, НАРОД.
Вот и заметно что ботва.>ОДНИМ СЛОВОМ, МИЛОСТИ ПРОСИМ.
А травой поделитесь?
>>К тому же железо бурно развивается, и то, что сегодня кажется hi-end'ом, завтра будет
>>общераспространенной конфигурацией, а после завтра устареет. Все наверняка помнят, что не
>>безызвестный Билли, как-то очень давно сказал, что компу вряд ли когда-то понадобится более
>>32 КИЛОбайт рама. Так послушаем же одного из лучших маркетологов ;).>у меня кошелек не резиновый. Да и потом билли сказал про 64кб памяти а не про 32кб. Почему >64кб ? Это вам надо матчасть почитать.
Читать обоим... 640кб. И вообще, он от этого открещивается... :)
http://en.wikiquote.org/wiki/Bill_GatesWrongly Attributed
"640K ought to be enough for anybody." and "No one will need more than 637 kb of memory for a personal computer."
* Two variants of the same quote. Attributed to him in 1981 when designing DOS's conventional memory limit as ten times the amount in his computer; Gates has denied this quote and mentions that it is always provided without a source. The quote sounds reasonable today, when Gates has so much control over the (personal) computing world, but he was hardly significant enough at the time to influence such issues. In fact, the memory limitation was hardware based: The intel 8086 processor imposed a 1MB memory limit. The 640KB limit came from the inflexible hardware architechture of the early IBM PC.
>Читать обоим... 640кб. И вообще, он от этого открещивается... :)
ну вот я тоже сомневался %)
Я думаю, те кто почитал тексты на сайте - сразу всё понял, и об уровне автора (как техническом так и человеческом), так и о самой этой идее.Комментарии просто излишни.
использование php как основного скриптового языка в этом проекте не самая "интересная" вещь, я не поленился и почитал про так называемые "модули" и мне откровенно стало смешно. автор утверждает что эконмия на размере дистрибутива это следствие исторических ограничений в размере дискового пространства и оперативной памяти, однако ни слова нет о цене этого самого размера, который выливается в трафик. идем дальше -"нужно делать эдакие самодостаточные модули с динамической компиляцией, состоящие из нескольких связанных ПО, которые ВСЕ ВМЕСТЕ размещены в одном модуле со всеми своими зависимостями, и впихнутыми в них заранее всеми библиотеками. Чтоб они не лезли наружу и не просили еще какой модуль или библиотеку"
- ну, тут без комментариев, тут просто занавес,антракт.после таких заявлений разработчики free bsd начнут поставлять последующие релизы со ВСЕМИ портами. и кстати, лексикон действительно напоминает журнал "][акер", но это тока ИМХО :)
nu a ruby?
Да сколько же можно плодить этих дистрибутивов?! Главное зачем?! Есть ли в нём потребность? Сколько он проживёт? Пока разработчику не надоест?"Основной задачей создания дистрибутива «РОД» на ядре Linux является создание удобной свободной системы"
Уж сколько этих удобных свободных систем создано..."с максимальной поддержкой кириллических кодировок"
Что имеется ввиду? Кириллические символы в консоли или в X? Первое не особо требуется, со вторым вроде бы и так всё хорошо."использование PHP-скриптов, как основных системных скриптов (!)"
Может кому-то оно и удобно, но я себе это не представляю. Так же, как не представляю системные скрипты на java."управление через локальный web-админ-сервер"
Зачем?! Аналог консолей windows что ли?"Одной из полноценно поддерживаемых аппаратных платформ будут процессоры выпускаемые/проектируемые в России, если они будут созданы и окажутся способными работать в настольных машинах."
:)"Кроме того, система должна получиться удобной, как для совершенно неопытных пользователей, так и для админов."
На мой взгляд до конца идея реализована быть не может. Да и слова эти я где-то уже читал."Как в таком случае быть с найденными багами в недавно установленном софте? Очевидно нужна система автоматического обновления до версии, в которой найденные баги закрыты. Сейчас трудно сказать, как конкретно это будет реализовано, но это будет сделано – несомненно."
Я создам крутую систему, но пока не знаю когда и как."Однако статически скомпилированная MySQL заставляет забыть о других СУБД?"
Мне для работы Oracle нужен :)"начнем разрабатывать и тестировать интеллектуальную систему установки из исходников, которую можно будет обучать"
Не дай бог! Дистрибутив живущий своей жизнью??Смеялся до слёз, когда читал http://www.rod-linux.org/main/razrabot.htm
В общем мне нехотелось бы увидеть такой "новоявленный дистрибутив, основанный на классических, очень Unix-подобных Slackware (в варианте Slax) и Gentoo". ВОТ ТАКАЯ БОТВА, НАРОД.
Идея интересная, но по моему автор не понимает что при статической компиляции даже даже гига памяти может не хватить для полноценной работы.
лучшие традиции UNIX как раз и подразумевают разделение всего и вся,
идея насчет модульного подключения большого колличества "микро файловых систем" и из этого строить систему тоже неплохо, но как будет тормозить такая файловая система, кажется еще никто не понимает.
насчет современного оборудования и увеличения его вычислительных рессурсов, скажу одно: ИХ НИКОГДА НЕ ХВАТАЕТ.
И вообще, тенденция, когда на операционная система расходут большую часть рессурсов машины- не приведет никчему хорошему не приведет.
З.Ы. причем здесь PHP и почему именно он я так и не понял.
> причем здесь PHP и почему именно он я так и не
нуу...просто другого ничего не знаюти вообще подобные системы и подходы люди делают исключительно по незнанию и слепоте...
охото сделать что-то полезное, присоеденитесь к уже существующим проектам, наберитесь опыта... а там (лет через 10, как утверждал один из великих, по поводу времени необходимого для обучения программиста :) глядиш и придумается чего-то новое и полезное...