Query support has been implemented into SkyOS. Queries can be initiated through either the Viewer, or directly through the command line.When pressing CTRL+F in the Viewer, a ‘Query Panel’ slides in from the bottom. In this query panel, you can enter your desired queries, and even load and save them.
The query results themselves will immediately be displayed in the file view list. Queries can even be performed on the individual meta-data of files. While no official benchmarks have been performed yet, initial testing shows the query function to be extremely fast and responsive.
The Live Queries are using the notification system (node listener) which is implemented since beta-1. Whenever a new file is created which matches one or more Live Queries, a notification is sent to all listeners.
For instance:
Whenever the Storage Viewer displays a folder, the content will be updated when you place a new file into this folder, or delete one. The same mechanism is used for Live Queries. When the Storage Viewer “displays” a Live Query, it will update the results when a new file matching this query is created. It’s almost identical to the way BeOS was working.
Head to the SkyOS Website for a screenshot of the Viewer query implementation in action.
What kind of queries can be run with this system? I’m unfamiliar with BeFS.
Anymore word on when 5.0 is coming out?
This is what you need to read then (not everything is discussed there, but it’s a good start):
http://www.birdhouse.org/beos/byte/24-scripting_the_bfs/
http://www.birdhouse.org/beos/byte/25-formula_queries/
Surely you just mean “Re enabled”. The filesystem already had them, they just didn’t have them enabled from the GUI or presumably also from the shell. Claiming they “implemented” them when they were in fact implemented in the file system by Axel Dorfler isn’t very accurate, or true.
“Claiming they “implemented” them when they were in fact implemented in the file system by Axel Dorfler isn’t very accurate, or true.”
Err, it clearly states: implemented into SKYOS, not: implemented into BEFS.
Well, SkyFS was changed from BFS; the two are imcomptiable now, so yes there was some work to be done getting the queries working again.
“Claiming they “implemented” them when they were in fact implemented in the file system by Axel Dorfler isn’t very accurate, or true.”
We assume that it is a well-known fact that the SkyFS is based on the BFS. When we say “implemented”, we are referring to query implementation into the Viewer, command line, VFS and SkyOS libraries. We are not claiming that we implemented query support into SkyFS. It is because of the great work by people like Axel Dörfler that we are able to implement this great technology system-wide in SkyOS.
Additionally, SkyFS/BFS was modified. For instance: The query parse code was moved out of SkyFS, so was much of the LiveQuery support. They are now part of the VFS.
Awesome this brings more functionality to SkyOS
5.0 is going to be awesome. Just make it good, make it work. Pay attention to even the smallest detail in the GUI, they’re all important. Oh, and if you want to write another gigabit ethernet driver the RTL8169 would be much apperciated
There’s source for both the Linux driver and Haiku driver 
BeOS seemed to have this but AFAIK no other mainstream viewer does which is sad because when i saw it i taught: “Wow, that is great”
ps. If KDE konquorer or Windows Explorer have this please tell me how to use it.
queries look to be able to do much more than can be done with simpler filesystems normally used on Windows and linux so i doubt you could query date of release of a mp3 on kde but this sounds even great for only name, dates, size, etc.
Filesystems that work with Linux have the necessary infrastructure. Just nothing to interface with and make use of it yet.
“BeOS seemed to have this but…” BeOS practically invented it.
(O.K. They didn’t REALLY invent it, but they implemented it successfully!)
The file system that works in Linux works in this to.
Only name, size and the other standard attributes would be fine too. Just say me how you can view only the files starting with an a and being bigger than 5k in a directory
How can this happen? Is not a GPL violation??
No since anyone can copy the icons out of skyos then the “source is available”. The icons are owned by Everaldo they were designed for KDE but since KDE is gpl it cannot really own anything.
cool stuff. And if it’s true that seach results show up nearby immediately, this feature will rock.
Gonna give it a try as soon as it is downloadable in a service pack! 🙂 Or maybe in a iso distribution? *gg* anyway.
First, great!!!!
Four not-used-SkyOS-type questions spring to mind:
1) it says it monitors file adds and deletes – how about file modifications (and rewrites)?
2) any plans to support searching *inside* files too? (Some kind of agent approach to parse sensible info from otherwise opaque data formats springs to mind.)
3) does SkyOS have a structured filesystem such as “apps” and “documents” separation? It would make sense to restrict the searching to the “documents” part and remote media.
4) any plans for remote integration? Googling inbuilt?
(Shameless plug: http://www.syllable.org/discussion.php?id=471 )
> 1)
in BeOS te node monitor notifies stat changes, file move and attribute changes as well.
> 2)
That isn’t possible with queries as they are done, but I guess something like BeOS’ registrar could be modified to also parse the file and extract some important keywords using plugins depending on the file type it just sniffed…
> 4)
remote ??
googling ? as in what ? Queries are quite what google desktop tries to do in windows :p
Now, you can also do the opposite, that is query google itself with googlefs
http://clapcrest.free.fr/revol/beos/shot_googlefs_006.png
Isn’t this what Beagle is already doing, or am i totally wrong?
“Isn’t this what Beagle is already doing, or am i totally wrong?”
You are wrong. Beagle is an application, and then even one that requires adaptions to the Linux kernel. The queries in SkyOS are basically the same as those in BeOS: implemented at the FS level and therefore inherantly better and faster than letting an application do it.
Implementing this at the FS level also ensures that anyone can code query functionality into their programs and apps. Far better than what Beagle or other desktop search tools are trying to achieve.
Also, Beagle and others will require momery and other resources– Query at the FS level doesn’t.
As you can see, this is superior to desktop search tools like Beagle.
I am not really a Beagle hacker, but I’ve been following it for a while. Some points:
You are wrong. Beagle is an application, and then even one that requires adaptions to the Linux kernel.
The Inotify patch to the kernel, yes, that as I understand has something to do with being notified about file changes. Right now you have to patch your kernel, but I think that the idea is that eventually Inotify will be incorporated upstream in the vanilla kernel.
The queries in SkyOS are basically the same as those in BeOS: implemented at the FS level and therefore inherantly better and faster than letting an application do it.
I don’t really know much about the BeFS or its SkyOS derivative, but ‘inherently better and faster’? I don’t know how the metadata are indexed, but I’m sure you can have very fast queries on a ‘usual’ DB application implemented e.g. with a normal file. After all, being good at queries is what DBs are for, and they can be optimized easily, while tweaking the filesystem is probably harder. Better maybe in the sense that metadata are naturally moved with files.
Implementing this at the FS level also ensures that anyone can code query functionality into their programs and apps.
Well, in the sense that you’ll have it in the filesystem API instead that in some beagle library API. But even without it being in the filesystem, beagle works with a daemon indexing and parsing queries as a backend, and you can communicate with it from your code in the same way that the existing graphical frontend that comes with Beagle does.
Also, Beagle and others will require momery and other resources– Query at the FS level doesn’t.
True, Beagle will require Mono, and all the worrying RAND/patents issues some coders can’t live with. And it is atm very unoptimized, of course, so it’s quite a memory hog.
Let’s wait for a version 1.0 before judging on its resources hunger, but the issue with the Mono dependency stands.
As you can see, this is superior to desktop search tools like Beagle.
Arguably, imo.
1) Beagle tries to be filesystem-agnostic, I think. A big advantage in my world, where I have to keep some partitions formatted in FAT32 to share stuff quickly with my Windows installations. Also, memory cards that come with digital cameras use FAT32.
But mainly:
2) Beagle uses a system of plugins to index and search the _contents_ of your documents ( same as Spotlight, for what I could read about it). That’s infinitely more useful to me than a query on the metadata only. Plus, many document types have their own sets and ways of setting metadata. I suppose that in BeOS the idea was of copying those in-file metadata to BeFS metadata for the file with the goal to expose them to fs-based queries?
To whoever knows about these technical issues with BeFS and Beagle, please correct any blatant mistakes I did
maybe ill try skyos some day in the future.
its starting to look like skyos would be a nice home desktop os with the abilitys it have in multimedia as those could extend into gameing nicely
looking forward to se what else gets put in.
can anyone comment on how simple it would be to replace the default desktop with something of my own creation?
Beagle aims to be file system and even operating system agnostic, in line with most free software projects. So comparing SkyOS’ new found query technology to Beagle is somewhat pointless.
Querying at the file system level may make sense for SkyOS, but will be a total disaster for Linux. To put things into perspective, how many file systems is Linux expected to support? Compare that with the number of file systems SkyOS supports, and it immediately becomes evident why both operating systems will continue approach solving similar problems in different ways, in this case global querying technologies.
In brief, for a project to be somewhat accepted in Linux/Unix-like environments, it needs to be as component agnostic, modular and pluggable as possible. This requirement does not apply to SkyOS, OS X or Windows at all. Therefore, to claim one methodology of search/querying in one operating system is better than another is quite shortsighted and misinformed.
“Compare that with the number of file systems SkyOS supports”
From skyos.org:
“The native filesystem used in SkyOS is SkyFS. This 64-bit journaled filesystem supports modern features like attributes, indexes, and queries. To access other operating systems’ native filesystems, SkyOS comes with FAT12/16/32, BFS (BeOS), Ext2/Ext3 and ISO9660 (CD-ROM) filesystem drivers.”
In any case, more than Windows
.
To the letter that’s true. But answering the _meaning_ of the question the correct answer is “one, SkyOS supports live queries on SkyFS”.
BTW, I don’t want to give the impression that I’m ditching this SkyOS feature. I can think of many ways in which this can be useful to the desktop user, I would use it mainly for file tagging and subject grouping. It’s just that until our apps do consistently fill in the metadata for us, we’ll still have to get our hands dirty and dig inside the documents when we need to search.
microsfot had an idea for filling in the metadata, drag and drop into an existing quesry
basicly the new file would get the same metadata as was searched for in the query.
other files, like mp3 files allready have metadata available in then.
mails have a structure that can be extracted to.
only thing that may need manual metadata addition is stuff like office files and pictures. and envision if pictures had metadata stored in them like most music files have these days. then google and similar could extract that info and the ability to search for images would increase dramaticly (if the metadata is good that is, given the amount of data falseification that happens on the web to get more hits i worry).
in fact its not the filesystems that should have metadata stored in them, its the files themselfs. that way metadata is transferable from filesystem to filesystem or from computer to computer.
It doesn’t take Microsoft, I think everybody came up with that idea as soon as they were familiar with the idea of live queries as virtual folders.
But of course it does not always work: what if my query was of the form ‘genre=pop OR genre=rock OR rating>80%’?
Would you set the rating, or the genre. Or both? and to what genre? The user would have to complete that manually.
And the point I was making is that office files do _have_ metadata, and music and some pictures (EXIF tags). But that’s inside the file, so from the point of view of a filesystem, that’s not meta-data, that’s data
So if you want to search on them you either copy them on fs metadata, and then you have to keep this redundancy syncronized, or yu search inside the files.
Our life would be easier if the most used file formats had evolved in metadata-rich filesystems and thus had used them. But, alas, that’s not the world we live in.
for files that allready have metadata then the filesystem should keep a copy of the internal metadata and automaticly update the internal one if the one in the filesystem is changed (or atleast query the user about it).
and the same with a query containing OR entrys. query the user. metadata isnt perfect, but the more aware the user is of its precence and the more they become used to useing it the more they will make sure that the metadata is up to speed.