Неспособность Microsoft выпустить WinFS в срок может привести к изменению облика...

Баян. (см. AAAAAAAAAAAAa!)

Та тема называется не "AAAAAAAAAAAAa!", а "Ааааааааааааааа!".

Бредятина построенная на бредовых утверждениях и приводящая к еще болле бредовым выводам.

>Та тема называется не "AAAAAAAAAAAAa!", а "Ааааааааааааааа!".

Старая виндовая привычка.

Автор прав, цитирую: "Для дальнейшего развития информационных технологий объектно-ориентированная система хранения нужна, как воздух."

*никсам со своей концепцией "everything files" не места в будущем, имхо.

Тебе мешает, что у тебя что-то там валяется в /dev? Ты можешь в своей венде в одной командой скопировать, скажем, MBR харда в файл?

>*никсам со своей концепцией "everything files" не места в будущем, имхо.

опчть ты пернул в лужу - и чем это мешать будет ООС хранения ? или если в твоем понимании ООС храниеия это БД - то с такой идеей все посылаются на фиг ибо это убогость.

Енергетик ты ошибаешься. Объект это нечто принимающее сообщения и обрабатывающее их. => команда "echo reboot > /dev/reboot" это уже ООФС. А прослойку ещё одну придумывать в оффопике IMHO бессмысленно. Он итак пирог уже напоминает.

>А прослойку ещё одну придумывать в оффопике IMHO бессмысленно. Он итак пирог уже напоминает.

скорее винигрет %)

>>Енергетик ты ошибаешься. Объект это нечто принимающее сообщения и обрабатывающее их.

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

ИМХО бред и полный кг/ам. При чем здесь смерть линухи и винды??? Даже если и построят какую-нить систему с ОО подходом к реализации хранения данных, то явно на уже имеющемся ядре в виде какой-нить очередной прослойки.

Не е_<be> мозги
Хочешь объекты и сейчас? На:
sysctl net.ipv4.ip_forward
net(объект) --> ipv4(объект) --> ip_forward (свойство)

А как оно там хранится и где, знать не надо - дал команду и готово

>>ИМХО бред и полный кг/ам. При чем здесь смерть линухи и винды??? Даже если и построят какую-нить систему с ОО подходом к реализации хранения данных, то явно на уже имеющемся ядре в виде какой-нить очередной прослойки.

Надстройка Windows привела к смерти DOS'а, точнее, его специально убили.

> Также объект это нечто имеющее некий набор свойств.

Файл - универсальная простейшая абстракция. Объекты можно легко свести к файлам.

> Объекты имеющие из свойств только имя, расширение, размер и дату создания

Этого достаточно. Всё остальное реализуется поверх этих простейших файлов по мере надобности. Например, каталог с файлом index.html и пр. сопустствующими (css, images, ...) может рассматриваться как один документ. В нём тебе, пожалуйста, и название, и автор, и кодировка, и много чего ещё.

> которые могут хранится только в иерархическом древовидном порядке - это вчерашний день, имхо.

Ну, это в Windows все средства для преодоления иерархичности попрятали так, что хрен найдёшь, а в *nix есть такая штука, называется ln.

>>Файл - универсальная простейшая абстракция. Объекты можно легко свести к файлам.

В том-то и дело, что пора от этой простоты отходить. В сабжевой статье как раз об этом и написано.

>>Этого достаточно. Всё остальное реализуется поверх этих простейших файлов по мере надобности.

Увы, пока реализации этого находятся в зачаточном состоянии и широкого распространения не получили.

2geek ** (*) (24.07.2005 9:34:10)
>А прослойку ещё одну придумывать в оффопике IMHO бессмысленно. Он итак пирог уже напоминает.
>скорее винигрет %)
Который уже кто-то съел :-)

Мы уже имели новшества от MS в деле FS-строения (FAT16, FAT32 и т.п.). Кредит доверия давно уже исчерпан и NTFS-ом кривым это не изменить.

2Energizer (*) (24.07.2005 11:58:03)
>В том-то и дело, что пора от этой простоты отходить.
Правильно, отходи, не мешай людям делом заниматься :-)
>Увы, пока реализации этого находятся в зачаточном состоянии и широкого распространения не получили.
Уточни, в какой системе. Примеров побольше.

2Energizer (*) (24.07.2005 11:58:03)
>Увы, пока реализации этого находятся в зачаточном состоянии и широкого распространения не получили.
Для общего развития почитай, что такое DCE и DFS.

угу. А универсального интерфейса к этой абстракции нету. ну есть файл баян.mp3 дык я хочу иметь возможность обратиться к "файлу" исполнитель.баян.mp3 - т.е. к отдельной структуре, причем тем же интерфейсом (неебет, хоть cat). А еще учти что там внутри есть "файл" про описание формата, алгоритма компрессии, мне нужен универсальный интерфейс чтобы из этой структуры на выходе (пофиг что там) можно было pcm дернуть. Чтобы можно было всю программу с либами ресурсами и потрохами представлять или как файл или обращаться по отдельности покомпонентно.

>>Мы уже имели новшества от MS в деле FS-строения (FAT16, FAT32 и т.п.). Кредит доверия давно уже исчерпан и NTFS-ом кривым это не изменить.

Среди кого исчерпан этот "кредит доверия"?

Тут у народа другое мнение: http://www.e-graduate.ru/Useful.html?artId=e5de1360-a9dc-430c-a2a3-a3032fe9bb93 , более свежего с ходу не нашел, но в целом картина понятна.

> ну есть файл баян.mp3 дык я хочу иметь возможность обратиться к "файлу" исполнитель.баян.mp3 - т.е. к отдельной структуре

Не понял, что за отдельная структура? исполнитель/баян.mp3 не устраивает?

> причем тем же интерфейсом (неебет, хоть cat)

В таком случае, объясни, что значит "обратиться"?

> мне нужен универсальный интерфейс чтобы из этой структуры на выходе (пофиг что там) можно было pcm дернуть.

man sox

> Чтобы можно было всю программу с либами ресурсами и потрохами представлять или как файл или обращаться по отдельности покомпонентно.

program_1.0_i386.deb - файл. Стандартными средствами можно легко расковырять на отдельные составляющие.

Смотри в сторону FUSE. Пишется user-space драйверок (хоть на C, хоть на Python, хоть на Perl), который будет делать виртуальную файловую систему, в которой файлопомойка mp3'шек, wav'ов, wma'шек будет отображаться в виде дерева каталогов по исполнителям, альбомам и пр. на основе ID3 тегов или ещё какой хрени. Каждый файл будет представлен каталогом, в котором будут его "свойства". Например:

исполнитель/баян/mp3 - в виде mp3, исполнитель/баян/pcm - в виде PCM wav.

> В том-то и дело, что пора от этой простоты отходить. В сабжевой статье как раз об этом и написано.

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

> Увы, пока реализации этого находятся в зачаточном состоянии и широкого распространения не получили.

С чистыми DB-based FS дела ещё хуже. Имел я тут дело с PalmOS. Жуть. Как внутри, так, местами, и снаружи. Хотя, со своими задачами более-менее справлялась.

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

>>С чистыми DB-based FS дела ещё хуже. Имел я тут дело с PalmOS. Жуть. Как внутри, так, местами, и снаружи. Хотя, со своими задачами более-менее справлялась.

Разумеется, хорошая идея должна иметь хорошую реализацию. Вот например, неплохая вобщем-то идея пэкедж-менеджеров и репозиториев с обновлением софта одной командой, благодаря опенсорсникам реализована просто по-уродски: Наплодили зоопарк несовместимых между собой форматов пакетов (только название общее - rpm или deb) и связали их непомерной кучей зависимостей от версий и кривых рук майнтрейнеров.

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

Если хочешь, я тебе сделаю. Сколько универсальных обменных единиц ты готов за это выложить? При желании, можно и настоящую DBFS сделать. С backend'ом, например, на PostgreSQL.

> неплохая вобщем-то идея пэкедж-менеджеров и репозиториев с обновлением софта одной командой, благодаря опенсорсникам реализована просто по-уродски

Ну, начинается... :) Я уже писал свой взгляд на эти вещи. В принципе, могу ещё раз написать. Последний. Надоело.

Хочу свободно манипулировать любыми файлами данных (системные нам ни к чему) аки объектами имеющими кучу свойств и которые можно группировать произвольно по метаинфе. Готов за это заплатить не больше, чем за OEM-версию Windows Vista Home Edition :).

>>Ну, начинается... :) Я уже писал свой взгляд на эти вещи. В принципе, могу ещё раз написать. Последний. Надоело.

Ты прав, не будем опять начинать :).

ps: Просто я сегодня злой: Хотел с подругой сходит на озеро, а с утра, вот льет дождь...

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

Вообще-то, юзерам и твоя объектная ориентированность на .. не сдалась, они хотят жрать попкорн и смотреть video on demand (копирайт Б.Г.). Невнимательно читаешь классиков.

Все верно, но когда у юзера на терабайтном винте накопится туева хуча фильмов/музыки/фоток/и тп., то за время поиска чего-то конкретного на винте, можно сожрать весь попкорн :).

> Хочу свободно манипулировать любыми файлами данных (системные нам ни к чему) аки объектами имеющими кучу свойств и которые можно группировать произвольно по метаинфе.

Совсем любыми? Интересно, а эта Vista поймёт, скажем, метаинфу OrCAD'овских схем? Или, скажем, такую метаинфу, как версия файла в RCS, CVS (или какая там в Vista система контроля версий для текстов?)? А для сетевых ресурсов это работает?

Это вообще характерно для политических и экономических проходимцев - навязывать народу мысль, что он - свинья, которой нужно лишь большое корыто с отборными помоямию

> Все верно, но когда у юзера на терабайтном винте накопится туева хуча фильмов/музыки/фоток/и тп., то за время поиска чего-то конкретного на винте, можно сожрать весь попкорн :).

Ты предлагаешь ему альтернативу - набивать метаинфу самостоятельно для каждого фильма? :)

> Совсем любыми? Интересно, а эта Vista поймёт, скажем, метаинфу OrCAD'овских схем? Или, скажем, такую метаинфу, как версия файла в RCS, CVS (или какая там в Vista система контроля версий для текстов?)? А для сетевых ресурсов это работает?

Нет, это будет работать только для тех форматов, которые нужны самой M$ - wma, wmv, doc и пр. Не видишь разве, к чему всё идёт? :)

>>Совсем любыми? Интересно, а эта Vista поймёт, скажем, метаинфу OrCAD'овских схем? Или, скажем, такую метаинфу, как версия файла в RCS, CVS (или какая там в Vista система контроля версий для текстов?)? А для сетевых ресурсов это работает?

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

>>Ты предлагаешь ему альтернативу - набивать метаинфу самостоятельно для каждого фильма? :)

Нет, но тоже можно. Правильные медиаданные будут идти с уже вбитой метаинфой или будут добавляться из интернета автоматически (типа как через cddb для аудиодисков).

>>Это вообще характерно для политических и экономических проходимцев - навязывать народу мысль, что он - свинья, которой нужно лишь большое корыто с отборными помоямию

Неее, эти как раз честнее будут. Проходимцы же будут кричать о "свободе, равенстве, братстве".

> Неее, эти как раз честнее будут. Проходимцы же будут кричать о "свободе, равенстве, братстве".

С, Р и Б не навязываются. Не хочешь - не участвуй. А DRM собирается запретить мне на моём компьютере (!!) запускать программы, которые я хочу запускать.

Уррааа! Энергетик осознал, что менеджер пакетов вещь правильная! Ещё годик-другой, и мы его на debian посадим!

Энергетик, что тебе лично не хватает в файлах? И часто ли ты лично пользовался многопоточностью NTFS? ФС в БД - это примерно как 3D-десктоп. Приколько, красиво - но неюзабельно, ибо мы живём совершенно в другом повседневном мире.

То есть ты хочешь их засунуть в произвольного формата помойку, а потом писать 3х страничный SQL для вытаскивания? Не все юзеры хотят быть программерами. Не все хотят учить SQL. Человек свободно ориентируется в древовидных структурах, и путается на сложных графах (которые к тому же раскрашены и с весами на вершинха и рёбрах)

>>Уррааа! Энергетик осознал, что менеджер пакетов вещь правильная! Ещё годик-другой, и мы его на debian посадим!

Угу, когда до ума доведёте свои менеджеры с репозиториями.

>>Энергетик, что тебе лично не хватает в файлах?

Мне не нравится сама концепция файлов с их ограниченным набором свойств. Я хочу работать с _данными_ и _информацией_, но не с файлами.

Ты бы что ли определил такой набор метаданных, которые бы однозначно работали со всем многообразием информации, которую мы имеем. И чтобы любой *general-purpose* инструмент их с коробки подхватывал и с ними работал.

Поэтому на данный момент как раз и получается, что НОД таких метаданных содержится в атрибутах файлов (ну еще можно автора добавить if applicable), а остальная специфическая инфа отдается на откуп специфическим тулзам, которые знают, чего с ней делать.

А знаешь, ведь данные -- это не только заявления в ворде, квартальные отчеты в экселе, перацкие мп3, ебуки в пдф и порнуха в жопег. Их гораздо больше всяких-разных бывает. И все при этом нужны. Обобщить необобщаемое?..

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

>>А знаешь, ведь данные -- это не только заявления в ворде, квартальные отчеты в экселе, перацкие мп3, ебуки в пдф и порнуха в жопег. Их гораздо больше всяких-разных бывает. И все при этом нужны. Обобщить необобщаемое?..

Если бы все было просто, то микрософт не отложила бы релиз WinFS. На опенсорсников надежды нет, они такое ниасилят.

google хоть и не опенсорс, но там наши математики Саша Брин и еще какой-то, так вот они - осилят. Не зря MS боится их конкуренции и хочет любыми путями закрыть гугол. И не дать им выпустить свою ОС на основе открытых сорсов

>Не понял, что за отдельная структура? исполнитель/баян.mp3 не устраивает? в том то и дело что нет, нужен доступ к тому что внутри баяна - mp3 тег расковырять средствами фс

>man sox

в том то и дело что не универсальный :) в идеале не хранить в голове кучу файловых ассоциаций а дернуть cat баян.mp3/pcmdata/44100 > /dev/dsp/44100 :)

>rpm можно стандартными расковырять

опять нет единого интерфейса :) да и я про уже установленную говорил. пример - допустим в /usr/local что-то поставил, потом залез в /opt/program - а там внутри все что к этой программе относится и в /usr/local лежит чтоб это грохнуть разом.

А о раздергивании структуры файла (тегов и прочего) на уровне ФС я говорил к тому что так впоследствии легко выборку можно будет осуществлять, а также уйти от монодеревянной структуры. Сейчас файлопомойки организуются следующим образом - юзер смотрит на файло и группирует его по какому-то признаку, на основании этого переносит в какую-нить папку. Не нужно это будет если вся метаинфа будет на уровне ФС, останется только выбрать представление, не только по алфавиту и по дате как сейчас, а допустим по версии установочного пакета определенной программы (файлопомойка с отдельной дирой не нужна будет) или по альбому исполнителя

а насчет FUSE - присмотрюсь. Похоже на выход.

>Совсем любыми? Интересно, а эта Vista поймёт, скажем, метаинфу OrCAD'овских схем? Или, скажем, такую метаинфу, как версия файла в RCS, CVS (или какая там в Vista система контроля версий для текстов?)? А для сетевых ресурсов это работает?

а об этом уж позаботится разработчик. просто прикрутить удобное API для этой ФС, допустим какой-нить SaveObject(), причем прилепить туда всякие вкусности. Так вам надо дергать fopen, преобразовывать файл, а так зарегил объект и все. Причем дополнительный бонус всплывает - для программы становится прозрачно где лежит этот объект - хоть на диске, хоть в свопе, хоть в оперативе - вас же не волнует теперь где ваша программа - в свопе или в RAM? так и отображение файла в память уйдет в прошлый век