Date: Thu, 28 Feb 2013 11:43:51 +0100 From: =?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?= <radiomlodychbandytow@o2.pl> To: freebsd-fs@freebsd.org, Ivan Voras <ivoras@freebsd.org> Subject: Re: freebsd-fs Digest, Vol 506, Issue 4 Message-ID: <512F34E7.40602@o2.pl> In-Reply-To: <mailman.41511.1362042468.2166.freebsd-fs@freebsd.org> References: <mailman.41511.1362042468.2166.freebsd-fs@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28/02/2013 10:07, freebsd-fs-request@freebsd.org wrote: > Message: 2 > Date: Wed, 27 Feb 2013 18:01:27 +0100 > From: Ivan Voras<ivoras@freebsd.org> > To:freebsd-fs@freebsd.org > Subject: Re: Some filesystem thoughts > Message-ID:<kgle54$f79$1@ger.gmane.org> > Content-Type: text/plain; charset="utf-8" > > On 20/02/2013 20:26, Radio m?odych bandyt?w wrote: > >> >The way I see it is not to treat files as streams of bytes. That's not >> >what they are, files have meanings and there are tools that bring them >> >out. A picture is a stored emotion. OK, there are no tools for that yet. >> >But it is also an array of pixels. And a container with exif data. And >> >may be a container with an encrypted archive. And, a stream of bytes too. >> >They have multiple facets. >> >I think that it would be useful to somehow expose them to applications. >> >Wouldn't it be useful to be able to grep through pdfs in your email >> >attachments? > I think the problem is presentation - offering just the "grep" function > is waste of effort since those using GUIs will generally not use grep. > What you're talking about is something like google tried to do with > android (and, probably, failed): a unified search interface across all > applications and their data. Not really. grep was just an example of a more general thing; tools having access to not directly visible properties of files. Another example: I download a src.7z from some project because I want to see how do they do a particular thing. To browse it with my file manager, I need to mount it or extract it unless my file manager supports .7z files. It does, I can just step in. Phew, I saved my time...but only until I get to a file that I want to view with my text editor - then I have to do either of this things 'cause there's no path that FM can pass to the editor. > > Actually, modern smartphones & tablets are slowly moving into the > direction that there are no "files" and no "filesystems" on your device, > but rather jost your "data" and "apps" which both are managed by the > system (and possibly reside in a "cloud"). It may be that the > "hierarhical filesystem" idea has just not so useful or efficient any > more (but OTOH, I don't see it going away any time soon). I checked "hierarchical filesystem" search term. After a quick look I see that it's a thing to read into somewhat deeper. > >> >Mass-edit music tags with sed? Manually edit with your favourite text >> >editor instead of the sucky one-liner provided by your favourite music >> >player? >> >How about video players being able to play videos by reading them in >> >decoded form directly from the filesystem instead of having to integrate >> >a significant number of complex libraries to provide sufficient format >> >coverage? > All those things already exist (or will exist soon) in modern GUI > desktop environments, and especially on handheld-enabled OSes. The way > they are achieved is to introduce a Grand Unified Interface (or several > of them, as it happens), which severly abstract the low-level libraries, > even to the point where the (GUI) application doesn't know it's dealing > with actual files or something completely different. That's not really the same. I don't know if there's any Turing-complete mass-tagger in Unix and for sure that's not a norm. Advanced text edition features like caps corrections are useful in tagging sometimes. More than once I wanted to run jpegtran and similar tools on artwork embedded in music files...the list could go on. Yet why would media managers be supposed to implement such things? There are text editors and scripting languages designed precisely for such jobs, they just don't have access to the file properties needed. They could have, but why would all tools be supposed to implement dozens of interfaces to handle narrow special cases? We already have a Grand Unified Interface interface that almost all programs implement - a filesystem interface. > > If you're more concerned about the technical aspects, then learning to > write filesystems in FUSE would be a good starting point for you. Thanks, but for now I prefer concepts. I know I can learn technicalities, but I don't see myself implementing such thing any time soon and very possibly - ever. -- Twoje radio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512F34E7.40602>