I cant get his pdf to open up ggv tells me it isnt a valid postscript file and gpdf just prints out unreadable garbage. Anyone else having this problem?
He’s spot on with ‘files’ being too large a granularity to be useful. I hope he proposes some way of breaking files up into pieces of data that can be manipulated seperately. A relational database is perfect for this. Therefore you no longer have to write file format readers/converters except when you are dealing with different compression options (e.g. audio, image).
i do like some sort of SQL based storage system, because some files fit to more than one directory 9replace “directory” with “category” and make a file “member” of one or more categories)
but i still luke compatability with the traditional file system. matbe gnone-storage is reaching too far.
but i still luke compatability with the traditional file system.
Please read the information properly: GnomeVFS module โ automatically invokes translators on read/write into the store allowing existing GNOME apps to use the store like a normal filesystem
It’s good that storage is not dead, despite the impression the website gives. The only problem with it is I don’t use GNOME any more ๐
yes, i’ve reacted too fast. admitted, there is a compatability layer, but only for GNOME apps. traditional console tools will not work with this storage?
it could be possible if there is a virtual filesystem driver for the storageDB.
It should be a userland File System driver for the OS, so that other non-storage aware programs (e.g. console apps) can still access the files. Would it be terrible slow though? Say you have your oggs/mp3’s in storage.. would ogg123 blah.ogg from the command line be slow as hell?
Also, the real-time document collaboration thingy intrigues me. I imagine working in Open office, with a little window which has names of people also working on the document (and what section they are working on). It could also have a little chat thing (or audio/video connectivity), so that one can discuss issues about the work, even over the internet. The storage system works something like subversion and so can handle branches, merging individual changes, etc etc. Little arrows (or other indicators) could pop up on the edges of the document (i.e. off the page) showing where changes have been made by other users. You can click to view changes, and that merges the changes into your view so you can read them (perhaps a different colour font so it is easy to see).
There is no “merging” at the end of the writing process. The document is already synchronised with all contributors – in real time. An interesting concept, and it would be cool to try out. Careful decisions would need to be made about the UI to make this usable of course.
For crying out loud… Can we please let technology move on? Why do we always have to hobble software because some people are still running PII 400s? I get it. Not everyone has the money to upgrade their hardware (hell, I still have a 1.2GHz system. Ancient by todays standards). But if you can’t upgrade, don’t complain about not being able to use the latest-greatest.
The idea of a killer-app is something that makes people want to upgrade their hardware. The killer-app has been MIA for the last 5-8 years. Maybe, if the Storage guys where allowed to develope, without hearing the constant whining about performace on old systems, they would be able to create the next Killer-App.
“It should be a userland File System driver for the OS, so that other non-storage aware programs (e.g. console apps) can still access the files. Would it be terrible slow though? Say you have your oggs/mp3’s in storage.. would ogg123 blah.ogg from the command line be slow as hell?”
Gnome-VFS, like KDE’s kioslaves, is essentially a set of user-level drivers (what you are proposing, with the user-space kernel modules, would not be an acceptable cross-platform solution; GNOME is used frequently on OSes such as FreeBSD and Solaris in addition to Linux). Keep in mind that what they are discussing in the article is not a complete rerepresentation of the filesystem model; the only functionality that the Gnome-VFS integration provides is that when a file is written from a GNOME application, the metadata index for Storage is updated. Like the upcoming metadata cataloguing in Longhorn’s “WinFS” system, Storage does not replace the traditional filesystem, it merely adds metadata-based search and retrieval features on top of it.
Right now, Reiser4 is just the framework that could be used to build something like BeFS or Storage. Reiser4 doesn’t have user-settable metadata or search queries. Yet.
What it does have is an extendable plugin design, which means that these things can be added to it. Right now Reiser4 is merely very fast.
“His approach isn’t very *nix-ish, it is very Windows-ish. It assumes you have a GUI.”
Please read the article again, especially the part where Seth Nickell wrote “I *will* provide a way to boot into a “stripped down console mode” aka “single” for system recovery and backup, and a regular non-graphical boot for servers.”
From what I can tell, SystemServices in and of itself only depends on D-BUS and libc. There are Python bindings for D-BUS, so that may make it easy to write a script for SystemServices using Python, but that’s the extent of Python’s relationship to SystemServices.
For crying out loud… Can we please let technology move on? Why do we always have to hobble software because some people are still running PII 400s? I get it. Not everyone has the money to upgrade their hardware (hell, I still have a 1.2GHz system. Ancient by todays standards). But if you can’t upgrade, don’t complain about not being able to use the latest-greatest.
Because this is fundamental to the working of the system, and it should not be like this just because Microsoft comes up with Win FS. This is totally the wrong route.
Gnome-VFS, like KDE’s kioslaves, is essentially a set of user-level drivers…
They’re proposing more than that:
…the only functionality that the Gnome-VFS integration provides is that when a file is written from a GNOME application, the metadata index for Storage is updated. Like the upcoming metadata cataloguing in Longhorn’s “WinFS” system, Storage does not replace the traditional filesystem, it merely adds metadata-based search and retrieval features on top of it.
The place for this is in the filesystem – where it belongs. The Microsoft method is absolutely the wrong way to go about it. Hans Reiser – Storage Layers Above the FS: A Sure Symptom The FS Developer Has Failed:
I cant get his pdf to open up ggv tells me it isnt a valid postscript file and gpdf just prints out unreadable garbage. Anyone else having this problem?
It works with Acrobat.
It also works with gv and xpdf.
I had minor flaw on page 4.. second figure covered the text a bit.. this with xpdf
He’s spot on with ‘files’ being too large a granularity to be useful. I hope he proposes some way of breaking files up into pieces of data that can be manipulated seperately. A relational database is perfect for this. Therefore you no longer have to write file format readers/converters except when you are dealing with different compression options (e.g. audio, image).
Gpdf shows garbage characters for me too. Well, it’s always been a flaky program
i do like some sort of SQL based storage system, because some files fit to more than one directory 9replace “directory” with “category” and make a file “member” of one or more categories)
but i still luke compatability with the traditional file system. matbe gnone-storage is reaching too far.
yep same here, with acrobat4 on windows…page 4 figure gets messed up with the text
All this looks alot like what BeOS already did many years ago, except the “natural language” part.
but i still luke compatability with the traditional file system.
Please read the information properly: GnomeVFS module โ automatically invokes translators on read/write into the store allowing existing GNOME apps to use the store like a normal filesystem
It’s good that storage is not dead, despite the impression the website gives. The only problem with it is I don’t use GNOME any more ๐
yes, i’ve reacted too fast. admitted, there is a compatability layer, but only for GNOME apps. traditional console tools will not work with this storage?
it could be possible if there is a virtual filesystem driver for the storageDB.
> All this looks alot like what BeOS already did many
> years ago, except the “natural language” part.
Indeed, a rather small difference ๐
It should be a userland File System driver for the OS, so that other non-storage aware programs (e.g. console apps) can still access the files. Would it be terrible slow though? Say you have your oggs/mp3’s in storage.. would ogg123 blah.ogg from the command line be slow as hell?
Also, the real-time document collaboration thingy intrigues me. I imagine working in Open office, with a little window which has names of people also working on the document (and what section they are working on). It could also have a little chat thing (or audio/video connectivity), so that one can discuss issues about the work, even over the internet. The storage system works something like subversion and so can handle branches, merging individual changes, etc etc. Little arrows (or other indicators) could pop up on the edges of the document (i.e. off the page) showing where changes have been made by other users. You can click to view changes, and that merges the changes into your view so you can read them (perhaps a different colour font so it is easy to see).
There is no “merging” at the end of the writing process. The document is already synchronised with all contributors – in real time. An interesting concept, and it would be cool to try out. Careful decisions would need to be made about the UI to make this usable of course.
In fact, using the LUFS driver, found at http://lufs.sourceforge.net/lufs/ , you can bridge Gnome VFS into a real userland file system driver.
Would it be terrible slow though?
For crying out loud… Can we please let technology move on? Why do we always have to hobble software because some people are still running PII 400s? I get it. Not everyone has the money to upgrade their hardware (hell, I still have a 1.2GHz system. Ancient by todays standards). But if you can’t upgrade, don’t complain about not being able to use the latest-greatest.
The idea of a killer-app is something that makes people want to upgrade their hardware. The killer-app has been MIA for the last 5-8 years. Maybe, if the Storage guys where allowed to develope, without hearing the constant whining about performace on old systems, they would be able to create the next Killer-App.
“It should be a userland File System driver for the OS, so that other non-storage aware programs (e.g. console apps) can still access the files. Would it be terrible slow though? Say you have your oggs/mp3’s in storage.. would ogg123 blah.ogg from the command line be slow as hell?”
Gnome-VFS, like KDE’s kioslaves, is essentially a set of user-level drivers (what you are proposing, with the user-space kernel modules, would not be an acceptable cross-platform solution; GNOME is used frequently on OSes such as FreeBSD and Solaris in addition to Linux). Keep in mind that what they are discussing in the article is not a complete rerepresentation of the filesystem model; the only functionality that the Gnome-VFS integration provides is that when a file is written from a GNOME application, the metadata index for Storage is updated. Like the upcoming metadata cataloguing in Longhorn’s “WinFS” system, Storage does not replace the traditional filesystem, it merely adds metadata-based search and retrieval features on top of it.
How is ReiserFS4 compared to Storage? What are the differences?
Right now, Reiser4 is just the framework that could be used to build something like BeFS or Storage. Reiser4 doesn’t have user-settable metadata or search queries. Yet.
What it does have is an extendable plugin design, which means that these things can be added to it. Right now Reiser4 is merely very fast.
“His approach isn’t very *nix-ish, it is very Windows-ish. It assumes you have a GUI.”
Please read the article again, especially the part where Seth Nickell wrote “I *will* provide a way to boot into a “stripped down console mode” aka “single” for system recovery and backup, and a regular non-graphical boot for servers.”
From what I can tell, SystemServices in and of itself only depends on D-BUS and libc. There are Python bindings for D-BUS, so that may make it easy to write a script for SystemServices using Python, but that’s the extent of Python’s relationship to SystemServices.
For crying out loud… Can we please let technology move on? Why do we always have to hobble software because some people are still running PII 400s? I get it. Not everyone has the money to upgrade their hardware (hell, I still have a 1.2GHz system. Ancient by todays standards). But if you can’t upgrade, don’t complain about not being able to use the latest-greatest.
Because this is fundamental to the working of the system, and it should not be like this just because Microsoft comes up with Win FS. This is totally the wrong route.
Gnome-VFS, like KDE’s kioslaves, is essentially a set of user-level drivers…
They’re proposing more than that:
…the only functionality that the Gnome-VFS integration provides is that when a file is written from a GNOME application, the metadata index for Storage is updated. Like the upcoming metadata cataloguing in Longhorn’s “WinFS” system, Storage does not replace the traditional filesystem, it merely adds metadata-based search and retrieval features on top of it.
The place for this is in the filesystem – where it belongs. The Microsoft method is absolutely the wrong way to go about it. Hans Reiser – Storage Layers Above the FS: A Sure Symptom The FS Developer Has Failed:
http://www.namesys.com/whitepaper.html