I have been using Linux for a number of years now. And one of the things that I have carried with me from using Windows, is something that repeatedly bothered me. As many of you know, in Windows, it has been common practice (especially by Microsoft) to repeat multiple directories all beginning with the same prefix in "/Program Files". It was my constant habit whenever I installed new software, to always if possible create a single root/master directory for applications beginning with the same name.

So for instances like Microsoft Windows Media Player, would be changed instead to Microsoft/Windows Media/Player. So Internet Explorer and everything else from Microsoft, would all appear under the /Microsoft directory. The same would be true for Mozilla. Mozilla would occur only once, as a master directory. All of the products of Mozilla would reside within the master directory, /Mozilla. As:
/Mozilla/Firefox
/Mozilla/Thunderbird
/Mozilla/Seamonkey
and so on.

So here I am now using Linux, and find myself even more so annoyed than before with Windows. So for as long as I can remember, I have toyed with the idea of restructuring the filesystem layout. And it seems my ideas are not in the least unique. Gobolinux has in fact attempted doing the very same thing, by having all applications occupying only one directory. No more scattering of files (from a single application) every which way across the entire system. The very thing I've always wanted.

But now you ask, "why don't you use Gobolinux then? Well, for a number of reasons:
1. I use 64bit AMD
2. I am specifically interested in clustering.
3. I want a system that functions primarily as a server.
4. I want a system that is completely multiarch in every capacity.
5. I want a system that provides cross-compilation of every application.
6. I want something that bears familiarity for current Linux users.

Now, that last comment #6 may seem completely non sequitur. But it doesn't have to be. I don't think providing a simplification of the directory structure would make it unnavigable by experienced Linux users.

So now the question is, "what do we have to benefit from this. The answer is simple. It would provide for a unification of all applications conforming to a single more intuitive placement on the user's system.

So then the thought came to me to ask Jamie Cameron, the author of Webmin to provide some help in this matter. Ok, so why Webmin? For those of you who have used it, know that it is the Swiss Army Knife for Linux. There used to be Linuxconf, but that seems to have died. I think the reason behind Webmin's success, has been it's implementation of the webbrowser as it's interface. And it properly interacts with every distribution available. Jamie, wisely didn't set about reinventing the wheel. So now you say, "aren't you trying to reinvent the wheel? Well, yes and no.

I am not so much attempting to design a new wheel, as I am trying to change how we spin it. More appropriately, I'm interested in the drivetrain. It's more like moving from a manual transmission, to a seven speed automatic with paddle shifters (or something along that line). We're still using the same wheel, we'll just have better control over how it provides traction to the user interface.

There are two templates which I think bear consideration. First of all, if Linux is primarily a server environment (being more and more marketed to the desktop), why doesn't it make sense that the system be engaged as a website itself? Since the internet was derived from the Unix filesystem structure, why not turn things around now, and have the system to be browsed as we typically browse the internet?

So here are the two templates I spoke of. Actually, there are many more than just two, but let's start at the beginning, which would be our "/" directory and it's layout. If you're currently using Linux right now, you're likely using either KDE or Gnome as your desktop. And let's not get distracted with how many others there out there, because that discussion is not germane to this topic. I am only looking for examples here. So let's keep to the point. That being an intuitive filesystem which mimics the application menu of most desktops (including Windows).

What I am after, is to turn the operating system into a website. Which means it has to be managed by a reliable webserver. Especially one which has already proven itself as a management tool for our systems. And I don't know of anything more universal than Webmin for this purpose. And since Webmin is already modular, and so easily extendible, why should we (I) waste time trying to find something better.

There is little that would be required for implementing this with Webmin. The first step would be to enhance the categorization of applications within it's directory structure. (There is some duplication of things which need to be changed.) The Webmin web interface has already mostly achieved this. With the new Blue Theme, we have an index tree structure to the left side of our browser. The main categories as they appear there, could be left mostly unchanged. It's only within those categories, that things need tuning.

But for those of us who have looked at the internals of Webmin, know that it doesn't directly reflect the layout of the web interface. So primarily, all of the internals would have to be restructured to conform to the layout of the interface. Secondly, ALL of the components of Webmin would have to be placed in only ONE directory. This may be the highest necessity of all. Because every application that we later install, would be installed in the directory structure of Webmin itself. And just as importantly, Usermin would have to be included within Webmin proper. Each of these two tools, would largely maintain their current function. It's just that Webmin would become our new desktop, and Usermin would function like the user settings in Windows.

What many of us have been familiar with the Control Panel in Windows, would now find that embedded within the application categories itself. It would be like taking the KDE Control Center, and having it's directory layout inline with the categories of the system menu itself. Every category would have it's own Control Panel (as a Settings submenu), which would simply be linked to the settings of the individual applications themselves.

Now, here is where we get into the discussion of the server itself. I want the system to serve as an application server, as with the LTSP (Linux Terminal Server Project). I want every application to be built against every architecture supported by the Linux Kernel. So, this system would be entirely cross-compiled. To manage this, the filesystem would appear as follows:
/Programs/FunctionalGroup/ApplicationGroup/Application/Version/Architecture.
or,
/Programs/$FunGroup/$AppGroup/$Name/$Version/$Arch.

The housekeeping of this done as it appears for many applications already following a similar format in Linux. Some "packages" (especially libraries) need to have multiple versions installed at once (as dependencies for other applications). In my system, that would be the standard, not the aberration. I have $Arch following $Version, because people from any system, are familiar with packages named as $Name-$Version. And since the Linux Kernel is the foundation for everything that is Linux, it also makes sense to follow closely the layout of the kernel itself. So, $Arch follow $Version. Complain about the concept of this system, and you'll be complaining in part about the kernel itself, and many other Linux application which already employ some of the features listed here. No application would ever overwrite the files of another application. No more application conflicts!

So I am posting this in hopes of soliciting suggestions and help in bringing this to reality. Thank you for taking the time to read this. But please, if this is something that you find reprehensible in concept, like some form of blasphemy to you, keep it to yourself. Because your opinions will have no affect in influencing the outcome of this endeavor.

Determined to success,
Xavian-Anderson Macpherson
Shingoshi

I don't think my opionion on this matte counts for a lot, but here goes anyway.

Aside from a basic question of why (and I would think this would want to be answered) and other random thoughts that crop up, this sounds like a nightmare for anyone who doesn't spend all day in a GUI.

Think about the complexity of the path variable in this scenario, or trying to remember where an application (however defined) when trying to write a script or a cron entry.

From my limited knowledge, most application confilcts arise from poor programming and or bad spec'ing in some form. Doesn't having multiple versions of libraries (or did I misread?) simply encourage poor practices, not to mention leading to bloatware?

Yes, I am a GUI adherent. If I weren't, I wouldn't use Webmin. But there is no reason whatsoever, why the equivalent of the Command Prompt can't be provided for everyone at any point in their navigation of the system. Having already stated that Webmin is the intended environment in which everything else would be installed, makes your complaint about a GUI being a nightmare, pointless. My concern, is with the clarity of the desktop, and the integration of the server into the organization of the user's thinking. NOT the integration of the user into the organization of the server's design. People are meant to use computers. Computers aren't meant to use people. And the same goes for definition of functionality as well.

I believe the issue of $PATH, can be resolved with something along the line of;
PATH="$PATH:$DESTDIR/bin

Some (older) applications simply cannot be compiled against newer compilers or libraries. Yes, it may be because of bad practices in how the software was originally written. But the fact is it's still the reality. And complaining about that reality, does nothing to provide the user with what they need, which is a working system that works for them.

I have seen something like this for using binaries and libraries recently compiled, for the compilation of other components in the process. And since our applications would all have a single definition for directory layout, things should be simpler, not more complicated. One of the things that has long annoyed me by so much of the source code I've tried to compile, is the relative disuse of variables that are more universal across multiple platforms. So instead of someone writing; ARCH=I686 (or whatever else the case would be), I see that it should be ARCH=$(uname -m). Writing something that is hardcoded to only one environment is silly (for everyone involved), and should be avoided at all costs.

It would come down to defining and using variables universally throughout the entire system, starting with the writing of software for that system.


Xavian-Anderson Macpherson
Shingoshi

Since the commandline is your primary vehicle, I could leave it to those like you to ensure it functions properly within this system.

Me, I spend my WHOLE day in GUI. Even for the console, I use it in KDE so that I can have multiple consoles in a single window. It's not unmanageable. But to give you some hint as to how I use my computer, I have 20 desktops. Each one has a dedicated function, for performing one task, or a group of them all related to a single function. And yes, I remember where everything is, too.

Shingoshi

Webmin is the System, and the System is Webmin.
Webmin is the System, and the System is Webmin.
Webmin is the System, and the System is Webmin.
Webmin is the System, and the System is Webmin.
Webmin is the System, and the System is Webmin.
Webmin is the System, and the System is Webmin.
Webmin is the System, and the System is Webmin.

Those are your seven steps to heaven!

Shingoshi
ROFLOL!!

I take it post 4 is an acceptance that you misunderstood my comment about GUI's in post 3

There are many Linux users who simply never want to see a GUI. That's fine. But I am not going to try and convince those users to accept this. My concern is with the majority of computer users, who happen to be Windows users. That is my intended target. It always has been. I want to create a system for people who know nothing but GUI. And I'm not going to debate the merit of that.

I have a simple philosophy. You support the majority, you (may) become the majority. Now I realize that is unrealistic in regards to Windows, as Linux will likely never even approach the level of usage as enjoyed by Windows. But I do believe that if you present a system that is more functional to the majority of (Windows) users (when compared to the majority of Linux systems), you will likely have a system which is more preferred by them if switching to Linux from Windows. That is my only concern. Nothing else really matters to me.

So what else do you think I might have missed?

Shingoshi

* Messages for package sci-libs/csparse-2.2.1:

* This package will overwrite one or more files that may belong to other
* packages (see list below). Add "collision-protect" to FEATURES in
* make.conf if you would like the merge to abort in cases like this. You
* can use a command such as `portageq owners / <filename>` to identify
* the installed package that owns a file. If portageq reports that only
* one package owns a file then do NOT file a bug report. A bug report is
* only useful if it identifies at least two or more packages that are
* known to install the same file(s). If a collision occurs and you can
* not explain where the file came from then you should simply ignore the
* collision since there is not enough information to determine if a real
* problem exists. Please do NOT file a bug report at
* http://bugs.gentoo.org unless you report exactly which two packages
* install the same file(s). Once again, please do NOT file a bug report
* unless you have completely understood the above message.
*
* Detected file collision(s):
*
* /usr/include/cs.h


Shingoshi