Date: Thu, 21 Feb 2013 12:40:07 +0100 From: "Ronald Klop" <ronald-freebsd8@klop.yi.org> To: freebsd-fs@freebsd.org Subject: Re: Some filesystem thoughts Message-ID: <op.wsutc5a68527sy@212-182-167-131.ip.telfort.nl> In-Reply-To: <51252372.1040001@o2.pl> References: <mailman.15.1361361601.62143.freebsd-fs@freebsd.org> <51252372.1040001@o2.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 20 Feb 2013 20:26:42 +0100, Radio m=C5=82odych bandyt=C3=B3w = <radiomlodychbandytow@o2.pl> wrote: > Hello, > I'm a pretty fresh Unix user, suffering from productivity loss caused = by = > changing OS. I dearly miss a couple of facilities that I had implement= ed = > in my file manager (Total Commander) and sought a file manager that = > could replace them. I'm pretty sure there's none. I found that Unix do= es = > some of them at the OS level and that's a superior way. But with other= s = > it doesn't; some file managers implement them by themselves, much like= = > TC (not well enough, but that's another rant), but I think that for = > them, OS is the right place too and that's what I'd like to talk about= . = > I come with a free idea that I think would be awesome to have = > implemented, while not being sure it even can be implemented sensibly = = > within Unix. Maybe I miss something? Maybe the idea ain't good? Maybe = = > there are things that do the job well enough already and I just miss = > them? > > Anyway, here's the story: > > Total Commander's filesystem plugins are awesome. They enable users to= = > manage remote / virtual resources just like remote filesystems. FTP, = > websites, process list, calendar; the variety is rich. > In Unix, there are equivalents for some of them; the ones that mattere= d = > the most for me can be usually simulated by mount. > And that's a better way because when mounted, they can be used by any = = > program, not just file manager. I'm sure that all people here are used= = > to enjoying the benefits of this approach, though for me they are nove= l. > > The other thing - packer plugins. They allow treating archives like = > directories. Again, there are many useful ones, some obvious (like = > zips), some not so much. I treated my executables as directories, whic= h = > enabled me to easily manipulate resources stored inside. Especially = > useful when hacking closed-source Delphi programs as they contain lots= = > of GUI code stored directly (The name 'TNASTYNAGSCREEN' will stay in m= y = > mind for long). Or extracting icons. Or doing many other things that a= re = > necessary to play with closed source code, but less relevant in Unix. > There was a steganography plugin storing data inside images. A plugin = = > for generation and browsing of file lists. A Java decompiler. And a = > great variety of others. > > Unix file managers offer similar, though not so rich options. Yet I = > think it's not their job. Like with mounting, there's great benefit fr= om = > being able to use standard tools with them. > Some write things like zipfs, but I think it's wrong. > First, typing a command is cumbersome. Second, even if it was automate= d, = > mounting needs a mount point. The only good one is the file itself; = > working with a dozen (or thousand) of archives in a single directory i= s = > a norm for me. Switching dirs back and forth would be very disruptive.= = > Breaks relative paths. And so on. > > 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 ye= t. = > 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 t= oo. > 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? > 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 integra= te = > a significant number of complex libraries to provide sufficient format= = > coverage? Creative ideas. Part of what you want is in fusefs (mounting of files to edit their = content). And part is implemented in e.g. KDE (integrated support for = various file types in fulltext search and tagging of files/metadata, etc= .). The chances of having all these complex libraries integrated in the = FreeBSD OS are close to zero I presume. But I am not in a position to = decide about that. I think you can't expect the OS to serve everybody's detailed wishes. Th= e = OS serves files and user programs know what to do with them. Ronald.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.wsutc5a68527sy>