| Привет |
| Мини-чат |
Вы должны быть авторизованы, для того чтобы оставлять комментарии на сайте. Пожалуйста, авторизируйтесь или зарегистрируйтесь на сайте. @Wanderer:Верно.Но в тоже время останавливаться на позициях критика не желаю.Есть уже рабочие намётки(можно по телнету пощупать) для всей этой истории,правда Буратино пока ещё носом не дорос,чтобы презентовать широкой публике.
Зато осталась главная мысль, которую нужно распечатать и повесить на самом видном месте: "Если хотите достичь успеха, меньше говорите и больше делайте". Вкратце, будьте немыми трудоголиками.
@exelents:от проекта остался весь этот веб.Только и всего.Пока так.Кто молится на линукс,кто на винду.Понимая всю безисходность,вся аудитория удалилась.К сожалению не вижу креатива в переработке POSIXґа!Вообще никто не замечает...Нафик ядро нужно,если подсистема над ним отсутствует?!На мой взгляд надо концентрироваться на новом возможном стандарте,и даже в переработке языка C/C++,если так охота можно всё назвать уже D...То что есть - сказал бы... - желаю себе лучшего!
По всем внешним признакам этот проект успешно загнулся.
Ни тебе описание процесса, ни новых версий.. Загублено.. Есть кто-нибуть из Саратова/Энгельса?
|
| Операционная система 3OS -> Форумы -> Идеология проекта | |||
|
|||
 Критики немногоПерейти к странице Предыдущая -1-2-3 Следующая |
| Автор | Отправлено |
| Аноним |
|
||
|
Гость |
В данном случае машают две проблеммы первая это совместимость с форматами а второе открытость стандарта. есди doc закрытый формат то нгикакими ухищрениями его коррктно не откроешь. И тут не надо приспосабливаться -микрософт еще больше при плющит наших введя еще одну фичу в формате и еще и еще... Надо заранее составить список стандартных форматов. и вместо doc юзать xml. если формат закрытый - послать его ибо поддерживая его мы тем самым поддерживаем M$. Легче сделать редактор для xml и портировать под окна стандартные библиотеки но сделать их тормозными немного а то под окна все добро перейдет |
||
| Наверх |
|
| Irish |
|
||
 
Сообщений - 29 |
Аноним194.85.82.254 писал(а): ... В данном случае машают две проблеммы первая это совместимость с форматами а второе открытость стандарта. есди doc закрытый формат то нгикакими ухищрениями его коррктно не откроешь. И тут не надо приспосабливаться -микрософт еще больше при плющит наших введя еще одну фичу в формате и еще и еще... Надо заранее составить список стандартных форматов. и вместо doc юзать xml. если формат закрытый - послать его ибо поддерживая его мы тем самым поддерживаем M$. Легче сделать редактор для xml и портировать под окна стандартные библиотеки но сделать их тормозными немного а то под окна все добро перейдет При таком раскладе может получиться "И эта маленькая , но гордая птичка..." От тогоже самого .doc невозможно уйти, слишком Windows проникла в нашу жизнь... |
||
| Наверх |
|
| ps |
|
||
 
Местоположение: Россия, Санкт-Петербург, дома :)) Сообщений - 40 |
сделать поддержку doc на уровне возможностей OO | ||
| Наверх |
|
| Roman I Khimov |
|
||
 Местоположение: Россия, Санкт-Петербург Сообщений - 178 |
Конвертировать все не придется. Можно временно представить файл в виде объекта, то есть физически ты будешь работать с файлом, но приложение будет видеть объект.
Греби и улыбайся!
|
||
| Наверх |
|
| Wowik |
|
||
Сообщений - 2 |
Если я все правильно понял идея не плоха, но на ее пути граблей накидано не мало. Даже если не вдаваться в "методы работы" и рассмотреть примитивнейший класс файлов - картинки : в различных форматах хранится различная доп.информация - с этим что делать? Далее сушествует растровый и векторный вид и многое другое. Не надо думать что форматы файлов появлялись от того, что людям нечего было делать - просто под некоторые нужды имеющихся форматов нехватало. Если же пытаться как то динамически наращивать параметры обьектов появится куча проблем. Например работа с обьектом картинка в растровом и вектроном виде - не всегда можно применить одну и ту же операцию ко обоим типам изображения и что тогда делать? И это не единственный пример есть еще базы данных, 3d модели, чертежи, звуки, видео - и всех их под одну гребенку не загонишь. Интересно представить себе одни и те же методы для работы с флэш мултиком и авишкой например и так перечислять можно долго. | ||
| Наверх |
|
| Davy |
|
||
|
Сообщений - 4 |
Roman I Khimov писал(а): ... Конвертировать все не придется. Можно временно представить файл в виде объекта, то есть физически ты будешь работать с файлом, но приложение будет видеть объект. Итак, насколько я вас понял, вы предлагаете все необходимые атрибуты хранить в виде полей объекта. Т.е., если, например, существует GIF-формат изображения, то все его характеристики както: разрешение, размер и прочее хранить именно в полях. Главное тут - разрешение и подобные атрибуты. Тут возникает несколько вопросов. Во-первых. Если заострить внимание именно на разрешении и прочих подобных атрибутах файлов (типа id3 тэгов), то при копировании в другие файловые системы эти атрибуты придется вновь компоновать из объекта в файл. А ведь атрибутов может быть очень много. Во-вторых. С другой стороны. Если импортировать атрибуты файлов в поля объектов, то другие ОС, которые, возможно, будут ради совместимости поддерживать 3ОС-файл.сисетму, не смогут обращаться к объекту, как к потоку данных в родном формате файла (тот же GIF). Поэтому поддержка объектной ФС со стороны других ОС будет серьезно усложнена. В таком случае, возможно, стоить оставить концепцию "всё суть - объекты", но не так обширно. Например, как в Мастдае (да простят меня все за сие упоминание). Ведь там тоже такая концепция. |
||
| Наверх |
|
| Freeman |
|
||
 
Местоположение: Зеленоград, Россия Сообщений - 74 |
Davy писал(а): ... Во-первых. Если заострить внимание именно на разрешении и прочих подобных атрибутах файлов (типа id3 тэгов), то при копировании в другие файловые системы эти атрибуты придется вновь компоновать из объекта в файл. А ведь атрибутов может быть очень много. Во-вторых. С другой стороны. Если импортировать атрибуты файлов в поля объектов, то другие ОС, которые, возможно, будут ради совместимости поддерживать 3ОС-файл.сисетму, не смогут обращаться к объекту, как к потоку данных в родном формате файла (тот же GIF). Поэтому поддержка объектной ФС со стороны других ОС будет серьезно усложнена. Блин, ну неужели так трудно отрешиться от традиционной концепции? У нас не будет понятия файла вообще. В понятиях 3ОС нельзя говорить, что файл - это файл, а объект - это объект. Никакого копирования атрибутов не будет. Вообще, копирование чего-либо с целью дублирования - потенциальная дырка в системе. Из-за различных сбоев описатели могут рассогласоваться с тем, что они описывают. У меня сейчас нет времени протестировать Longhorn. Было бы очень интересно. Кажется, Майкрософт пошла путем, который мы забраковали еще полтора года назад. Хотят использовать XML-описатели, прикрепленные к обычным файлам в новой версии NTFS. ИМХО, так делать нельзя, причины были изложены выше. В 3ОС будет все сделано по-другому. Имеется три основополагающие концепции: - единое пространство данных (все потенциальные источники данных объединяются в единой строго типизированной среде) - единая среда (в ОО-интерпретации нет понятия программ и библиотек - они представляют собой классы и выступают в роли плагинов к операционной системе) - существующие данные и форматы данных (в том числе форматы разделов существующих операционных систем) остаются неизменными и должны по-прежнему быть доступны из них безо всяких преобразований Поэтому не надо воспринимать поддержку тех или иных форматов данных как прерогативу внешних программ. Если можно так выразиться, в 3ОС библиотеки поддержки форматов данных будут доступны на уровне файловой системы. Следовательно, если потребуется получить данные из объекта GIF, они будут прочитаны не из описателя, а непосредственно из "области данных файла GIF". Нечто подобное сейчас делает Windows Shell, однако в ней эта возможность является опциональной или даже просто "приятной фичей". В 3ОС же это будет не только штатная возможность системы, но краегольный камень реализации всей среды. |
||
| Наверх |
|
| HandleX |
|
||
|
Сообщений - 18 |
Вот тут я смотрю, Davy недоумевает по поводу того, как это — ОО файловая система и рисунок GIF могут совместно сосуществовать  "Вражеский" GIF реально на самом низком уровне будет, скорее всего, обычным BLOB. А объект "изображение GIF" появится только после того, как в системе будет зарегистрирован некий объектный "браузер" формата GIF. Именно он будет предоставлять программам поля и методы для работы с логикой GIF. Никто не говорит, что будут обратные преобразования туда-сюда. "Вражеский" GIF останется GIF'ом в двоичном своём представлении до самой своей смерти поэтому никаких проблем с экспортом "наружу" быть не должно. Можете тогда спросить: а в чём же отличие? А в том, что если объектный репозиторий централизован, то программеру не надо ломать голову "где мне взять библиотеки для работы с GIF", поскольку в системе уже всё есть! Или, к примеру, нужно трансформировать 1000 рисунков GIF по некоему закону (к примеру, подогнать их под один размер). Вот гемор-то в обычных системах! Это вам надо иметь графический программный пакет с элементами автоматизации... А тут пишете скриптик, запускаете его и пошли пить кофе... IMHO, выгода налицо. |
||
| Наверх |
|
| Davy |
|
||
|
Сообщений - 4 |
Ага... Т.е. для представления содержимого полей и методов объектов будут применяться некие плагины и кодеки... Вкусно. Но если плагины (кодеки) будут "висеть" на уровне пользователя, просто дополняя ФС, то это уже не будет прерогативой ФС, а просто надстройкой для поддержания уровня абстракции. Такую же хрень я могу устроить и поверх FAT. Но это будет, опять-таки, не фичей ФС, а, скорее, фичей ОС. А ведь я предлагаю обсудить не верхние слои реализации ФС, а те, которые будут ближе к физике устройств. В каком виде хранить данные? Что решить с правами доступа и вообще с общими атрибутами объектов? Не надо говорить, что там у каждого объекта будут некие поля "права доступа..." - и так ясно. Как эту шнягу ФИЗИЧЕСКИ разместить на винте? Или, может быть, использовать какую-нибудь уже существующую ФС? |
||
| Наверх |
|
| Freeman |
|
||
|
Местоположение: Зеленоград, Россия Сообщений - 74 |
Классно меня HandleX поддержал, спасибо. Идея понята правильно. Davy писал(а): ... Но это будет, опять-таки, не фичей ФС, а, скорее, фичей ОС. Да, иначе нет смысла разрабатывать собственную ОС. Davy писал(а): ... А ведь я предлагаю обсудить не верхние слои реализации ФС, а те, которые будут ближе к физике устройств. В каком виде хранить данные? Что решить с правами доступа и вообще с общими атрибутами объектов? А кто сказал, что у нас будет собственная ФС? Пока разговора вообще нет. Следовательно, если 3ОС будет работать на FAT, ни о каких правах доступа и речи не идет. На Ext2 - пожалуйста, но это будут абсолютно те же самые права, что и в Linux. Вопрос не в реализации собственной ФС пока, а в некоей стандартизации существующих, чтобы их возможности можно было представить в абстрактном слое. А 3ОС будет работать (и скорее всего, даже грузиться) с любых файловых систем (для которых мы сами или еще кто-то сподобится написать поддержку в виде драйверов-контейнеров). Кстати, на данный момент вопросы безопасности в 3ОС вообще не проработаны. Можете чем-то помочь конкретным? |
||
| Наверх |
|
| В онлайне |
| Гостей: 2, Пользователей: 0 ... Максимум онлайн: 23 (Пользователей: 0, Гостей: 23) зарегистировано 05.12.2005 | 03:31 Зарегистрированных пользователей: 319 Последний зарегистрированный пользователь: maxutov |
| © 3OS.Team 2002-2005 |