Slashdot Mirror

Gobolinux has directories named after programs and keeps all the program's files in a subdirectory named after the version of the program. Various symbolic link tricks are used to allow programs to see other programs' libraries and such. You can just rm -rf a program directory to remove the program as long as no other program depends on it. They include a script to determine a programs dependencies so running that script over all the programs and grepping the output to see if anything depends on a particular program is pretty easy. You can not move programs around like you can on the Mac because linux programs are not really designed that way. They internally refer to the location of other programs and even themselves in all sorts of ways. The only program I am aware of that can be moved like that is OpenOffice.org. There is another one, but I can not think of it right now.

Another example of the strengths of many distros for many needs. ;-) A one or even 5-distro world wouldn't be able to have such cool projects.

see Gobo Linux

Pardon the long post, but I feel there are several things to comment on here

Playing videos on Windows is even easier than that. You just download ffdshow and ac3codec, and you're set. You can then play divx, xvid, any mpeg, and lots of raw format files with complete hardware acceleration (regardless of video card, as long as it's less than 6 years old). The ac3codec gives you ac3 sound, which as it's a directshow filter, gives you hardware-accelerated sound. That's it. Two files you have to run. The player is built into windows (and does a fine job).

You've got two packages (ffdshow, ac3codec), we've got two packages (mplayer, "essential" codec package). Will yours play Quicktime and Real files with just those two packages?

I don't know if I would tout the media player being built in as a good thing. More than once, that built-in media player has opened the rest of the OS (including IE) to attack.

I'm not really going to address the directory structure issue. The standard linux structure is a bit arcane. There is a linux which is working at more readable directories... GoBoLinux

I've seen kde and pretty much everything else you can name, and there are always MANY apps (even ones that come WITH the OS) that seem to ignore the skins completely. They break the consistency. Of course you get them with Windows, too, but not included, and you rarely come across any. That's my point. Until most things actually look the way you intend, it's going to take a back seat. The public is fickle.

This is where most of the linux people say the same thing: that's because not much comes with Windows, whereas all kinds of third party apps come with your standard Linux distribution. All the KDE software looks like KDE, which is a more fair comparison.

There are, of course, apps that don't look just like your desktop. That's partially because of the KDE/GNOME difference. RedHat is making decent progress towards a solution for this.

You can't remove IE from Windows, as IE has lots of functionality Firefox doesn't. IE is available to the rest of the OS via COM object, activeX and DLLs, whereas firefox isn't. Windows relies on that to generate HTML previews, and render all the HTML-based content in Windows. That's quite a bit, seeing as Windows' native help format is based on HTML.

Interestingly, a lot of KDE apps use KHTML to do their HTML work. This is the same as the above problem, but with one key difference: most of those apps can be told to use Mozilla (firefox, if you like) instead, from one KDE control panel.

It is easily argued that, like the WMP problem above, that IE being so tightly integrated isn't a bonus. Again, this integration of non-OS-component/OS just means that problems in the non-OS-component hit the user harder. Of course, this has to be weighed against the problem of every app wanting HTML rendering... the market seems to have decided that it's worth the risk.

I've never had any products on windows screw up the OS to the point of re-installation. Ever. I can't imagine where you even pulled that one from. As for linux, it's a whole lot easier. As most apps have files spanning multiple directories and dependencies across the whole system, it's easy for an errant install to remove (or overwrite) something another app depends on. The sprawling dependency means the system is unstable. You can't deny that - linux's dependencies are a weakness as well as a strength.

Well, you're not in the majority if you've never hosed a Windows install. The problem you're talking about with Linux is solved by one common thing: a decent package manager. Gentoo, for instance, won't allow a package to overwrite another package's configuration files or binaries. Everything else is put in directories that are structured in such a way that they can't overwrite others (/usr/local/doc/packagename-packageversion/, as an example).

I do have objectivity.

I know at least two Linux distros that are going to attempt to fix this, GenSTEP and Komodo

There's also Gobolinux.

Are you crazy? I've never seen a release of any package, no matter how minor, that wasn't in the portage tree within a few hours. You probably have "testing" packages masked, as they are by default. Turn off your masking, and emerge sync more often.

[* OT -- the one other Gentoo weakness I've found thus far is that it seems like it will be more fragile across upgrades. Gentoo users are cautious about upgrades,

WHAT? Most gentoo users I know are upgrade addicts -- every day, twice a day if they're bored. I mean, it only takes "emerge sync" followed by "emerge --update world." And that's why you never need to reinstall gentoo -- a simple emerge makes it identical to the latest release.

whereas Debian unstable users tend to upgrade constantly and without much concern. That factor will probably lead to my Gentoo system lagging even further behind my Debian unstable systems. Ah, well, nothing's perfect. ]

You cause me much bemusement. I don't use gentoo, being a Gobo person myself, but your words were ridiculous.

Actually there are symlinks to each package's bin, lib, share, man and so on, on a directory called /System/Links/{Executables,Libraries,Shared,...}. This allows programs to be found by other packages in the same way that standard distributions do with their LD_LIBRARY_PATH and PATH variables.

The difference, so, is that on GoboLinux everything is self-contained on its own directory, allowing a very clean vision of the entire system without breaking any kind of compatibility.
Please give a look at the GoboLinux website ( http://gobolinux.org ) and give a look on the Documentation section to take a good overview of the system itself.

As far as I can see by browsing a few recipes from your repository, you have not developped a special scripting language for it. It's simply bash scripts, with facilities through the usage of common variable and functions that trigger different behaviors.

If I take Armagetron recipe, for instance, it's not really that user-friendly in my opinion. Or, at least, not really more user-friendly than a Gentoo ebuild. Okay, the armagetron ebuild is longer, but it also contains more meta-data (dependences, license, architecture, etc) and it obviously has to install the program in the standard Unix file tree.

So basically, Compile looks like a lighter version of ebuild, but it is certainly not a revolution in the way you have to write the recipe/ebuild. I think GoboLinux looks different enough to make me try it one day, but in my opinion, the recipes do not improve much (assuming they do at all) from the Gentoo ebuilds to be as user-friendly as the inial poster said.

Disclaimer: yes I'm a Gentoo user, but still, kudos to the GoboLinux devs for making it happen anyway !

If you RTFFAQ here, you'll notice that they still use /usr, /bin /sbin, /etc etc. (hehe) as symlinks to their new, fancy directories.

It actually is pretty clever the way they've laid it all out, except for that fact that it totally screws up non-English speakers. Three letters of gibberish is a lot easier to learn and remember than fourteen. Also, three is (probably not coincidentally) the magic number past which humans' ability to remember patterns generally drops off very quickly.

Isn't making an interface usable something interesting? Something challenging? Aren't challenges something geeks do well? Ignore Microsoft. Why not make the best interface that can be made? It'll take time but it'll arrive. I'd like to see lots of distributions with a strong core feature set to each of them, but with each carrying an ever varying application set. Think KDE on a large scale.

What I find interesting is that whenever someone says "usability" and "linux", people automatically assume "the graphical interface".

How about the rest? A well thought out OS, as far as usability is concerned, is thought so from the ground up.

Pardon me, but I'm going to point at Mac OS X. It's definitely not just the interface that's different, that's just the icing on the cake. The underlaying OS is vastly different from your average Linux distro, because the way it is organized. It has to do with everything: the bootscripts, the security, the application packaging, the filesystem organization, etc.

Think about it: those guys at Apple probably sat down and said "let's make it easy on the user", then they started doing things more or less from scratch. Only some of the people who contribute to Linux give a thought to the basic design principles that Linux is organized upon. No I don't mean the freaking graphical interface, I mean everything. The result is obvious.

The Linux heritage is UNIX, which has always been a black hole of usability. UNIX was always an OS designed by the extra-power users for other extra-power users. Naturally, Linux inherits all the flaws in it.

Frankly, I think it will take something like 10 or 20 years for Linux to become usable (you know what I mean by usable, don't start nitpicking please) and impose itself on the market. If it won't be too late by then. Why? Because companies like Apple and Microsoft can afford to redesign the entire operating system every few years. Think about how the Windows systems have evolved, or how Mac did. Eventually, one of these summers, you're going to look at the new Windows system and say "dude, that looks so good and usable, and it's thought out so well." People already say this about Mac, it's just the price tag for the hardware keeping them back.

Granted, the Linux community could do the same in 6 months to 1 year. The problem is that they don't even begin to acknowledge the need for a complete overhaul. The replies to this post will probably say "what's wrong with Linux as it is today?" Therein lies the problem.

There are already avangardist projects like GoboLinux or Zero Install (heck, even SELinux makes a good example, see how many adopt that soon) out there who try to challenge the basics of the Linux system design, but not many people take them seriously. It's a shame, because if anything, such projects have proved that you can do anything with Linux, as long as enough people start to see the need for the change.

Every year, the major distro's come up with bells and whistles, and better hardware detection, and package newer versions of the software, and better tools to tie together with ducttape the problems in the system. And we delude ourselves into thinking that Linux systems are evolving. Please. No, I don't mean the kernel or the applications, I mean the systems.

Sigh. You'd think there would be a breakthrough at some point, somewhere. That someone would understand the need for fundamental changes. That someone would design a new breed of Linux system. That it would implement that new system to a fairly usable point. That a company would appear to pick it up and bring it to the masses. That the community would embrace it.

But it doesn't happen. There are 5 hops I mentioned here, and something happens at some point. I can figure out some reasons and you can probably figure them out too. So we all clap for the 10th version of the same old distros, going on the 20th.

GoboLinux has an interesting approach that reminds this one adopted by ROX and Zero Install. The advantage is that this classification is done by the OS itself, rather than only on the desktop. I'd suggest everyone interested on Zero Install's directory tree to give a look at http://www.gobolinux.org .

From the GoboLinux FAQ:

What the heck is GoboLinux?

GoboLinux is a Linux distribution that breaks with the historical Unix directory hierarchy. Basically, this means that there are no directories such as /usr and /etc. The main idea of the alternative hierarchy is to store all files belonging to an application in its own separate subtree; therefore we have directories such as /Programs/GCC/2.95.3/lib.

To allow the system to find these files, they are logically grouped in directories such as /System/Links/Executables, which, you guessed it, contains symbolic links to all executable files inside the Programs hierarchy.

To maintain backwards compatibility with traditional Unix/Linux apps, there are symbolic links that mimic the Unix tree, such as "/usr/bin -> /System/Links/Executables", and "/sbin -> /System/Links/Executables" (this example shows that arbitrary differentiations between files of the same category were also removed).

From the GoboLinux FAQ:

What the heck is GoboLinux?

GoboLinux is a Linux distribution that breaks with the historical Unix directory hierarchy. Basically, this means that there are no directories such as /usr and /etc. The main idea of the alternative hierarchy is to store all files belonging to an application in its own separate subtree; therefore we have directories such as /Programs/GCC/2.95.3/lib.

To allow the system to find these files, they are logically grouped in directories such as /System/Links/Executables, which, you guessed it, contains symbolic links to all executable files inside the Programs hierarchy.

To maintain backwards compatibility with traditional Unix/Linux apps, there are symbolic links that mimic the Unix tree, such as "/usr/bin -> /System/Links/Executables", and "/sbin -> /System/Links/Executables" (this example shows that arbitrary differentiations between files of the same category were also removed).

I see stow has already been mentioned. You might also want to check out the various Encap variants and also gobolinux

I have this right now using GoboLinux using symlinks. Works extremely well.

Or you could just use GoboLinux It stores packages in /Programs/Foo/1.0/ bin sbin lib And so on. There is a set of scripts for managing a /System/Links/* heirarchy and a legacy heirarchy.

Linux on the desktop will never be truly successful until it atleast has a file system that makes sense as well as a simple and reliable method for software installation. And of course the former greatly helps the later. Naturally, there are the other points such as game and application support, but these will come when the basics become standard and Linux becomes more accepted. Personally, I believe everything Linux, as a whole, needs to succede already exists but is not yet embodied in a single distro. I find it ironic that no one's fully taken advantage of the freedom of information that open source entails and encorporated the best ideas into a "super-distro".

As a user, I only expect that sending non-free off to a separate organization would cause quality regression. I don't see an advantage in it.

... put non-free somewhere else with people who care about it ...

Debian has a number of individuals who maintain non-free packages. Aren't the packages already with people who care about them?

... APT will handle this very easily...

APT might, but Debian's quality doesn't come from APT. It comes from Debian -- the organization, the policies, the developers, the large umbrella.

Suppose non-free were the ugly duckling of the open source community. Then a separate Non-Free Organization should have trouble _getting_ facilities. Would a user be well served with fewer mirrors and fewer build hosts (representing fewer architectures) for the non-free portion?

Suppose non-free Debian poses different technical issues from free Debian. Why should I believe that those issues are better dealt with separately? For example: testing and unstable periodically change ABI when they adopt a new gcc or libc. The two organizations would have to coordinate the transition in order to maintain quality. Also: licensing issues and compilation issues (eg hard-coded paths, patch constraints, binary-only releases) may make non-free software harder to integrate with Debian. That difficulty is good: it is a check against open-source's flexibility. A Debian which ignores non-free issues can only become _less_ compatible. That would make it harder for _me_, a supporter of free software principles, to keep Debian at work (we use Oracle and MatLab); it would make it harder to persuade my bosses or my users that free alternatives can satisfy _their_ needs.

Finally (on another note), Debian provides a vetting process for developers and packages. That process may be overburdened or flawed, but I can't imagine that duplicating the effort at Debian and Non-Free Organization would improve it.

Now (*begins stepping off soap box*) I haven't run any large, multinational non-profit software organizations. But I think you need to make a more compelling case. What can a separate, official organization offer that an integrated, unofficial organization cannot? (*actually gets off soap box*)