The main problems are that people don't understand, or are confused by:
a) The references to derivative works - what exactly is a derivative work? How can you tell?
b) The meaning of redistribution.
The whole Java/LGPL thing was a storm in a teacup caused by people who didn't understand the wording or the spirit of the license.
I sometimes wonder if it's due to the nature of the people involved. Programming is sometimes an sexact and inflexible science - literality is important. The law on the other hand is anything but those things.
So, for instance, I've seen people wrangle and argue over exactly what is and isn't linking, without realising that this is beside the point - the LGPL is very clear that if you use the code in your program, the user should be able to drop in a replacement they compiled themselves - otherwise, what is the point of having the source (for the user) if they are powerless to use it to improve their own apps? In standard C or C++ apps, static linking prevents the user from doing that, so you can't do it (or rather, you must offer a version that uses dynamic linkage). In Java, all linkage is dynamic, so as long as the user can drop in a new jarfile, or set of classes, you're set. In Python etc, you're almost always compliant even if you embed the code direct into the source files, because the user can still go in an edit those parts. At least, that's *my* interpretation.
Likewise, I've seen people say you can't link GPLd code with anything other than a GPLd program - also rubbish. Any GPL compatible license will do.
Basically people forget that licenses are agreements between the author of the code, and themselves. The author expresses their wishes for how the code can be used, and you must abide by those wishes. The GPL/LGPL/BSD and so on are just useful boilerplates to save people reinventing the wheel. You can always ask the copyright holder to grant you a commercial license if you want to use some GPLd code - they may so no, but also they may not.
Out of all the projects Apple has used, FreeBSD is easily the worst off. Other than lots of free publicity, KHTML and gcc have all had far more code given back to them, even if it is in the form of almost-unmanageable patch dumps.
I do sometimes. While I'm inside the realm of websites created by people who know what they're doing, I'm OK. All too quickly though, if I want to buy something, visit some hobbyist website, or a promo site for some new film/game, I can still find myself lost in a morass of IE only code.
It's not especially pleasant, especially when I remember that MOST people use this part of the web ALL the time. Gecko following the standards was the right thing to do, and I don't think I'll ever criticize them for that. But, unfortunately the days of the IE only web are not over yet.
* The number of volunteer Moz hackers eclipsed the number of Netscape hackers last month.
* Quite a few of the core hackers are already being picked up by IBM, Sun and Red Hat.
I expect Moz will mature into a true open source project - heavily funded by a variety of sources, with a strong community of volunteers to back it up. This is for the best - I'm never comfortable with projects dominated by corporate hackers. Do you think OpenOffice would survive if Sun dropped it tomorrow? No, it has no community.
Mozilla has, and that's really amazing. It's gone from corporate product, to a projec truely owned and developed by society. It'll be OK.
I guess it just means that if you use AOL on Longhorn, you get the new IE embedded, otherwise you get the old IE. The interfaces have hardly changed since the IE4 days, I doubt it'd be hard to engineer.
Like a lot of journalists, lacking a take on a juicy story, they have to steal one from elsewhere. The "it took too long because they started again" line has been done to death. The fact is, that they had no choice.
Would people really be praising Netscape/AOL instead if they had constantly hacked the limping, near dead Communicator codebase? Would we really be pleased that the two most popular browsers BOTH sucked at standards compliance? Is a 20%/80% market share split OK, when they are both as bad as each other?
The fact is that the moment Microsoft decided to kill Netscape, they were dead. I've seen many suggestions about what they should have done, but the fact is that none hold water. If they hadn't started over, they'd have still lost, because IE was better engineered, had more resources and so on. If they had started over but not used XUL, XPCOM or NSPR Mozilla would have been Windows only. It would have minimal marketshare on Windows, as opposed to having nearly 100% marketshare on Linux.
As it is, they started over, and took their time about it, and made something good.
I'm not convinced that they'd have more market share even if they had carried on using the old 4.x codebase really, at least this way Mozilla/Firebird has legions of geek fans who are spreading the word, as opposed to dumping all over it like they used to.
Poor old Netscape - put in a lose/lose scenario, they lost. You have to give them some credit for making the best of a bad situation. That's something most journalists won't say though, it's realistic and therefore boring.
Indeedy. It's easy to forget how hard it is to make a decent browsing engine. For instance, Safari has BIG problems with pages not laying out correctly because the Aqua form controls are not scalable, and websites are written assuming they are (because in the specs they are, and the Win32 widget toolkit that IE uses are too).
It's tempting to trash XUL and the rewrite, but without it, there would be no Mozilla on Linux. And anyway, I'm writing this from Firebird, which is using GTK2 on Linux and is absolutely beautiful. It fits in smoothly and cleanly with my environment. All it needs it to use some nice GTK stock artwork in the menus.....:)
Yay free software. They ended up spending millions of dollars more over the Microsoft package.
Yes, however they got a lot more for their money (in terms of software, support and local employment) and this was only after Microsoft gave large discounts.
I'm sure training and attrition will offset whatever benefits they could have realized by avoiding the "forced upgrades", which SuSe will most certainly start doing eventually when they come to their senses, just like RH did.
The effort to switch from SuSE Linux to Red Hat Linux, or to Mandrake, or to MunichCity Linux, is very very low. Not nil, but low. So, if SuSE or IBM did try and screw them, they could go elsewhere.
Despite that, I don't understand how upgrades are forced. You can still download very old, unsupported versions of Red Hat Linux. If you're referring to the "only 12 months of free errata" thing, then who cares? RHL is meant for developers and home users now, not servers or corporate desktops. I know people still running on RH 7.1, they aren't dead yet.
I think it's rather disingenuous to jump from that to "forced upgrades". If I could still buy Windows 98 then maybe you could also argue that Microsoft don't try and force upgrades, but you can't....
The vote was 50-30. Doesn't seem to me like an "overhelming" victory. Well, I guess it depends who you're rooting for.
I think it was meant in the sense of "overcame overwhelming odds" - ie Microsoft, Ballmer himself, offers very large discounts, you've got all the inertia and proprietary lockin there, and still Linux won out. Not in terms of vote numbers.
It's not discoverable though. How is anybody supposed to guess that they can attach this file by sticking a # on the end?
Obviously you can have mail apps, browsers etc doing all this automatically, it was more a description of how it could work for times when it's not automatic.
That kind of thing would benefit from this, especially if integrated into the GUI in a nice way.
In effect, it'd be similar to what Linux does with memory - empty disk space is useless! What is the point of that? Might as well use it for something. Storing old versions of files is an ideal use for it, and combined with an LVM means that the more space you have, the further back in time you can go. That's far more flexible and useful than storing stuff in a recycle bin.
Of course, you run into problems straight away if you aren't using lots of small files. Are you really going to store a new copy of that 5meg presentation every time you hit save? Bad idea. You only want to store what has changed.
But - how? Doing it with text is easy enough, we have diff and patch for that. But what about more complex formats?
Ahhh, now we understand why minimizing primitives is useful in the real world. If the internal structure of a file is split into many small files, each representing a facet of the presentation (each slide, each bullet point on the slide, font weight of that bullet point etc) then suddenly it becomes much simpler to write a generic differential analyzer, we can just snapshot the mini files that changed.
As a result, we increase efficiency to a level at which it becomes feasable to keep the undo transaction buffer on disk - just imagine how much hassle we'd save if all apps used this reliably?
There are still plenty of details missing of course - some things still wouldn't work well, in particular large BLOBs with no structure, like say images, or audio files. I guess if you were smart you could leverage the apps transaction buffer, but still..... that would lead to interop problems.
Still, there are many unexplored possibilities that appear when you increase the abilities and even efficiency of low level parts of the OS like this.
Ah, no, in no way does OLE Structured Storage compare to this.
For starters, the MS compound document file format is a very poor reimplementation of a filing system in a file. Why reinvent the wheel like this? Because the filing system layer didn't provide what they needed.
Unfortunately, OLESS is kind of a text book example of how not to design a filing system. It's opaque to the normal APIs, you have to access it using COM. The files contain large strips of garbage for compatability with earlier, buggier versions. The format is inefficient and limited, and you lose the benefits of things like fine grained security and journalling.
Basically, the whole point of things like ReiserFS is to eliminate pointless reinventing of the wheel like this, by adding the features that caused the invention of these formats to the filing system itself.
*shrug* I dunno. Walk before you can run and all that - I don't even know if the files/directories thing will actually be in Reiser4.
Last I heard, there was going to be a special system call that you could use to access the special features, but standard POSIX users wouldn't see them (which makes sense).
So, really, not much will change at first. All these things, if they happen, will be very gradual.
Yeah, but it doesn't really need the co-operation of anybody else to be useful. A filing system upgrade would improve things immensely on Linux at any rate, even if it wasn't portable to Windows or MacOS.
I guess the main problem would be that projects like KDE/Gnome wouldn't be willing to lose portability to forms of Unix that sucked at small files, needing layers of abstraction and so on. OTOH that causes problems just with Linux integration, it's just one of the balances people have to make.
Oh, I should probably mention - if you read the whitepapers available on ReiserFS the "foo/..attr" syntax is just a toy, made up on the spot, syntax to demonstrate the idea of files within files.
Nobody (apart from perhaps this guy) has ever claimed that this syntax will actually ever be used, or needed. There are other possible syntaxes available, and in fact one long term blue sky plan for RFS is to allow many different types of syntax within the same file path, including for instance things that vaguely resemble database queries.
So, don't get hung up on the syntax given in this article.
Nothing is stopping Microsoft from implementing support for the same technologies.
After all, if a few volunteers can implement NTFS support in Linux with no source and no specs, then Microsoft with all its manpower can certainly add support for Reiser4 to Windows when they have the source and specs (and maybe HR would be willing to support them, for the right price).
Basically, it's a non-issue in my books. It's like people who are "locked in" to Word, because they use advanced features available nowhere else. Well, that's the decision you make, isn't it.
Re:How about fixing the current filesystems?!
on
State Of The Filesystem
·
· Score: 4, Informative
I'd really like to know why this driver has taken so long to complete - is there some information that the developers don't have access to? Some technical reason? What?!
Yes. They don't have access to the NTFS specs. Also, NTFS is a very complex filing system, with many different versions. You don't want to get that wrong. Resizing was a more important goal, and that has been working for many months now.
Of course, it might be included in all distros when completed anyway, due to patents MS hold on the technology.
I think people are distracted by the examples he gave, which make the point clear but are perhaps not representative of what this would be used for in real life.
GConf was a better example. ATM using GConf is, well, not hard, but you have a lot of extra machinery involved, new APIs to learn and so on. Basically all that machinery does is control the backends and give change notification (it does stuff like schema validation as well).
It'd be *much* easier to use GConf if in order to read a value, you didn't have to load up the GConf libs (which in turn depend on CORBA), or parse XML files. At the moment that's really the only way to do it, but in most environments/languages it's far easier to manipulate files and directories than it is to talk to a CORBA server or bind APIs into them.
You also get an increase in efficiency. Parsing XML is kind of cludgy - XML is not a particularly efficient format to store stuff in. It's a good compromise between humans and machines, but both of us have to do lots more work to meet in the middle. The reason it's used, rather than lots of small files, is that otherwise GConf would be too slow. In fact, they are already talking about removing yet more of the files/directories to speed things up, and sticking them all in the same XML file.
Being able to have a configuration system that truly leveraged the filing system would make a lot of stuff easier, more reliable, and faster (because you can take advantage of filing systems that are really really tuned to take advantage of advanced data structures).
It won't really impact the way you do things like set file attributes today. Most of the changes would be under the hood. But used well, everything would become easier for the developers, and so more advanced and slicker for the user.
It doesn't tell you anything you can't already learn by reading up on the articles on Plan 9 and the whitepapers on namesys.com, but it's a well written compressed version for those who perhaps don't want to wade through a description of set theoretic namespaces (whatever they are;)
The concept of reducing primitives is a good one, and based in sound mathematical theory. As already pointed out though, you need some container format that can handle some of these new ideas, things like very small files, files as directories and so on. This is needed, because when you transfer files through lossy mediums like the internet, or older filing systems, you don't want to lose the structure.
As far as I know, there isn't a container format that can do this. Tar is showing its age already, I wouldn't like to see it hacked yet again. Zip is alright, but you'd need to break compatability to add in all those extra features, and then it wouldn't be zip anymore. It'd also be inefficient.
So, what I propose is rather than reinvent the wheel to solve this problem, we add support for "boxing" to the Linux kernel.
A box is a filing system in a file. We already use them, to some extent - it's been possible to mount ISO images using the loopback filing system for a while. What's needed is to take this to the next level. The first thing is that we need the ability to use files as mount points, not just directories. When files and directories are the same, well, I guess that should be easier.
The.box file format simply contains a short header with some useful metadata, like maybe a checksum, and the filing system it contains (maybe that isn't needed). The fun part is the UI. What you need is the ability to right click on any dirfile (for want of a better term) and choose the "Box it" option. You'd need a better label. What essentially happens then is that the heirarchy below this point is sucked up and transformed into an ISO containing perhaps a "Reiser4-Lite" filing system. You can forgo the journal and other things that are redundant purely for storage.
The user has then converted their file or directory into something that can be transferred across the net, on Windows compatible CDs and so on, without losing the inherant structure of the original.
At the other end, choosing the "Unbox" option mounts the contents of the box using the loopback FS, mounted at the point of the file. To the user, it is seamless, far easier than zips or tarballs.
Of course, there are lots of complications. You have to agree on the format to use inside the box, for one, because the need to have kernel mods and so on makes it more complex than just installing tar.
I think MacOS has something a little bit similar with disk mountable images (.dmg) files, but the MacOS filing system is rather poor, and I don't know how easy it is for users to create them. Also the OS unfortunately applies some magic to them - for instance Safari will automatically extract the contents of the DMG file then destroy it when you download one (but other stuff does not, oops).
Anyway. That's one way to prevent loss of vital structure when transferring across lossy mediums, that I can think of. There are probably others.
Slashdot Mirror
a) The references to derivative works - what exactly is a derivative work? How can you tell?
b) The meaning of redistribution.
The whole Java/LGPL thing was a storm in a teacup caused by people who didn't understand the wording or the spirit of the license.
I sometimes wonder if it's due to the nature of the people involved. Programming is sometimes an sexact and inflexible science - literality is important. The law on the other hand is anything but those things.
So, for instance, I've seen people wrangle and argue over exactly what is and isn't linking, without realising that this is beside the point - the LGPL is very clear that if you use the code in your program, the user should be able to drop in a replacement they compiled themselves - otherwise, what is the point of having the source (for the user) if they are powerless to use it to improve their own apps? In standard C or C++ apps, static linking prevents the user from doing that, so you can't do it (or rather, you must offer a version that uses dynamic linkage). In Java, all linkage is dynamic, so as long as the user can drop in a new jarfile, or set of classes, you're set. In Python etc, you're almost always compliant even if you embed the code direct into the source files, because the user can still go in an edit those parts. At least, that's *my* interpretation.
Likewise, I've seen people say you can't link GPLd code with anything other than a GPLd program - also rubbish. Any GPL compatible license will do.
Basically people forget that licenses are agreements between the author of the code, and themselves. The author expresses their wishes for how the code can be used, and you must abide by those wishes. The GPL/LGPL/BSD and so on are just useful boilerplates to save people reinventing the wheel. You can always ask the copyright holder to grant you a commercial license if you want to use some GPLd code - they may so no, but also they may not.
Out of all the projects Apple has used, FreeBSD is easily the worst off. Other than lots of free publicity, KHTML and gcc have all had far more code given back to them, even if it is in the form of almost-unmanageable patch dumps.
I do sometimes. While I'm inside the realm of websites created by people who know what they're doing, I'm OK. All too quickly though, if I want to buy something, visit some hobbyist website, or a promo site for some new film/game, I can still find myself lost in a morass of IE only code.
It's not especially pleasant, especially when I remember that MOST people use this part of the web ALL the time. Gecko following the standards was the right thing to do, and I don't think I'll ever criticize them for that. But, unfortunately the days of the IE only web are not over yet.
* The number of volunteer Moz hackers eclipsed the number of Netscape hackers last month.
* Quite a few of the core hackers are already being picked up by IBM, Sun and Red Hat.
I expect Moz will mature into a true open source project - heavily funded by a variety of sources, with a strong community of volunteers to back it up. This is for the best - I'm never comfortable with projects dominated by corporate hackers. Do you think OpenOffice would survive if Sun dropped it tomorrow? No, it has no community.
Mozilla has, and that's really amazing. It's gone from corporate product, to a projec truely owned and developed by society. It'll be OK.
I guess it just means that if you use AOL on Longhorn, you get the new IE embedded, otherwise you get the old IE. The interfaces have hardly changed since the IE4 days, I doubt it'd be hard to engineer.
Would people really be praising Netscape/AOL instead if they had constantly hacked the limping, near dead Communicator codebase? Would we really be pleased that the two most popular browsers BOTH sucked at standards compliance? Is a 20%/80% market share split OK, when they are both as bad as each other?
The fact is that the moment Microsoft decided to kill Netscape, they were dead. I've seen many suggestions about what they should have done, but the fact is that none hold water. If they hadn't started over, they'd have still lost, because IE was better engineered, had more resources and so on. If they had started over but not used XUL, XPCOM or NSPR Mozilla would have been Windows only. It would have minimal marketshare on Windows, as opposed to having nearly 100% marketshare on Linux.
As it is, they started over, and took their time about it, and made something good.
I'm not convinced that they'd have more market share even if they had carried on using the old 4.x codebase really, at least this way Mozilla/Firebird has legions of geek fans who are spreading the word, as opposed to dumping all over it like they used to.
Poor old Netscape - put in a lose/lose scenario, they lost. You have to give them some credit for making the best of a bad situation. That's something most journalists won't say though, it's realistic and therefore boring.
A lot of people worked on the Netscape portal, from what I remember.
It's tempting to trash XUL and the rewrite, but without it, there would be no Mozilla on Linux. And anyway, I'm writing this from Firebird, which is using GTK2 on Linux and is absolutely beautiful. It fits in smoothly and cleanly with my environment. All it needs it to use some nice GTK stock artwork in the menus..... :)
Wow. That sounds totally rockin. The GIMP of DTP is here people, now rejoice and make merry :)
Yes, however they got a lot more for their money (in terms of software, support and local employment) and this was only after Microsoft gave large discounts.
I'm sure training and attrition will offset whatever benefits they could have realized by avoiding the "forced upgrades", which SuSe will most certainly start doing eventually when they come to their senses, just like RH did.
The effort to switch from SuSE Linux to Red Hat Linux, or to Mandrake, or to MunichCity Linux, is very very low. Not nil, but low. So, if SuSE or IBM did try and screw them, they could go elsewhere.
Despite that, I don't understand how upgrades are forced. You can still download very old, unsupported versions of Red Hat Linux. If you're referring to the "only 12 months of free errata" thing, then who cares? RHL is meant for developers and home users now, not servers or corporate desktops. I know people still running on RH 7.1, they aren't dead yet.
I think it's rather disingenuous to jump from that to "forced upgrades". If I could still buy Windows 98 then maybe you could also argue that Microsoft don't try and force upgrades, but you can't....
The vote was 50-30. Doesn't seem to me like an "overhelming" victory. Well, I guess it depends who you're rooting for.
I think it was meant in the sense of "overcame overwhelming odds" - ie Microsoft, Ballmer himself, offers very large discounts, you've got all the inertia and proprietary lockin there, and still Linux won out. Not in terms of vote numbers.
Thanks for clearing that up. Good to see you taking part in these discussions Hans! :)
No, the slowness comes from the overhead involved in locating the area of the file on disk and seeking the head to it.
Obviously you can have mail apps, browsers etc doing all this automatically, it was more a description of how it could work for times when it's not automatic.
That's why diff/patch doesn't record each line that changed, they have quite advanced fuzzy matching, to increase efficiency.
In effect, it'd be similar to what Linux does with memory - empty disk space is useless! What is the point of that? Might as well use it for something. Storing old versions of files is an ideal use for it, and combined with an LVM means that the more space you have, the further back in time you can go. That's far more flexible and useful than storing stuff in a recycle bin.
Of course, you run into problems straight away if you aren't using lots of small files. Are you really going to store a new copy of that 5meg presentation every time you hit save? Bad idea. You only want to store what has changed.
But - how? Doing it with text is easy enough, we have diff and patch for that. But what about more complex formats?
Ahhh, now we understand why minimizing primitives is useful in the real world. If the internal structure of a file is split into many small files, each representing a facet of the presentation (each slide, each bullet point on the slide, font weight of that bullet point etc) then suddenly it becomes much simpler to write a generic differential analyzer, we can just snapshot the mini files that changed.
As a result, we increase efficiency to a level at which it becomes feasable to keep the undo transaction buffer on disk - just imagine how much hassle we'd save if all apps used this reliably?
There are still plenty of details missing of course - some things still wouldn't work well, in particular large BLOBs with no structure, like say images, or audio files. I guess if you were smart you could leverage the apps transaction buffer, but still..... that would lead to interop problems.
Still, there are many unexplored possibilities that appear when you increase the abilities and even efficiency of low level parts of the OS like this.
For starters, the MS compound document file format is a very poor reimplementation of a filing system in a file. Why reinvent the wheel like this? Because the filing system layer didn't provide what they needed.
Unfortunately, OLESS is kind of a text book example of how not to design a filing system. It's opaque to the normal APIs, you have to access it using COM. The files contain large strips of garbage for compatability with earlier, buggier versions. The format is inefficient and limited, and you lose the benefits of things like fine grained security and journalling.
Basically, the whole point of things like ReiserFS is to eliminate pointless reinventing of the wheel like this, by adding the features that caused the invention of these formats to the filing system itself.
Last I heard, there was going to be a special system call that you could use to access the special features, but standard POSIX users wouldn't see them (which makes sense).
So, really, not much will change at first. All these things, if they happen, will be very gradual.
I guess the main problem would be that projects like KDE/Gnome wouldn't be willing to lose portability to forms of Unix that sucked at small files, needing layers of abstraction and so on. OTOH that causes problems just with Linux integration, it's just one of the balances people have to make.
Nobody (apart from perhaps this guy) has ever claimed that this syntax will actually ever be used, or needed. There are other possible syntaxes available, and in fact one long term blue sky plan for RFS is to allow many different types of syntax within the same file path, including for instance things that vaguely resemble database queries.
So, don't get hung up on the syntax given in this article.
Uh, nobody said that'd be the user interface you use. It's simply an implementation detail.
After all, if a few volunteers can implement NTFS support in Linux with no source and no specs, then Microsoft with all its manpower can certainly add support for Reiser4 to Windows when they have the source and specs (and maybe HR would be willing to support them, for the right price).
Basically, it's a non-issue in my books. It's like people who are "locked in" to Word, because they use advanced features available nowhere else. Well, that's the decision you make, isn't it.
Yes. They don't have access to the NTFS specs. Also, NTFS is a very complex filing system, with many different versions. You don't want to get that wrong. Resizing was a more important goal, and that has been working for many months now.
Of course, it might be included in all distros when completed anyway, due to patents MS hold on the technology.
GConf was a better example. ATM using GConf is, well, not hard, but you have a lot of extra machinery involved, new APIs to learn and so on. Basically all that machinery does is control the backends and give change notification (it does stuff like schema validation as well).
It'd be *much* easier to use GConf if in order to read a value, you didn't have to load up the GConf libs (which in turn depend on CORBA), or parse XML files. At the moment that's really the only way to do it, but in most environments/languages it's far easier to manipulate files and directories than it is to talk to a CORBA server or bind APIs into them.
You also get an increase in efficiency. Parsing XML is kind of cludgy - XML is not a particularly efficient format to store stuff in. It's a good compromise between humans and machines, but both of us have to do lots more work to meet in the middle. The reason it's used, rather than lots of small files, is that otherwise GConf would be too slow. In fact, they are already talking about removing yet more of the files/directories to speed things up, and sticking them all in the same XML file.
Being able to have a configuration system that truly leveraged the filing system would make a lot of stuff easier, more reliable, and faster (because you can take advantage of filing systems that are really really tuned to take advantage of advanced data structures).
It won't really impact the way you do things like set file attributes today. Most of the changes would be under the hood. But used well, everything would become easier for the developers, and so more advanced and slicker for the user.
The concept of reducing primitives is a good one, and based in sound mathematical theory. As already pointed out though, you need some container format that can handle some of these new ideas, things like very small files, files as directories and so on. This is needed, because when you transfer files through lossy mediums like the internet, or older filing systems, you don't want to lose the structure.
As far as I know, there isn't a container format that can do this. Tar is showing its age already, I wouldn't like to see it hacked yet again. Zip is alright, but you'd need to break compatability to add in all those extra features, and then it wouldn't be zip anymore. It'd also be inefficient.
So, what I propose is rather than reinvent the wheel to solve this problem, we add support for "boxing" to the Linux kernel.
A box is a filing system in a file. We already use them, to some extent - it's been possible to mount ISO images using the loopback filing system for a while. What's needed is to take this to the next level. The first thing is that we need the ability to use files as mount points, not just directories. When files and directories are the same, well, I guess that should be easier.
The .box file format simply contains a short header with some useful metadata, like maybe a checksum, and the filing system it contains (maybe that isn't needed). The fun part is the UI. What you need is the ability to right click on any dirfile (for want of a better term) and choose the "Box it" option. You'd need a better label. What essentially happens then is that the heirarchy below this point is sucked up and transformed into an ISO containing perhaps a "Reiser4-Lite" filing system. You can forgo the journal and other things that are redundant purely for storage.
The user has then converted their file or directory into something that can be transferred across the net, on Windows compatible CDs and so on, without losing the inherant structure of the original.
At the other end, choosing the "Unbox" option mounts the contents of the box using the loopback FS, mounted at the point of the file. To the user, it is seamless, far easier than zips or tarballs.
Of course, there are lots of complications. You have to agree on the format to use inside the box, for one, because the need to have kernel mods and so on makes it more complex than just installing tar.
I think MacOS has something a little bit similar with disk mountable images (.dmg) files, but the MacOS filing system is rather poor, and I don't know how easy it is for users to create them. Also the OS unfortunately applies some magic to them - for instance Safari will automatically extract the contents of the DMG file then destroy it when you download one (but other stuff does not, oops).
Anyway. That's one way to prevent loss of vital structure when transferring across lossy mediums, that I can think of. There are probably others.
Ah hum, use of vertical panes has been around for a looong time in user interfaces - see, for instance, xtree.