You are viewing cniehaus

Previous Entry | Next Entry

Desktop Search (and Kalzium)

Taken in Portugal
All interested in Desktop Search, Strigi, Kat, Tenor or Kerry/Beagle, please read

http://chem-bla-ics.blogspot.com/2006/06/kde-desktop-search-kat-strigi-and.html

Egon created a nice overview about the current situation and asks some questions. I would like to answer one of them: Don't use xattr... Why? If I understand that correctly they only work on some filesystems like XFS, Reiser3, ext2/3 but not on others and also has problems in Windows and MacOS. Also you need a specific mount-option...
kalzium could be a chemistry-specific frontend to Strigi and would offer a specialized GUI for chemistry related data. This would indeed be very cool...

In other news Kazium's new 3D-engine now offer five different view-modes, including different colouring, sticks, spheres, big spheres and something I forgot :) Look pretty cool, I have to say. Thanks Benoit!

Comments

( 35 comments — Leave a comment )
(Anonymous)
Jun. 17th, 2006 02:04 pm (UTC)
xattr
We can't live forever with the dated standard unix permissions. That doesn't work, whereever you need a policy based approach. Be it large scale installations or the need for very finegrained permissions. While writing an application in a way that it does work both with extended attributes and with Windows policies - um, I guess I'm not the only one, who gives a shit about the world leading malware-infested sometimes operation system piece of software.
shannonstaedtl
Aug. 10th, 2008 10:10 pm (UTC)
Before you can start assigning permissions, you need to create a client or department. Typically, you will use FogBugz access control for two purposes: If you have multiple external clients, you can give them all accounts on your FogBugz database without letting them see each other's cases, or even know about each other.
(Anonymous)
Jun. 17th, 2006 02:24 pm (UTC)
But what else?
I think we need a way to share tags and comments independent from the used desktop - think of kalzium users which are running gnome (edubuntu...), or think of f-spot uses which are using KDE. We cannot ask every application to connect to Tenor as well as to provide data for beagle.
There are two possibilties I seeright now to reach this aim: a central database/daemon for all files, or storing the files together with the comments.

From my point of view the second one is much more sensible, because you are then also able to "export" these tags together with the file without even thinking about it. A databased system would not allow easy transport of tags, neither would a daemon allow it. Additionally, a daemon would eat system ressources, etc.

About the file system support and the options:
First of all, the options will be made by the distributors - the user does not have to care. When xattr is more used, the distributoes will activate it.
Additionally, there are file systems which activate it automatically, so this is no problem which is important to normal users.
Also the supporting file systems are no problem: reiserfs, ext2/3, xfs, nfs and jfs support it - there are no other file systems really in use which does not support these. Sure, there are maybe other file systems, but these are not used by the normal users (correct me if I'm wrong).

And the problem of other desktops: MacOS X comes with xattr support, so no problem there (in fact that was one feature that many people have waited for). About Windows: I do not know.

But even if it's not supported with Windows: there could be the possibility to make a database fallback. And that's what I suppose:
We should not give up the possibilties we could have with xattr just because some people think it's a good idea to port Tenor to Windows. We should use xattr - and make sure that there is a fallback for these cases where it does not work.
Keep in mind that we will have a database in every case because the indexing need some kind of storing it's indexed information. So there should be no problem of implementing a fallback.

What do you think about these arguments?
jamiemcc
Jun. 17th, 2006 06:56 pm (UTC)
Re: But what else?
Tracker is already a ready made dbus based tag/metadata server *and* indexer too. In fact its the only open source software that provides the whole deal (indexing, db storage for first class objects, metadata and tags).

Its also super fast and very efficient with RAM and its freedesktop so it should be okay for KDE to use.

(Anonymous)
Jun. 18th, 2006 12:59 am (UTC)
Re: But what else?
Yes, but I already pointed out: a server running in the background just to do something which can be also done completly without depending on a server is odd.

And about "super fast" and "very efficient" - that's worth nothing as long as there are no real comparisons provided. Don't you fancy adjectives, but show statistics.

In any case, the main problem I see here is:
It doesn't matter which solution will be taken at least, but I see it comming that Gnome and KDE will use incompatible solutions.

Is there any cooperation ongoing at the moment? Besides shared-filemetadata-spec? Have the kat-guys talked with beagle, and kitten/strigi with Tracker?
jamiemcc
Jun. 18th, 2006 09:59 am (UTC)
Re: But what else?
You need a db based server for all the metadata/tags.

Without one, how are you going to search for data?

(obviously scanning every file on yer hard disk to get the extended attriutes is too slow!)

(Anonymous)
Jun. 18th, 2006 06:12 pm (UTC)
Re: But what else?
Yes, you are right with the already needed db.
And that I prefer storing the data together with the comments and tags and not in an external database is probably more something personal than really a (dis)advantage.

So I focus more on the interoperability fact: as a user I don't care who stores what and how, but I do care if I can reach and modify my stuff from both desktops in the same way - I don't want to tag all stuff again just because I want to have a look at the newest version of $OTHERDESKTOP.

And I'm afraid that Gnome and KDE will not make a common basis here; probably because the aims are too different, probably because leaftag, a gnome tag solution, is already quite developed and does not want to make the needed changes to become *really* desktop agnostic, probably because KDE wants to have something to tight integrated. I don't know - but I guess that we will not see a common solution. And in this case the xattr solution looks like the best one...
corycuxiv
Jul. 16th, 2008 12:54 am (UTC)
Ravi explained how it works, and it’s proprietary right now, but suffice to say that Kickfire does not need to rewrite all the data you’ve already stored if you suddenly start storing values you didn’t anticipate.
nikkisixul
Jul. 16th, 2008 04:52 am (UTC)
I can explore my own stuff in a tag-oriented way. And I can exploit the social dimension of del. Icio.
gretchenmcanna
Aug. 11th, 2008 05:41 am (UTC)
yes, you right, but when I really need valid data, it can be easily got from entity EJB directly. I do not use cache in business tier.
othaneuhauser
Aug. 10th, 2008 09:55 pm (UTC)
We had considered writing software to capture and play DPX files, however it's very hard on disk systems, and SAN's because you need to open 24 files per second when doing real time capture, and you cannot edit folders of frames very easily in NLE software.
sterlinggilgun
Aug. 10th, 2008 10:44 pm (UTC)
There system MUST be able to backup files that are in use and to control bandwith use so it can run in the background even if you are working on the system.
raultowheed
Aug. 11th, 2008 12:53 am (UTC)
So you can see it's a crappy tedious process, but yes, it can be done :) Posted by Graeme at PM | Comments June Ask an FMS Guru How do I stop that annoying sound.
michalhoghe
Aug. 10th, 2008 10:04 pm (UTC)
It also has gnome and kde so on a GUI level it's pretty much the same as Linux. Landotter October 6th, PM Because it attacts long legged sexy women.
horaciopass
Aug. 10th, 2008 10:57 pm (UTC)
It also has gnome and kde so on a GUI level it's pretty much the same as Linux. Landotter October 6th, PM Because it attacts long legged sexy women.
jerewaltrip
Aug. 11th, 2008 01:06 am (UTC)
It also has gnome and kde so on a GUI level it's pretty much the same as Linux. Landotter October 6th, PM Because it attacts long legged sexy women.
phillipsadowsk
Aug. 11th, 2008 01:30 am (UTC)
It also has gnome and kde so on a GUI level it's pretty much the same as Linux. Landotter October 6th, PM Because it attacts long legged sexy women.
mariastith
Aug. 11th, 2008 02:51 am (UTC)
It also has gnome and kde so on a GUI level it's pretty much the same as Linux. Landotter October 6th, PM Because it attacts long legged sexy women.
milanchaix
Aug. 11th, 2008 04:44 am (UTC)
It also has gnome and kde so on a GUI level it's pretty much the same as Linux. Landotter October 6th, PM Because it attacts long legged sexy women.
danesnodgrasse
Aug. 11th, 2008 04:46 am (UTC)
It also has gnome and kde so on a GUI level it's pretty much the same as Linux. Landotter October 6th, PM Because it attacts long legged sexy women.
daphnemundefor
Aug. 11th, 2008 05:29 am (UTC)
It also has gnome and kde so on a GUI level it's pretty much the same as Linux. Landotter October 6th, PM Because it attacts long legged sexy women.
(Anonymous)
Jun. 18th, 2006 08:08 am (UTC)
Re: But what else?
> And the problem of other desktops: MacOS X comes with xattr support, so
> no problem there (in fact that was one feature that many people have
> waited for). About Windows: I do not know.

Wikipedia lists NTFS as supporting extended attributes.

http://en.wikipedia.org/wiki/Comparison_of_file_systems

It looks like practically everyone has some form of extended attributes that could be used. If extended attributes do the trick, then use them I say. We don't want to be stuck building KDE on "lowest common denominator" operating system features anyway.

--
Simon
adalbertokmeti
Aug. 6th, 2008 05:02 am (UTC)
Some people find the Apple philosophy of designing the OS with the lowest common denominator (the dummy user) in mind admirable; perhaps it is, but for a professional developer it is supremely annoying not to be able to customise things as you like.
heidelykiwo
Jul. 16th, 2008 02:19 am (UTC)
" And more specifically from my point of view " How do you have good standards for automated systems.
johnathonspoon
Aug. 6th, 2008 04:20 am (UTC)
" And more specifically from my point of view " How do you have good standards for automated systems.
erwinmatheson
Aug. 11th, 2008 01:29 am (UTC)
D/bind9 stop Next, edit the file /etc/default/bind9 so that the daemon will run as the unprivileged user bind , chrooted to /var/lib/named.
jospehkraenwyn
Aug. 11th, 2008 01:35 am (UTC)
Bob Drake Regarding installing Leopard on Mac slower than Computerworld comments: "Does not support" really means "will not install," by the way.
michalhoghe
Aug. 11th, 2008 03:02 am (UTC)
Bob Drake Regarding installing Leopard on Mac slower than Computerworld comments: "Does not support" really means "will not install," by the way.
garyrayns
Aug. 11th, 2008 05:04 am (UTC)
Bob Drake Regarding installing Leopard on Mac slower than Computerworld comments: "Does not support" really means "will not install," by the way.
deskitty
Jun. 17th, 2006 05:19 pm (UTC)
I think you're wrong about xattrs.
Why? Because "some filesystems like XFS, Reiser3, ext2/3" are the filesystems most people use.

Plus, most modern *BSDs (using UFS) support xattrs, and Windows has its own somewhat similar solution (named streams on NTFS -- who uses FAT anymore?). I don't know enough about MacOS to comment on it, although I see that another commenter has said OSX also has xattrs. And the special mount option is only for ReiserFS, isn't it? I know XFS doesn't need one, and I didn't think ext? needed one either, but I don't use ext?, so I could be wrong.

Sure, I suppose they don't have 100% support, but xattrs are a lot more mainstream than they used to be. So I think in the majority of cases, users won't have too many issues with software that requires xattr support (and even so, one could come up with a compatibility layer of some sort).

As a user, and a geek, I would much rather see KDE4 embrace xattrs and get the potentially-huge benefits they have to offer, even if not everybody has them yet.
judyzubit
Jul. 10th, 2008 11:50 pm (UTC)
After two years he is still free from the disease which had spread to his lymph nodes and one of his lung" CRITICAL:OS X root via AppleScript "Half the Mac OS X boxes in the world (confirmed on Mac OS X 10.
fallibledragon
Jun. 18th, 2006 07:00 pm (UTC)
There's absolutely nothing wrong with using extended attributes, or ACLs. They work just fine; I've used them on other OSes without any trouble. They're not even difficult for beginners, or that easy to mess up when moving data between systems, the way some people would suggest. All we need is to embrace them, use them, and use tar-like tools that support them. All of that is available, afaik. The benefits are immense, and the limitations imposed by not using them are tragic. On Mac and Windows, these things are already available. On any other system, or even on a filesystem without support, they can be implemented in a fallback way, with a simple file-based database. Frankly, it's embarrassing that we haven't embraced this stuff yet.
jasonsml11
Jun. 21st, 2007 10:51 am (UTC)
agree
never had a problem with extended attributes on main OSes although i'm a rookie.
Jason
hasyer
Apr. 7th, 2008 04:34 pm (UTC)
HeLLO..
Thank you. (;

---------------------
muhabbet
korku
msn nickleri
msn nickleri
netlog
sohbetiq
Apr. 13th, 2008 10:08 pm (UTC)
Hi !
Nice cool. Thanks.
--------------------------
Msn nickleri
( 35 comments — Leave a comment )

Profile

Taken in Portugal
cniehaus
cniehaus

Latest Month

July 2009
S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 
Powered by LiveJournal.com
Designed by Tiffany Chow