GoboLinux Compile -- A Scalable Portage? 366
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."
Emerge (Score:3, Insightful)
Re:Emerge (Score:2)
In reality, most programs aren't typical of course.
If they're doing away with USE variables, that will make things simpler at the expense of losing a powerful feature.
Re:Emerge (Score:2, Funny)
WHAT? (Score:5, Funny)
BLASPHEMY!!! They're SINNERS! How DARE they mess with the SACRED directory structure! Et cetera! Et cetera! Ad nauseam!
The shorter the better (Score:5, Insightful)
Non-issue (Score:3, Interesting)
2. Even if you're afraid of X Windows, have you ever heard of tab completion?
Re:Non-issue (Score:5, Insightful)
Even with tab-completion, I just got my time quadrupled! Frickin' shift keys.
Re:Non-issue (Score:5, Informative)
Try it, you might like it: on bash, just add
set-completion-ignore-case on
on your ~/.inputrc.
Re:Non-issue (Score:4, Insightful)
There are several languages where lowercase -> uppercase -> lowercase can't be done without losing data, for example. Then there is the problem of how many languages you can support. Say, English is easy, but what happens when you find a disk with filenames in an encoding the filesystem doesn't know about?
In Linux, it's just all bytes, it doesn't care if it's english, cyrillic or whatever. With case insensitivity it suddenly has to know what to do with cyrillic letters as well.
Re:Non-issue (Score:2)
Wait, wait, wait, time, time, cut, cut, cut. That's a fucking joke, right? None of the Linux or BSD users I know use file managers for file management, except perhaps mc. And, given your second observation, I don't see why anyone would need to.
Re:Non-issue (Score:2)
has tab completion. Simply hit / in any window, and it pops up a directory on the bottom. backspace takes you up a level, and there is tab completion for files/folders.
It's fantastic.
Re:Non-issue (Score:2)
Re:Non-issue (Score:2)
In particular, look at the "-s" option.
Re:The shorter the better (Score:3, Insightful)
Tab auto complete....
Nice, but annoying to have to rely on it. I use Cygwin periodically and use tab completion. Under cmd.exe I do stuff like this:
or
I know tab completion is enable-able in XP, but I don't think it is in 2k without a 3rd party shell.
The annoying part about the unix filesystem is that you have to learn it. But you have to learn Windows, too. Sure, your temp files are
Re:The shorter the better (Score:3, Insightful)
%programfiles% is -not- a simple lay out. Not only do you have every application in its own folder (that's not in your path), sometimes the application directories are hung off an intermediate directory for the vendor (such as %programfiles$\Adobe). This is assuming we're talking
Re:The shorter the better (Score:5, Informative)
Re:WHAT? (Score:3, Insightful)
I don't mean to nitpick, but
Re:WHAT? (Score:3, Insightful)
Pronounce it the same as you would if you saw it in a normal sentence, "et cetera".
Re:WHAT? (Score:2)
Re:WHAT? (Score:2)
Screw that (Score:5, Insightful)
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.
Re:Screw that (Score:2)
And you can uninstall by deleting the directory.
Windows tries to do this, but the registry prevents simple folder removal as an uninstall procedure, because stuff is left in the registry.
Rox (Score:3, Informative)
Scroll down to "Applications are directories" [sourceforge.net]
Re:Screw that (Score:5, Insightful)
Except that many applications install their own DLL cruft under C:\WINDOWS anyway (Microsoft itself being one of the worst offenders), and that the program stops working if you move the application dir around, thus eliminating completely the usefulness of this concept.
No, the OS that does this right is Mac OS X. Installing an app is as simple as copying the application package (basically just a directory), and you can put and move it anywhere.
Re:Screw that (Score:3, Interesting)
Except that many applications install their own DLL cruft under C:\WINDOWS anyway (Microsoft itself being one of the worst offenders), and that the program stops working if you move the application dir around, thus eliminating completely the usefulness of this concept.
Most of the cruft Microsoft installs in C:\Windows are shared libraries such as msvcrt.dll and mfc42.dll. I agree that it's ugly but there's not really anywhere else they can go, especially since C:\Windows\System32 is on the path by defaul
Re:Screw that (Score:3, Insightful)
The big problem here is that if you have a vulnerability or bug in a shared library, you now have to wait for the vendors/maintainers of every package to upgrade everything. With shared libraries, you can just upgrade the library and all is well (obviously t
Re:Screw that (Score:2)
Re:Screw that (Score:2)
OTOH, they got it slightly wrong, it should have merely been an invisible directory that was automatically dragged/copied/deleted with the application, but which didn't need special system commands for access. Turning it into a single file (the resource fork) rather than an invisible directory (the resource folder?) was the only mistake, though. And I particularlly liked having file type separate from linked applicatio
Actually.. (Score:3, Informative)
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.
Re:Screw that (Score:3, Informative)
Re:Screw that (Score:3, Insightful)
If you do how do you explain the "Shared file, confirm deletion" during an uninstall?
If you had said that OS X has it right, you would have been closer, but even some apps in OS X scatter things around during an install.
Re:Screw that (Score:4, Insightful)
Re:Screw that (Score:4, Informative)
And that's exactly what scripts such as GNU Stow [gnu.org] do.
The 'foo' application is installed in '/usr/local/foo-v1.x', and symlinks are placed into /usr/local/bin so that it can be run.
This makes installation and removing applications simple - and you can share your applications across NFS if you're so inclined.
Re:Screw that (Score:2, Insightful)
what prevents you to install your apps with a different prefix if you think it is the good thing ?
keeping the
but when you have remote mounted filesystems, and you are organised enough to care about what belongs to the system and what is an application you installed and what belongs to the system
making backups/reinstalls/upgrades is a lot better when you know what belongs to eg
Re:Screw that (Score:4, Interesting)
While this works, I dont care for gentoo's problems with Mozilla and QT3 compiles, you can recompile an application and break 2 others, gets to be a hassle. But you trade the hassle for speed, or ease (I guess)
Sometimes I just want to rpm -ivvh --force --nodeps and forget about it. And to tell the truth, there is alot of misc stuff on linux/bsd/solaris boxes that could be cleaned up. X directories alone are garbage.
And this
OSX on the other hand is set out clean, they did a good job the personal
Think Gobolinux might be on to something. I'm gonna install it later and try it out.
Re:Screw that (Score:3)
(Sorry about the indentation, I don't feel like fighting with the tabs inside the <ecode> tags)
I actually install my boxen like this now, with the base system where it
Re:Screw that (Score:2)
Re:WHAT? (Score:5, Insightful)
You are welcome to alias them to whatever you want, but it wont help you understand your next door neighbour's Unix system, or your next employer's either.
Re:WHAT? (Score:2)
No in *nix, that would be
Re:WHAT? (Score:2, Interesting)
I realize that it comes as a surprise to many people, but the standard Unix filesystem arrangment is not just a random pile of stuff that's accumulated over time. The directory structure- though not necessarily the names- is the result of a great deal of experience and careful thought. While it might make sense to rename standard directories with more descriptive names, like "libraries" instead of "lib" or even "temp" instead of "tmp", any suggestions to change their basic structure need strong justificat
Uhmm (Score:5, Funny)
Uhmm... I guess not, from now on, we'll do all of our compilations without source code... however that will supposedly be done.
A job for ln? (Score:5, Interesting)
mkdir /System/Settings
ln -s /etc/X11/ /System/Settings/X11
Couldn't this also work?
Re: A job for ln? (Score:5, Insightful)
Re: A job for ln? (Score:2)
The files are in
ln -s
Re: A job for ln? (Score:2, Informative)
Each app has its own Settings directory, and
Ok... (Score:2)
Ooops! It's directories and files are scattered throughout the filesystem
Restricting programs to build into their own trees is an awesome idea IMO.
Re: A job for ln? (Score:2)
If you RTFFAQ here [gobolinux.org], 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.
"as simple as possible" (Score:5, Interesting)
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...
Re:"as simple as possible" (Score:4, Interesting)
There is a separate Resources/Dependencies file, which is automatically generated with ldd (but can be hand-tuned). This is further integrated with the GoboLinux fs-oriented concept of dependencies, so if you, say, compiled Allegro "by hand", it will not complain "Allegro is missing" just because it was not built with Compile.
It has no way to merge config files. It doesn't even have a way to enumerate the installations.
Could you clarify on those? I really did not get it (and maybe that's why it's not implemented
To say nothing of distribution patches, configuration (e.g. to build xchat with gnome support or not?), and so on.
Distribution patches are applied if found in the recipe directory (a recipe is a
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...
Yes, we are aware it will get more complex over time, but by keeping minimalism as the #1 goal, let's see how "little complex" can we still be while being reasonably feature-complete for real world usage (and some would even argue we already are).
What does this have over Gentoo? (Score:3, Interesting)
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?
Easier to Write Build Scripts, Please? (Score:3, Insightful)
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!
Re:Easier to Write Build Scripts, Please? (Score:4, Interesting)
Exactly! That's our #1 design goal. Most of the more active users in our mailing list have already contibuted at least one build script for their favorite app. That's how the recipe-store has grown so fast.
Compile doesn't use a specialized language (Score:2)
If I take Armagetron recipe [gobolinux.org], 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 [gatech.edu] is longer, but it also contains more meta-data (dependences, license,
Re:Compile doesn't use a specialized language (Score:3, Informative)
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
Re:Easier to Write Build Scripts, Please? (Score:3, Interesting)
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!
For small programs, I can imagine an XML file that describes stuff like possible shortcuts to place on start menus and any file extensions that should be handled by the program. The inst
Screenshots (Score:3, Insightful)
Descriptive path and OS X (Score:4, Insightful)
Re:Descriptive path and OS X (Score:2)
Naming things such that they are easy to find.
Sadly, I could see that happening.
"Recipes" are a bad idea (Score:5, Insightful)
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.
Re:"Recipes" are a bad idea (Score:2, Interesting)
That remains to be seen. The implementation so far has been pretty proof-of-concept, more to get the model stress than to get the actual code. After all, code can be rewritten, but redesign is much more costly after you have a large database
Unix paths (Score:3, Informative)
For all those thinking "what a nice idea":
afaik LSB [linuxbase.org] requires FHS [pathname.com] 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.
Re:Unix paths (Score:2)
The Gobo Linux system creates its own directory structure using simple descriptive names. It looks loike a very nice idea to me. They also have links in place to allow compatibility with the Posix directory structure. LSB is not threatened. Yet.
Re:Unix paths (Score:2)
It's possible LSB dependant apps could run just fine on this system.
I hope so, this kind of soulution is needed, the cryptic (to MOST people) unix style directory structure really need to go, or at least be hidden for Joe Sixpack to be able to use it. The only reason for not do
Re:Unix paths (Score:4, Informative)
This might be nitpicking, but I think you didn't read what the first letter in 'LSB' stands for - Linux
My shift key!! (Score:2, Insightful)
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
Re:My shift key!! (Score:2)
the site is worth visiting (Score:4, Informative)
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.
The "declarative" approach (Score:3, Informative)
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 [seankelly.biz] available.
Why confuse matters? (Score:2)
Jury Still Out (Score:2)
From their web site:
The "differentiation" between /usr/bin and /sbin is hardly arbitrary. /usr is often on a separate partition; /sbin must be accessible even without other partitions m
UNIX filesystem has *always* eveolved (Score:2, Insightful)
Then many of the binaries in
Now
parent makes a great point (Score:2)
Re:parent makes a great point (Score:2)
No. Directory names (and common commands like ls and rm) were traditionally short on Unix because comm speeds were very slow in the 70's and 80's. When your terminal's running at 110 baud, you don't want to type any more than you have to. Things are a lot faster now, fewer people use the command line, and tab-completion helps those who do--so we could theoretically have /User/Bin
Re:UNIX filesystem has *always* eveolved (Score:3, Insightful)
You know what they're really for?
*
*
*
Sandbox? Dependancies? (Score:2)
Sandbox for those of you unfamiliar with gentoo, provides a method for making sure that durring the build no file outside the directory can be written to, so malicious scripts (say someone cracked a project & changed configure for example) & whatnot wouldn't be able to work. It doesn't rule out trickier exploits (backdoors etc actually in the code) but does make it safer.
Now I saw no mention of something
Re:Sandbox? Dependancies? (Score:2)
I always thought that the Sandbox was there to keep track of all the files the package installs, for the unmerge procedure...
Re:Sandbox? Dependancies? (Score:2)
It doesn't matter what distro it is for the execution if it's in the source code (as in someone has coded in a back door that hasn't been noticed), because any build system that I know of won't see it or be able to prevent it.
Now, sandbox does prevent things from happening like build scripts accidentally over writing things if either the w
Re:Sandbox? Dependancies? (Score:2)
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 filesys
I'm all for ditching the paths (Score:4, Insightful)
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.
Re:I'm all for ditching the paths (Score:3, Informative)
Directory names (Score:3, Interesting)
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
The user can never escape awkward directory trees (Score:3, Insightful)
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....
Re:It works for Gentoo (Score:5, Insightful)
Surprisingly, not everything in the world has to be Unix!
Re:It works for Gentoo (Score:3, Funny)
Re:It works for Gentoo (Score:3, Interesting)
Re:It works for Gentoo (Score:4, Informative)
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
Oh! My! God! (Score:4, Funny)
It's George [nanc.com]!
(tig)
Re:It works for Gentoo (Score:2)
Re:It works for Gentoo (Score:2)
Re:It works for Gentoo (Score:2)
and b) what you just described is broken for many people. try cut and replace that way.
highlight to copy, then highlight what you want to replace, oh wait that won't work. I used a windows app that ha
Re:It works for Gentoo (Score:3, Interesting)
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 d
Re:It works for Gentoo (Score:2)
/ and
Gentoo's file hierarchy is annoyingly loose, in my opinion, but this is common to most Linux distros. (I'm still a big fan of FreeBSD's "/ to boot,
However, complaining that you haven't set PATH properly in your
Re: (Score:2, Insightful)
Re:It works for Gentoo (Score:3, Insightful)
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.
Re:Sounds like Mac OS X (Score:4, Informative)
Re:All I want is SATA RAID support (Score:5, Funny)
Nice, you just managed to enrage the two biggest groups of Linux zealots in one go. :-)
Re:All I want is SATA RAID support (Score:3, Funny)
Nonsense. Now emacs and vi: those are teh suck.
Re:Just what the Linux community needs! (Score:2)
Re:Just what the Linux community needs! (Score:2)
Re:Mac OS X (Score:3, Insightful)
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