История изменений

Чтобы ФС смогли работать как БД, нужно не просто радикально переделывать весь storage-layer, а еще и создавать широкую экосистему, в рамках которой независимые разработчики приложений могли бы договариваться между о форматах данных.

В контексте этих рассуждений непонятен твой оптимистичный настрой на тему того, что эти идеи получат дальнейшее развитие. Считаешь, что независимые разработчики смогут между собой договориться? По Linux’у это как-то не особо заметно.

И кстати при подходе «File System like Data Base» ещё ведь всплывают чудовищные проблемы сожительства с остальными уже существующими экосистемами, которые не разделяют подобные подходы. Миграция «файлов» или «объектов» из одного в другое будет чертвоски усложнена, а сами компании-основатели экосистем будут цепляться за собственные несовместимые реализации до последнего.

За примерами ходить далеко не надо – Classic Mac OS и технология в древнем HFS называемая Resource Fork.

The rigid nature of traditional programming bothered me. The idea of an application frozen in code, with no way to change anything dynamically, was anathema to my ideals. I wanted to be able to change as much as possible at runtime. Of course, the application code itself couldn’t be changed, but what could be changed without having to recompile the code? (c) Bruce Horn

The solution was that files on the original Macintosh had a “data fork” and a “resource fork”, something that made it incredibly easy to store things like icons, translations etc. along with binary files.

Идея вроде как интересная, здравая и разумная. Но во что это вылилось на практике? В то, что когда пользователь Mac OS пытался залить куда-нибудь или перенести на какую-нибудь другую ФС (вроде тех, что использовались в Windows или MS-DOS) свои файлы из-за потери resource forks он получал неработающую тыкву с куском безвозвратно потерянной инфы. В итоге эта неплохая идея стоила пользвателю больших потерь по удобству, из-за которых пользователи должны были добывать и даже покупать специальное стороннее ПО (созданное даже не Apple) и хранить файлы, предназначенные для переноса в сложных архивах специальных форматов, дабы вся нужная информация для работы программы сохранялась.

Чтобы ФС смогли работать как БД, нужно не просто радикально переделывать весь storage-layer, а еще и создавать широкую экосистему, в рамках которой независимые разработчики приложений могли бы договариваться между о форматах данных.

В контексте этих рассуждений непонятен твой оптимистичный настрой на тему того, что эти идеи получат дальнейшее развитие. Считаешь, что независимые разработчики смогут между собой договориться? По Linux’у это как-то не особо заметно.

И кстати при подходе «File System like Data Base» ещё ведь всплывают чудовищные проблемы сожительства с остальными уже существующими экосистемами, которые не разделяют подобные подходы. Миграция «файлов» или «объектов» из одного в другое будет чертвоски усложнена, а сами компании-основатели экосистем будут цепляться за собственные несовместимые реализации до последнего.

За примерами ходить далеко не надо – Classic Mac OS и технология в древнем HFS называемая Resource Fork.

The rigid nature of traditional programming bothered me. The idea of an application frozen in code, with no way to change anything dynamically, was anathema to my ideals. I wanted to be able to change as much as possible at runtime. Of course, the application code itself couldn’t be changed, but what could be changed without having to recompile the code? (c) Bruce Horn

The solution was that files on the original Macintosh had a “data fork” and a “resource fork”, something that made it incredibly easy to store things like icons, translations etc. along with binary files.

Идея вроде как интересная, здравая и разумная. Но во что это вылилось на практике? В то, что когда пользователь Mac OS пытался залить куда-нибудь или перенести на какую-нибудь другую ФС (вроде тех, что использовались в Windows или MS-DOS) свои файлы из-за потери он получал неработающую тыкву и куском безвозвратно потерянной инфы. В итоге эта идея стоила пользвателю больших потерь по удобству, из-за которых пользователи должны были покупать специальное стороннее ПО (созданное даже не Apple) и хранить файлы, предназначенные для переноса в сложных архивах специальных форматов, дабы вся нужная информация для работы программы сохранялась.

Чтобы ФС смогли работать как БД, нужно не просто радикально переделывать весь storage-layer, а еще и создавать широкую экосистему, в рамках которой независимые разработчики приложений могли бы договариваться между о форматах данных.

В контексте этих рассуждений непонятен твой оптимистичный настрой на тему того, что эти идеи получат дальнейшее развитие. Считаешь, что независимые разработчики смогут между собой договориться? По Linux’у это как-то не особо заметно.

И кстати при подходе «File System like Data Base» ещё ведь всплывают чудовищные проблемы сожительства с остальными уже существующими экосистемами, которые не разделяют подобные подходы. Миграция «файлов» или «объектов» из одного в другое будет чертвоски усложнена, а сами компании основатели экосистем будут цепляться за собственные несовместимые реализации до последнего.

За примерами ходить далеко не надо – Classic Mac OS и технология в древнем HFS называемая Resource Fork.

The rigid nature of traditional programming bothered me. The idea of an application frozen in code, with no way to change anything dynamically, was anathema to my ideals. I wanted to be able to change as much as possible at runtime. Of course, the application code itself couldn’t be changed, but what could be changed without having to recompile the code? (c) Bruce Horn

The solution was that files on the original Macintosh had a “data fork” and a “resource fork”, something that made it incredibly easy to store things like icons, translations etc. along with binary files.

Идея вроде как интересная, здравая и разумная. Но во что это вылилось на практике? В то, что когда пользователь Mac OS пытался залить куда-нибудь или перенести на какую-нибудь другую ФС (вроде тех, что использовались в Windows или MS-DOS) свои файлы из-за потери он получал неработающую тыкву и куском безвозвратно потерянной инфы. В итоге эта идея стоила пользвателю больших потерь по удобству, из-за которых пользователи должны были покупать специальное стороннее ПО (созданное даже не Apple) и хранить файлы, предназначенные для переноса в сложных архивах специальных форматов, дабы вся нужная информация для работы программы сохранялась.

Чтобы ФС смогли работать как БД, нужно не просто радикально переделывать весь storage-layer, а еще и создавать широкую экосистему, в рамках которой независимые разработчики приложений могли бы договариваться между о форматах данных.

В контексте этих рассуждений непонятен твой оптимистичный настрой на тему того, что эти идеи получат дальнейшее развитие. Считаешь, что независимые разработчики смогут между собой договориться? По Linux’у это как-то не особо заметно.

И кстати при подходе FS like BD ещё ведь всплывают чудовищные проблемы сожительства с остальными уже существующими экосистемами, которые не разделяют подобные подходы. Миграция «файлов» или «объектов» из одного в другое будет чертвоски усложнена, а сами компании основатели экосистем будут цепляться за собственные несовместимые реализации до последнего.

За примерами ходить далеко не надо – Classic Mac OS и технология в древнем HFS называемая Resource Fork.

The rigid nature of traditional programming bothered me. The idea of an application frozen in code, with no way to change anything dynamically, was anathema to my ideals. I wanted to be able to change as much as possible at runtime. Of course, the application code itself couldn’t be changed, but what could be changed without having to recompile the code? (c) Bruce Horn

The solution was that files on the original Macintosh had a “data fork” and a “resource fork”, something that made it incredibly easy to store things like icons, translations etc. along with binary files.

Идея вроде как интересная, здравая и разумная. Но во что это вылилось на практике? В то, что когда пользователь Mac OS пытался залить куда-нибудь или перенести на какую-нибудь другую ФС (вроде тех, что использовались в Windows или MS-DOS) свои файлы из-за потери он получал неработающую тыкву и куском безвозвратно потерянной инфы. В итоге эта идея стоила пользвателю больших потерь по удобству, из-за которых пользователи должны были покупать специальное стороннее ПО (созданное даже не Apple) и хранить файлы, предназначенные для переноса в сложных архивах специальных форматов, дабы вся нужная информация для работы программы сохранялась.