Hisham Muhammad wrote: > Yes, that's the plan. It's a unionfs-style solution, but not using > unionfs directly because it doesn't scale too well for hundreds of > layers (it's just not what it was designed for) and we have some other > stuff in mind related to versioning beyond just merging layers. > That sounds really exciting Hisham. Do you have any details yet, or is it still in the planning stages? By versioning, I assume you mean program versions? Does that mean you'll lose the subdirectories in the program dirs? I think this would be a good step. Personally, I'd prefer giving my program dirs different names for each version, or having the option of moving them into subdirectories myself. > Yes, ChrootCompile produces a package (Foo--1.0--i686.tar.bz2) which > should then be installed into /Programs. > That's great. I'd also really love it if it were possible to ChrootCompile programs as an unprivileged user. Is there any reason that's not possible, given that we're building in a fake root anyway? That way we can build a package and either run it as an unprivileged user, or install it as root for everyone to access...
I would love for packages to be mounted/merged into the system from anywhere. That is, for there to be no need for InstallPackage, because the program will run directly from a package once it's built. It would be great if unzipping were optional, but that's certainly not essential. What I mean is, you build the package, then run something like MountProgram MyProg or MountProgram MyProg.tar.bz2 and it's on the path straight away. I'll introduce one more concept into the mix here. I may be going mad here, but I find it a fascinating idea. Now ChrootCompile compiles programs in an environment where only the programs it depends on exist, correct? Well when you run a program, it needs access to only the programs & libraries it depends on, plus data files. Now I realise there may be overheads here, but what do you think of the concept of having a separate set of "mounted" programs for each program that is run? (That is, using the current system as an analogy, each program has a different view of /Programs.) That way, we could unclutter the PATH, which is a problem that I still have with all Linux distros. We can then run, say, two versions of GCC, just by opening two consoles, doing MountProgram for a different GCC in each, then entering gcc as normal. The two will not conflict with each other because they are in different namespaces, so to speak. When a certain program becomes highly depended on, we could move it to, say, /System/Programs, which would contain programs that are automatically mounted into every program's environment. Most useful command-line programs would end up in /System/Programs, whereas applications like GIMP or Firefox would stay in /Programs (which could maybe be renamed /Applications in view of the change). When you open a console, all programs in /System/Programs would be on the path, but to load an application, you would have to do: $ MountProgram /Applications/Firefox $ firefox This idea further promotes the concept of separate programs, hopefully without creating a huge impact on command-line operations. > Comparing ourselves to these alternatives, I think we have the > concepts laid out pretty well; we just need to keep working on the > implementation. > Without a doubt, GoboLinux is the closest thing to a user-friendly and intuitive Linux desktop that I have ever found, because you have started by changing the underlying system into something understandable and maintainable, and have not resorted to just abstracting it with countless utilities that limit the user's possibilities. Thank you all so much for the time and effort you have put in so far :) Paul
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
