Slashdot Mirror
GoboLinux Compile -- A Scalable Portage?
LodeRunner continues "We already have ebuilds, RPM .spec files, and whatnot. The argument for reinventing the wheel yet again was the observation that while developing apps to handle these files is easy, the task of maintaining the ever-growing database of compilation scripts is the real problem -- the huge package collection of Debian comes to mind. Compile took the extreme minimalistic approach, and its scripts ("recipes") are as small as can be: the script for a typical autoconf-based program takes two lines.
Knowledge for handling common situations is usually added to Compile itself instead of being coded in the script (for example, apps that need a separate build directory just add a needs_build_dir=yes line). The plan is to make Compile as smart as it can and the recipes as small as possible.It remains to be seen whether this experiment of gauging differently the tradeoff between flexibility and simplicity will prove itself to be limiting or enlightening, but in the ~six months Compile has been in beta test by the people from the GoboLinux mailing list, over 500 recipes were written, ranging from Glibc and GCC up to KDE and the Linux kernel itself."
When i first changed to gentoo I was gladly surprised by the power and flexability of portage. If this is half as good it is worthy a place in the linux community, no doubt about it!
"Does away with" /usr/bin and /lib?
...In all seriousness, though, that does sound kind of like an interesting concept--might make things easier for people to understand. Me, I like my three letter unpronounceable paths all the same :)
BLASPHEMY!!! They're SINNERS! How DARE they mess with the SACRED directory structure! Et cetera! Et cetera! Ad nauseam!
But is yet another source-based compilation system needed?
Uhmm... I guess not, from now on, we'll do all of our compilations without source code... however that will supposedly be done.
mkdir /System/Settings
ln -s /etc/X11/ /System/Settings/X11
Couldn't this also work?
Yes, an autoconf build script contains two lines. And cannot express version dependencies that the autoconf build didn't think to maintain ... and if it did, it doesn't communicate the dependency back to the build system. It has no way to merge config files. It doesn't even have a way to enumerate the installations. But yes, you could build a system that simple, because it's good enough for some, but even slackware isn't that simple. To say nothing of distribution patches, configuration (e.g. to build xchat with gnome support or not?), and so on.
This isn't to say it'll get to be as complex as portage, but it will probably have to get at least as complex as ports. Which then begs an obvious question...
I've finally had it: until slashdot gets article moderation, I am not coming back.
I strongly believe in the jungle-evolution style of distributions, so I welcome any new randomness into the population to find out if natural selection will choose it or forget it... but...
I'm still not seeing what this has over Gentoo, other than the new directory naming scheme (which is, btw, very nice). Portage is a pretty slick system. Ebuilds are fairly simple to write. There isn't much in the way of "unnecessary extra" in them. Is this really that much better?
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
Just because you have a Unixish kernel does not mean you have to have a Unixish operating system.
Surprisingly, not everything in the world has to be Unix!
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
It's much more difficult to make a typo in /etc than /System/Config. That's one of the godsends of the POSIX structure over that of Windows - /lib is easier to remember/type than C:\Windows\System32. And there are none of those annoying spaces in /usr/bin that exist in C:\Program Files.
Having created build scripts in FreeBSD, Gentoo, Sourcemage, and Arch Linux, I think the most important goal is to use/develop a script language that newbies find easy to use.
If you're developing a new distro, and you're concerned about giving users a reason to move, focus on making it easy for us to add to the distro!
Check out my blog: My Galaxy is Milky Way Adjacent
I like how they post lost of screenshots running window managers. They could have just said "it runs KDE." It's not like their KDE is anything special, it's the underlying structure that's different. Then again, every distro does this. However, this distro is targetting people who most likely understand this concept already.
Blasphemy my ass. i have been using Linux, BSD, nd other UNIX derivatives for over 10 years now, and all I can say is THANK GOD.
/usr/bin, /etc, /usr/local concept is totally outdated. Having apps in their own directories eases maitenence, eases administration, and eases uninstallation. Think about it, if apps were in their own self contained directories, who even *needs* a package manger? To install, you extract the tar, to uninstall, delete the directory. Boom snap, done and done.
The
Other than core system configuration and core libraries the whole system uses, I ideally think *any app should be totally confined to one directory level. IMO this is one thing Windows does right.
I would tend to agree that breaking the paths would be bad, fourtunately they don't exactly do that.
/Programs/Xorg/6.7.0 and /Programs/KDE/3.2.2. Each file category (executables, libraries, headers) can also be accessed through unified symlink views, such as /System/Links/Libraries and /System/Links/Headers. These views match the legacy directories (/bin, /usr/include, /usr/local/share) and so on, achieving total Unix compatibility while keeping program directories completely self-contained."
What they do is provide a more intuitive (on the surface of it, it seems so to me, need more details to be shure) path system while maintaining compatability to the old system.
"In GoboLinux, each program resides in its own directory, such as
They claim thier systems is path agnostic.
this is a good thing imho. One of my (minor) pet peves is that the standard *nix path system is largely cryptic to joe user, and a pain in the butt even for the cluefull unless you have enough *nix experience to make it automatic.
Now if they fix cut and paste and find a way to make havening both a *nix and a windows version as close as possible to a simple recompile with a few options/flags changed the year of linux as a major desktop contender will finally arive istead of forever being next year.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
The descriptive path thing sounds a lot like what OS X does, except that it goes all the way where OS X still has /usr, /etc, etc. although hidden. I wonder if Apple can patent or has patented that?
1. With Linux entering mainstream, hardly anyone uses the command line for things like file management anymore. They use file managers like Konqueror and Nautilus.
2. Even if you're afraid of X Windows, have you ever heard of tab completion?
Yes, simplicity is good, but only in the context of the whole system. Here, you're just shifting complexity from the per-package scripts to the overall Compile package itself -- creating a large, central, monolithic service.
Because it's centralized, over time, this is going to accumulate a lot crap and become opaque, obfuscated, and unmaintainable. Changes and maintenance to Compile will more significantly impact the contemporary set of recipes than, say, changes to Portage and ebuilds.
It's easy to apply a good idea, like "simplicity", in too narrow of a scope -- to the detrement of the overall design. Better to think about it as balance of "package maintainability", "system maintainability", "barrier of entry", etc.
a distro that does away with Unix paths such as /usr/bin and /lib and uses things like /System/Settings/X11 instead
For all those thinking "what a nice idea":
afaik LSB requires FHS which, in turn, requires the standard directory structure. Does this mean we should throw the whole LSB out now?
And no, OSX is not LSB compliant - go figure.
When the poster mentioned
/System/Settings/X11
/System/Links/Tasks ,as the article mentions
/usr itself pains lazy idiots like me with the capital X; I shudder to think as to what'd happen if this, in case, becomes the standard (or the fad)
I had thought, he/she was trying to be funny
But the distro does seem to go this way :
Despite the intuitiveness, having capitals at the beginning of all the directories, particularly the ones that you are going to replace all the / dirs with, would be a major pain atleast in a case-sensitive *nix world
The current 'X11R6' in
(Karma be damned; I am no better than an AC anyway)
I've recently switched from linux to OSX, and I've learned that the latter has some clever ideas (e.g. bundles) that can leverage developer effort. Given this context of learning by changing, my own view is that this new direction for linux is worth investigating ... not that I'll likely leave OSX anytime soon.
This is similar to the evolution from ant to maven for Java developers. With ant, you gave the steps necessary to build your system, an imperative approach. With maven, you instead describe the shape of your system, and it figures out the steps.
;)
Projects become more uniform as a result, and developers spend more time building the projects instead of maintaining build systems.
My only concern is the knowledge or experience that's lost as a result; larger and larger groups of developers have a smaller and a smaller understanding of the tools, environment, and subtle filesystem dependencies that systems tend to have, putting the experience in in-the-field debugging into a relative tiny number of cutting edge high-priced consultants.
By the way, I'm available.
To be fair, this isn't even a new idea for Mac OS X. It came from NeXT.
The filesystem is the package manager
Nice, you just managed to enrage the two biggest groups of Linux zealots in one go. :-)
LOAD "SIG",8,1
But... but... "It's UNIX, I know this!"
In Soviet America the banks rob you!
Then many of the binaries in /usr/bin became 'standard' parts of distributions, and we started using /usr/local/bin for user contributed binaries ... Now /usr/local is becomming the standard place for 'standard-nonstandard' binaries
/bin is for binaries that you need to use the system in single user mode (i.e. no 'user' involved). /usr/bin is for binaries that a user might want to use, like those of your average set of applications. /usr/local/bin is for binaries that are local to the machine.
/usr mounted via NFS then. Say you have a few graphically-oriented machines in your lab.. Perhaps they would have their graphical applications in their /usr/local/bin, since they only apply to the local machine.
/usr/bin, and some local ones in /usr/local/bin, it would be great if they all transparently appeared in /Applications/$AppName..
You know what they're really for?
*
*
*
Why the separation? Imagine you run a lab full of computers.. chances are that they'll have the same main applications. Well, you can have
I imagine that many people won't need that degree of separation, but it's there should you need it. If you don't need it and desire simplicity, just mask it with some symlinks.
On the subject of the main article, I could imagine, with perhaps some filesystem tweaks with regards to symlinks, that a filesystem along the lines of GoboLinux's could be very useful indeed. I'm not quite so sure about *replacing* the current hierarchy rather than just *masking* it, but perhaps some two-way strategy can be used...
I mean, if I have some apps in
That would be cool.
Rox Desktop / Filer (GTK) does this for Linux, and the filer app (sort of Nautilus replacement) is blindingly fast too.
Scroll down to "Applications are directories"
Anything I compile myself goes in
Believe it or not, most things in unix are they way they are for a reason. That reason may not be immediately obvious to you, but it still exists.
While I'm used to the current paths, I have no hard feelings at all about ditching them.
I don't know if there's a linux standard for what kinds of files go in each directory but everyone I ask has a different answer.
I think switching to an updated naming scheme for directories and getting a common installation/uninstallation routine for applications that actually sticks items on the menus in the guis, etc. would be a huge move forward.
Not that I need either feature. I don't even use a linux gui. But someday maybe I will.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
Nonsense. Now emacs and vi: those are teh suck.
=-+
Comment removed based on user account deletion
On reading the some of the docs on the website, I see no reference to something like sandbox.
Yes, Compile uses a sandbox. I am somewhat familiar with the Gentoo sandbox, and our approach is different. Instead of trapping system calls, we install programs using a non-priviledged user which has only temporary access to the program directory it is supposed to work on. You see, this solution uses only the standard Unix permissions system with no ld hacks, and is only possible because of the GoboLinux filesystem layout.
Now I saw no mention of something like that on the compile documentation. Does it have something similar & where is documentation on it?
As mentioned in the Compile page linked by the article, documentation is included in the Compile package.
Secondly, how does it handle minimum dependancies, eg kde-3.0.0 relies on qt-3.0.0 & similar things, & won't build on versions older than that.
Hate to "RTFA" again, but it does support dependencies, and this is also mentioned in the Compile page.
The filesystem is the package manager
I've always wondered if we can replace the Windows NT kernel and loader with Free ones based off Linux or HURD or something...much in the style of ReactOS, but with an MS proprietary operating system, non-kernel DLLs, etc. running over the kernel. Or if the NT kernel can run a fully POSIX operating system. GNU/NT or Windows/Linux, anyone?
Yes, I basically agree with you. The Armagetron recipe shows the "ugly" side of recipes: the support for imperative constructs, which often slip in declarative systems (ask any functional programmer...).
:) What we're doing here is just trying a different approach. Time will tell if it produces revolutionary results. :)
In this particular example, I think the recipe author could have avoided the pre_build function using a patch instead. I recommend that very strongly to users, because patches are easier to maintain when writing a new recipe based on a existing one: patches make "rejects" when they change from one version to another, whereas that sed command will fail silently if the recipe writer is not careful. With a patch instead of the function, the Armagetron recipe would be reduced to 3 declarations.
But yeah, there are cases when ugly imperative functions will be impossible to avoid. This most likely means that the design of the project's build system is pretty screwed up.
What I, personally, try to do in those cases is, instead of writing a marvelously smart recipe, is to contribute a patch to the project itself. Most of the times, it's just $prefix-awareness missing, or something like that. Often the effort people spend working around build inflexibilities in distro-specific scripts would be much better spent improving the programs themselves.
It's usually less work to "fix the program" than work around it. For a few key packages for GoboLinux I even contributed the autoconf scripts, and it was way less work than I thought it'd be. The one thing I like about this approach is that it helps the entire free software community, making for smaller recipes, smaller ebuilds, smaller specs, and so on.
Sure, it ain't revolutionary today, but revolutions don't happen from night to day... they are secretly planned for a long time before the strike.
The filesystem is the package manager
It's George!
(tig)
Ignorance and prejudice and fear
Walk hand in hand
You should look at rox which advocates and uses an appdir apporach in unices (which is actually really neat and effective, they even provide ROX-LIB which shows how it would work with repect to libraries.
True, libraries would still have to be in some common area, but at least would have all relevant resources entirely contained in a subdirectory.
OSX does some impure global resources stuff and some things (particularly Apple packages) are installer based and contribute to tossing things all over the place...
XML is like violence. If it doesn't solve the problem, use more.
It doesn't matter what you call system directory names, because at the desktop level and below, the average user just won't care. In other words, the typical newbie will never encounter /etc or /usr/lib. It may sound nice at first glance, but this is not something that will make the system easier for users.
/usr/X11R6/lib/fonts, because the user is going to push the "install font" button instead!
At the "desktop level", however, it does make sense. And oddly enough, this is an area where the FHS and tradition are completely silent. Do what you want and no one will care.
The user isn't going to care that system-wide fonts go in
Don't blame me, I didn't vote for either of them!
At least, so long as the system uses shared libraries.
:P
MS-DOS was the only OS(that needed an install, Atari DOS wouldn't count there) where I really had a "clean" install the whole way through. Programs went in x, drivers in y. Everything using DOS4GW had a copy of it included with the binary, no harm done. Needless to say, configs also went alongside the binary.
Of course, this falls apart as soon as you have a more complex OS that needs things like scripting languages and windowing systems. There's just no way around shared libraries. And with shared libraries comes other kinds of shared access - to data and devices. So you have to reorganize, create new structures to hold certain kinds of files. Version conflicts, missing depends - all result from this necessity.
Of course, these structures just won't make any sense to the end user, except as a programmer. It won't matter how much you try to polish it up. A project like this might help, but putting an end to it all would probably need something along the lines of an FS and binary format revision, to include more data like the version number and purpose for each file. Good luck doing that....
It's confusing and convoluted as hell.
In what way? What are you going to find in Applications other than applications?
there are applications left and right
Unless you're actively moving things around, all of your applications will end up in one place -- Applications.
- Scott
Scott Stevenson
Tree House Ideas
Ever have a vital piece of info destroyed because you accidently hit the delete button.
Ever accidently overwrite a file because you saved with the wrong name and didn't realize it.
This is why I see a problem with silent actions like how the highlight/middle click works.
Not necessarily as disaterous, but it still takes a non obvious assumed action with no feedback.
It good UI design to have clarity of action and response. People make mistakes and click the wrong thing from time to time and the dumping of the clipboard into a document because just a little to much pressure was aplied to the mousewheel while scrolling is plain asking to frustrate the user and bad ui design.
I'll grant that mousewheels that act as a middle button probably didn't exist when this was started, but that still dosen't excuse it still doing that on a single click.
From your last paragraph it seems as though the situation might be improving some. But you can understand my frustration when a recent set of apps (mandrake 9.1 install) couldn't even share TEXT through simple cut/copy and paste. I don't mean obscure apps, I mean a browser, a file manager and a text editor and other apps that SHOULD communicate simple text easily.
One last partial tangent to this. Choice is good when optional, not when forced for everything. To make an analogy try going to a few stores, start with general stores that don't specialize and notice how limited thier selections per item are. Then goto a few specialty stores that cater to people with specific intrests and likely specific knowledge. notice how broad thier selection is and consider how daunting that could be to an outsider.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
Not sure if this is a good idea, but here it goes:
Directory entries could be presented to the user in his/her native language after the fashion of gettext -- i.e., the language/locale of the text would be determined by some environment variable, configuration setting, or command issued by the user.
Imagine a user who speaks only Mandarin Chinese. Suppose he gets a list of directory entries at the root level. There he would see the Chinese words for "System", "Applications", "Library", etc.
Later, when an English-only speaker uses the same machine, he'll see the same directory names in English, either because:
1) He logged into his own account, which is set so that the OS presents everything, including directory entries, in his language and locale, or:
2) He issued some command to change the language during the same session with the same account.
Normally, this would be difficult to implement (and have it work everywhere in the operating system -- not just while in a special desktop environment). But maybe Reiser4, with its plugin architecture, will allow the job to be done with a small amount of effort; see here:
http://www.namesys.com/v4/v4.html