Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  19:19[Войти] | [Зарегистрироваться]
Обсуждение темы:
Русская ОС

Здравствуйте!

Хотелось бы знать, как народ отнесся бы к появлению проекта по созданию Руccкой ОС. Причём не только русской, но и всего русскоговорящего населения? Присоеденились бы вы к такому проекту?

Прошу не относить к флейму. Речь идёт о уже существующем проекте.

С уважением,

VICH

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 5452 сообщения



Отслеживать это обсуждение
<<<... | 2432—2423 | 2422—2413 | 2412—2403 | ...>>>
Всего сообщений в теме: 5452; страниц: 546; текущая страница: 304


№ 2422   29-08-2007 05:18 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2419« (Ка джа)
___________________________

Кажется еще немного и в документы начнут включать не просто структуру, но и механизм, ибо в ФС не хватает подходящего механизма.

Активные документы системы Oberon (Oberon System) включают не только структуру, но и механизм. Само слово "аплет" придумал Микаэль Франц. Ученик Вирта. Как он говорил, третий пользователь Oberon System (после Вирта и Гуткнехта).

В системе Oberon почти всё есть документ (подобно тому, как в системе Plan 9, созданной при активном участии авторов UNIX, файл стал практически всем).

В Sun, изучив в 1992-1994 гг. Oberon System, идею сильно извратили. Потому и аплеты мы во многом воспринимаем негативно и как атрибут исключительно веб-страниц. Только потом люди стали задумываться о том, что веб-документ и обычный документ не должны различаться. Что сам документ может быть вообще приложением. Что браузер -- это не только средство навигации по веб-страницам, а универсальный инструмент навигации по любым документам.

Но в системе Oberon это было изначально. В начале 1990-х годов. И это не скрывалось. Были книги. Была бесплатная система со всеми исходниками. И сделана была под DOS, Windows, MacOS и почти все Unix'ы. Был авторитет Вирта и ETH.

Но индустрия, прекрасно это зная, повела людей другим путем. Так, как было выгодно именно ей.


№ 2421   29-08-2007 05:05 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2413« (Руслан Богатырев)
___________________________
Усложнять — просто, упрощать — сложно (c)

Росе нужно иметь дивиз. Предлагаю следующий "Гвозди против шурупов"


№ 2420   29-08-2007 03:35 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2418«

Значит для Вас мейнстрим стал уже логичным? И "факторы" эти тоже? И сколько лет для этого понадобилось?

В компании где я работаю так и не услышал причины, по которым новый проект пишется на C++/Java, почему именно такое разделение по группам и языкам? почему именно эти языки? Где документ, в котором бы аргументировалось именно такое решение с обсуждением достоинств и недостатков других альтернатив.

Проект пишется с нуля, в нем участвуют десятки человек по всему миру. Так что свобода выбирать и разделять была.

Самый логичный "фактор", который мне привели, это то что некоторые менеджеры "знакомы" с C++, а некоторые с Java. Вот и поделили как знали. Просто боялись за своё ЕГО - как то нужно было бы работать с подчинёнными, которые чисто формально больше знают. А учить что то новое не хотели. Вот и весь логичный "фактор".

Другой пример Linux. Причина по которой выбрали его это: клиенты не хотят Windows, и есть корпоративная Linux, вот и все. А простой вопрос нафига ставить ОС общего назначения на applience, к которому ни у кого не будет доступа на прямую, я так и не получил ответа. Надеюсь что у клиента будет стоять другой корпоративный MiniLinux, но это тоже абсурд. И при всем при этом, эта супер надёжная система пару дней назад просто зависла на операции с Source Control. Поспрашивал народ, говорят что вообще для Linux это хоть и редкость, но постоянство. Т.е. все таки виснет она иногда. Причём разные версии, и не только эта корпоративная.

Вот вам и логика в принятии решений, влияющих на несколько лет в перед. Может и есть документы почему да как, но наверняка там будет что то типа "ну... C++ и Java и Linux - это ведь хорошо! ну вот и выбрали... вот и мучаемся... Вот..."


№ 2419   29-08-2007 03:17 Ответить на это сообщение Ответить на это сообщение с цитированием
Возможен ли вообще здоровый минимализм в отношении ФС? Ведь "сарай" получается немалый - структурированные документы в структурированной файловой системе... Одни механизмы... другие над первыми... или вместо первых... Кажется еще немного и в документы начнут включать не просто структуру, но и механизм, ибо в ФС не хватает подходящего механизма.


№ 2418   29-08-2007 02:53 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2402« (Руслан Богатырев)
___________________________

Паранойя сложности -- это наркотик. Который точно нащупала ИТ-индустрия и ловко этим пользуется. Ей это позволяет не останавливать производство все новых и новых пилюль для массового потребления (что пользователей, что разработчиков, что проектировщиков), постоянно извлекать прибыль, ставить в зависимость от себя. И всем хорошо.

Знакомая песня. Когда-то, много лет назад, когда я еще варился в тепличной академической среде, я тоже любил порассуждать о мейнстриме, который, вот ведь незадача, устроен совершенно неверно в целом и не хочет программировать "правильными" научными методами в частности. А когда пришлось, по стечению обстоятельств, в этот мейнстрим самому нырнуть, то спустя некоторое количество лет вдруг оказалось, что изнутри видны некоторые факторы, которые ну никак не разглядеть "с орбиты" (как выражаются по адресу One Microsoft Way, Redmond, WA). И если учесть эти факторы, то окажется, что те самые "правильные" методы и языки --- отнюдь не желаемая "серебряная пуля".

Но стоит задуматься, что "паранойя", как гласят словари, -- редкая форма психического заболевания, характеризующаяся своеобразной бредовой переработкой жизненных впечатлений при сохранении формальной правильности мышления.

Раз уж мы начали навешивать друг другу ярлыки с привлечением  психиатрии, предложу встречный вариант: "Аутизм простоты" (http://ru.wikipedia.org/wiki/%D0%90%D1%83%D1%82%D0%B8%D0%B7%D0%BC).


№ 2417   29-08-2007 02:08 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2414« (Димыч)
___________________________

Как формализовать доступ к файлам (документам) со столь разнородной структурой, как например, *.jpg, *.dwg, *.txt, *.doc? На уровне страниц файла?


А в чем проблема? В БД могут быть такие поля, куда записываются данные в произвольном формате. Сам документ может иметь сложную структуру, включая рисунки, таблицы, музыкальные файлы и т.д. Любой рисунок или импортированный из другой ОС файл экзотического формата можно "обернуть" в такой документ. Более того, можно даже иметь в файловой системе - БД все документы единого, но сложного составного формата. В самом документе могут храниться и указания на типы приложений, которые по умолчанию могут работать с таким документом или его частями. Конечно, документ сложного формата будет дольше обрабатываться, но описанный механизм и не предполагается применять к исполнимым файлам, для которых скорость приоритетна. Сам документ не имеет смысла размазывать по нескольким полям БД (страницам файла).

Всё, что сложно реализовать в централизованных таблицах метаданных, проще реализовать в виде тегов, содержащихся в самом документе. Мне кажется, что проблема WinFS в излишней централизации сложноформализуемой информации о структуре, формате и содержании документов. Централизовывать целесообразно лишь то, что универсально для любых документов.



Идея с метаинформацией, разнесенной с телом файла (о чем уже писалость не раз), кажется перспективной, однако вот ассоциативный поиск - уже нет, поскольку поиск должен быть очень "умным", чтобы подыскивать то, что надо, а не то, что считает нужным. Кроме того, многочисленные системы маркировки файлов, созданные за последние лет 15, решают какую-то очень небольшую задачу, не претендуя на полноту. Возможно я просто не встречал удобных систем структурирования информации, а может просто не умею ее структурировать.



Ассоциативный поиск и не должен быть очень "умным" или претендовать на полноту. Но он должен быть удобным. Это лишь способ ускорить поиск, основываясь на сохраненных данных о связях между документами, копировании информации из одного документа в другой, о совместной работе с несколькими документами, о пользователях, работавших с теми или иными документами и т.п. См. сообщение »сообщение 2219« , пункт 7.


№ 2416   29-08-2007 01:13 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2413« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2411« (Сергей Прохоренко)
___________________________

Добавлю также полезные вещи, отсутствующие в хранилищах данных:
1. Возможность рецензировать/аннотировать документы, устанавливать рейтинги.
2. Сопровождение документов метаданными об источнике и приложении, генерировавшем эти данные.
3. Делегирование прав доступа к документам.

Не слишком ли многих людей Вы хотите оставить без работы? :)


Согласно закону Паркинсона объем работы увеличится в другой области.


№ 2415   29-08-2007 00:06 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2414« (Димыч)
___________________________

Можно ли подобное сделать для файловой системы?
WinFS ?


№ 2414   28-08-2007 22:31 Ответить на это сообщение Ответить на это сообщение с цитированием
При обсуждении служебной СУБД хочу упомянуть одну потенциальную проблему, которая неявно присутствует.

БД работает с такими категориями, как запись (кортеж), домен, отношение (таблица) и далее по нарастающей (см. работы Кодда). И хотя в большинстве случаев пользования/администрирования БД это можно не знать, при проектировании все же приходится учитывать.

БД формализуется от самого мелкого элемента до самого крупного; возможно построить матаппарат ко всем процессам, происходящим в базе и вокруг нее. Можно прописать механизмы конкурентного доступа (версионный/блокирующий/комбинированный). Поэтому возможно оперирование сущностями БД в контексте datawarehouses и понятие нормализации.

Можно ли подобное сделать для файловой системы? Не знаю.
Как формализовать доступ к файлам (документам) со столь разнородной структурой, как например, *.jpg, *.dwg, *.txt, *.doc? На уровне страниц файла?

Идея с метаинформацией, разнесенной с телом файла (о чем уже писалость не раз), кажется перспективной, однако вот ассоциативный поиск - уже нет, поскольку поиск должен быть очень "умным", чтобы подыскивать то, что надо, а не то, что считает нужным. Кроме того, многочисленные системы маркировки файлов, созданные за последние лет 15, решают какую-то очень небольшую задачу, не претендуя на полноту. Возможно я просто не встречал удобных систем структурирования информации, а может просто не умею ее структурировать.

Возвращаясь к началу сообщения, проблема состоит в том, что доступ к файлам и файловой системе плохо формализуется (по сравнению с БД) и могут возникнуть проблемы, если скрещивать файловую систему и БД "в лоб".


№ 2413   28-08-2007 16:24 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 2411« (Сергей Прохоренко)
___________________________

Добавлю также полезные вещи, отсутствующие в хранилищах данных:
1. Возможность рецензировать/аннотировать документы, устанавливать рейтинги.
2. Сопровождение документов метаданными об источнике и приложении, генерировавшем эти данные.
3. Делегирование прав доступа к документам.


Не слишком ли многих людей Вы хотите оставить без работы? :)


<<<... | 2432—2423 | 2422—2413 | 2412—2403 | ...>>>
Всего сообщений в теме: 5452; страниц: 546; текущая страница: 304




Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования