Home_greyopenFATE - openSUSE feature tracking > #310515
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Filesystem compatybility layer

Feature state

Rejected Information


Many closed source software are designed to working with only one operating system. Main  problem to creating closed source application to Unix is filesystem hierarchy difference.

We can fix that by using package manager. First of all, RPM's should provide variables for some predefined path, like program data(such like levels), program icons, wallpapers, system-wide configuration, program configuration, etc. There's should exist an library to ask for one of them. It is very similar to XDG_DESKTOP_PATH specification, but much wider.

Second off all we should create /application directory(such like proc) and mount there virtual file system containing links to application resources(in hierarchy defined by package). Mount process would been performed on special library initialization, so application should use special library to be independent.

We can also allow to publish some other information into /application, such like named fifo, new run locking system, etc. /application/pid/resources could contains for example files(name fifo) to be shared between application and another.

User benefit:

Filesystem hierarchy differences are too big matter for developers. We can solve this problem with delivering code source to packagers, but that's no solution for closed source programmers. Imagine developer would prepare application for MacOS X and Linux. Without making rubbish(like in Solaris, which supports many of standards) we can't provide better solution than mine( ;-) ). Developer will compile library with our new Virtual File System library(or better: library providing special interface to asking for information about application virtual filesystem).
Actually it works in this way: file system hierarchy should been fully transparent for user and application will only acts with it.
In my opinion, it's impossible. So makes it different: File System Hierarchy are for administrators, not for applications. User will still don't care about it(it haves /home directory).


Developer would create closed source application, but filesystem hierarchy difference in each system is too big matter for him.

He create his own hiearchy and tell to packagers: do rest of work.


Create OpenSource application, which uses this library. Create a lot of packages without recombiling(one binary file).


icons/user_comment.png J. E. wrote: (8 years ago)

>Developer will compile library with our new Virtual File System library

This reads like legalese, so I respond in legalese: Developer will not.

I see no compelling reason to do anything like this. Especially since there _is_ already, for example, libgnome-vfs2. I don't see why one should use your library over that.

icons/user_comment.png T. E. wrote: (8 years ago)

The difficulties with porting programs from one OS to another go a lot deeper than the filesystem layout. Not to mention that a virtual filesystem layout that presumably mimicked Windows' or OSX's and somehow 'translated' paths onto a Linux layout would be a massive undertaking, if not impractical.

icons/user_comment.png R. D. wrote: (7 years ago)

"Many closed source software are designed to working with only one operating system. Main problem to creating closed source application to Unix is filesystem hierarchy difference."

This core assumption is simply not true, generally a Windows or Java API is what they code to and WINE & java are big projects in their own right, not something solved by a distro.

There's been quite a number of API's (and included with SuSE) featuring compatability between Windows & Linux, how many 'dows programs have you heard of using them?

Even when programs are basically portable, business managers of software do not want to market to minority nor open themselves up to support risks on other OS, which might require staff re-training.

Last change: 7 years ago
Loading tags...
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint