Linked by Thom Holwerda on Mon 18th Aug 2008 23:33 UTC, submitted by Charles Wilson
Editorial GoboLinux is a distribution which sports a different file system structure than 'ordinary' Linux distributions. In order to remain compatible with the Filesystem Hierarchy Standard, symbolic links are used to map the GoboLinux tree to standard UNIX directories. A post in the GoboLinux forums suggested that it might be better to turn the concept around: retain the FHS, and then use symbolic links to map the GoboLinux tree on top of it. This sparked some interesting discussion. Read on for more details.
Thread beginning with comment 327359
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: My Question
by wannabe geek on Tue 19th Aug 2008 15:25 UTC in reply to "RE: My Question"
wannabe geek
Member since:

osx does the same as android.

basically it straps a whole new ecosystem on top of a BSD kernel and basic tools.

so ones your past the kernel startup your in a whole different world.

These days it seems that many promising approaches to building a new computing environment in the short-to-middle term do not try reimplement everything down to the metal, but instead they use, say, Linux, as a "driver" and then build the environment on top. The advantage is that you can instantly leverage all the Linux drivers, be it FOSS or proprietary, while treating the underlying Unix-like system as a black box, as if it were part of the hardware. A nice example of this approach is the Etoile project. This is an excerpt from their site:

What is CoreObject? Basically, it's a replacement for a filesystem as a programmer and user interface. Files (in the UNIX sense of the word) never were a good abstraction; an untyped series of bytes is no use to anyone. The operating system needs to deal with things like this, but programmers shouldn't have to.

We already have a much nicer abstraction than a file; the object. Unlike files, objects have all of the structure and introspection that we want in order to be able to interact with them programatically. In Etoile, we want to treat everything as an object, and objects as first-class citizens.

When reading this one may think that such a radical departure from the main abstraction of most operating systems means to rebuild everything from scratch. An awful lot of work and no substitute for binary-only drivers. But in fact Etoile is a set of frameworks on top of GNUStep. Files are not eliminated, they are just pushed down in the abstraction hierarchy, so that they become as irrelevant, as transparent, to application programmers as registers and assembler instruction sets are. The crucial point here is that the underlying files are not just hidden from regular users, they are hidden from *everyone*; they are just a convenient backend. That's what makes an abstraction work.

kde is doing the same with their abstractions to exist on top of anything from linux to windows.

KDE4 looks nice. Still, there's the problem that it intends to coexist with other systems that manipulate files in different ways. Think of what happens when you boot from another distro (without KDE) and edit (create, rename, delete) your personal files from there, obviously without the corresponding updates in the Nepomuk database. Of course you could also mess up the CoreObject files of Etoile from another OS (the underlying problem is, I think, computer hardware is not really designed for safe coexistence of different operating systems, otherwise the BIOS would protect the different abstractions ) , but Etoile makes it clear that it's not designed to interoperate in that way.

Edited 2008-08-19 15:27 UTC

Reply Parent Score: 2