No. In fact it dies on computers faster than 190 MHz. Computers started to cross this barrier right soon after I learned Pascal, so I started to see programs break all over. There's a patcher program for generated binaries, and for the environment itself.
If you're curious, the problem is with the timing code of the CRT unit. (Yay, travel back memory lane!)
Come on, I don't know how this was ever modded up (who am I kidding -- of course I know... just look at the buzzwords).
Anyways, it makes no sense whatsoever to ask "objects instead of an API". I won't explain what objects or APIs are here, but an API can obviously be object-oriented (need an example? the Java API).
Not to start a flamewar, but this is what the Bush administration has been basing its entire existence on! And it hasn't just been Bush, it has been our entire government over the last XXX years.
Was I the only one who read that as "over the last 30 years"?:)
(and don't come telling me "yes, and that's what I meant"...:) )
You don't, but guess what, lots of people do. Millions of people have green apples drawn in their LP labels and CDs, and see the Apple logo and name in the back cover of the albums, in the opening of the DVDs, etc.
I was just going to give you another example with "Vertigo", relating to the music label, and then (only after thinking of the label) I remembered the Hitchcock movie. For tons of other people, they'd think of the movie first, but I'm sure that for a lot of music fans, not.
On the other hand, when my father thinks "Apple", he thinks "fruit".
So don't come saying "Apple"->"Beatles" is unreasonable. It's no less reasonable than saying "Apple"->"Mac".
Good ol' TVGA 8900...:) Yep, 1MB RAM in that SuperVGA (wow) card. Enough to play SimCity 2000 (therefore, enough for everything!;) ) I remember it wasn't hard at all to drill it. My father did it, using the regular drill we had at home.
The nice thing is that it is a small chip, rather discrete. Doesn't look geeky to non-trained eyes, and it's instantly recognizable to those of Our Kind.;-)
If I look at System/Executables/Zsh/Settings or whatever they call it, I am catapulted back into c:\progra~1 world.
Nah, that's just your traumas. We never had Windows in mind when designing it. And for the n^n-th time, no, it's not a pain in the command line, with a properly configured shell (like the one we ship by default):-)
Are they considering backups? I don't want to backup the binaries, and I don't want to write endless lists of inclusions or exceptions.
Sure! Is tar czvf backup.tar.gz/Programs/*/Settings good enough?:)
In this approach, you have the advantage to know what programs each settings files came from, their pathnames will be stored in the backup.
Or are they going to "fall back" to the legacy tree, which was designed to be exactly that: a tree logically divided into groups that make sense to a system.
As I mentioned in another post, the directories were not renamed. They are new directories with different semantics, they function differently. I had to choose names, and I picked descriptive ones (long names in a tab-completion world are a non-issue) and used capital letters (caps in a case-insensitive-tab world are a non-issue) in order not to clash with the (yes, ever-changing) Unix namespace.
That was back in 2001. Imagine if I had chosen/sys instead of/System back then. That would have been a bad, bad idea.
It won't help at all. After a short time you learn what "etc" means and it doesn't matter anymore.
It's very important to note that/System/Settings is not just "renaming/etc to make it pretty". It has different semantics.
/System/Settings is the "global view" of all apps settings. It is a collection of symlinks from each apps' own settings (/Programs/Foo/Settings,/Programs/Bar/Settings...). To Unix apps,/System/Settings looks like/etc, smells like/etc and works like/etc.
But when you do an ls -l you know exactly to which program each xyz.cnf belongs to. And when you remove XYZ from your system, xyz.cnf goes away. For sure. Even if you copied the binaries from a friend, compiled it by hand, whatever. No matter what, it just won't get out-of-sync with the filesystem... because it is the filesystem.
I did RTFA, 2 times before posting, and links from it, I just read it a third time, and read the README in the Compile package. Maybe I wasn't clear: I saw something (can't find it now, perhaps it should be on the documentation for compile...) that led me to believe dependencies are made after the package is compiled.
Oh, yeah, sorry, I assumed you just implied there were no dependencies at all, my bad. In fact, dependencies are made after the package is compiled, the first time, by the recipe author, and this information is then reused by the recipe users.
I was thinking more in terms of compile dependencies. I looked at abiword's recipe for example: no reference to GTK or optionally GNOME at all. Does compile just know to build abiword requires GTK, or do you have to have all the dependencies already, somewhere not associated with the recipe file?
That's a bug in the AbiWord recipe, it ought to include a Resource/Dependencies file. This means it was created with an old beta of Compile which did not "export" dependencies. The first release was just released this week (1.0.1; 1.0.0 was in the last GoboLinux release candidate), and many recipes do not explore all Compile features. We are fixing things as we upgrade packages and get reports/fixes; of course, our resources are limited because we are a small distribution.
The other issue you raise, about the GNOME optional dependency, is a current Compile limitation, and a clean way to implement this is still under discussion in the GoboLinux list.
Those are the only two statements I can currently find about it. Perhaps you should be a little less RTFA, or point me to an Article which says more.
You're right, and I apologize. The documentation is currently terse (and the README serves at most as a reference API for the people from the mailing list). I did not spend much time documenting Compile's support for dependencies because it is basically the same as the usual GoboLinux approach for dependencies, so writing "GoboLinux-style dependencies" was enough documentation for the target audience the development snapshots were aimed at (those who were already GoboLinux users).
On second though, your screenshots actually serve an even more valuable service; showing me that you haven't sufficiently cleaned up the directory structure to really interest me.
I told you the screenshot were thought out to be informative!:)
However replacing a/usr/bin with 600 programs with a/Programs with 300 directories doesn't really solve the problem./Programs is unusable in this state.
It is usable, only not for what you may be thinking about./Programs was not designed to be a "user-friendly view of the system". It is designed to be the "package manager".
User-friendly views can always be built with pretty applications (tree? give me a cool 3D layout any day;) ). They can use meta-data, organize, show descriptions, as the fashion du jour sees fit.
The paradox GoboLinux tries to break is that package managers rely on a (potentially out-of-date) database to know what's on the filesystem, while the files are already indexed in a always-up-to-date way by a structured database... the filesystem itself! That's why we say "the filesystem is the package manager".
Best of all, a power user has full access to this transparent package manager. If you want you can forget completely about the GoboLinux helper scripts and manage the system only with cp, rm, ln, mv... isn't it ironic that in a sense we're actually going back to the Unix roots?
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...).
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.:) What we're doing here is just trying a different approach. Time will tell if it produces revolutionary results.:)
where in typical unix naming conventions (because i'm lazy) you'd have something like/stuff/include/foo/stuff/lib/libfoo.so
[In NeXT] you'd end up with something like/stuff/foo/include/stuff/foo/lib/libfoo.so
Yeah, and GoboLinux does make the NeXTish "philosophy change" you mention. We follow (in your terms) the/stuff/foo approach, not the/stuff/lib one. (In very general terms,) in GoboLinux,/stuff/lib is a compatibility layer, or else "all apps would break".
Incidentally, this is exactly what GoboLinux does, only with different paths... or the same paths, depending on how you look at it: there is a/usr/lib ->/System/Links/Libraries so everything is still "in its place", as far as dumb-apps-that-rely-on-hardcoded-paths can tell.
For modern, $prefix-aware apps, this is a non-issue, of course.
(Actually, there are other aspects to be considered, but if I delved in technicalities, that would get too long.)
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.
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.
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 of recipes "out there".
I believe the modularity of the declarative model will help to keep the code manageable. The impact of side-effects can be much more precisely assessed.
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.
Worry not, we are not blindly going for "simplicity". We are applying it as a means to reduce package maintenance cost. A lower barrier of entry for new contributors is a welcome bonus we get.
And better system maintainability was the reason GoboLinux itself was created, and not to "attract newbie users" as many people say -- I created it for my own use, and I'm hardly a newbie.:) I was tired of package managers that broke when I compiled stuff "by hand". I wanted a system where those things integrated seamlessly (the/usr vs./usr/local distinction is not what I call seamless).
You see big Konqueror windows open in the screenshots because they show the GoboLinux filesystem structure.:-)
I agree screenshots are not something very remarkable for distributions (they basically show off which apps run on the distro, which is, well, pretty much any app). We tried to show something specific in each screenshot (this has the GoboLinux custom theme, this has the GoboLinux custom font, this shows some console tools, etc.)
But yeah, we should update the shots gallery with some new stuff, like the installer (another favorite in distro's shots galleries...). Any better ideas?:-)
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!
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.
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.
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.tar.bz2 containing a directory and some files). Configuration is being discussed in the mailing list, but currently we rely on configuration detected by autoconf et al: usually, if you have svgalib installed, program foo gets compiled with svgalib support compiled in, and vice-versa. It works well for a surprising number of packages, but yes, we are considering something like that.
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).
Actually, GoboLinux works thanks to symlinks, but the other way around./etc is a symlink to/System/Settings, in order to maintain good Unix compatibility.
Each app has its own Settings directory, and/System/Settings is the "global view" of every apps' settings (ie,/etc).
after you get the hang of it, is it comfortable enough to use with all your building? or is something you add on at the end when app/project is ready for export?
I have to say yes. I just converted my latest project, htop, to autoconf and automake, and don't regret a thing. I just followed the tutorial from the info pages (yes, not the manpages, the other ones, that nobody reads:) ), wrote two files (configure.ac and Makefile.am), and everything worked.
There is also a very cool program called autoscan which scans your.c files and creates a sample configure.ac with the configure checks your program needs.
There are also bonus features by switching to autoconf, like make dist: it packs a clean htop-0.3.tar.gz file, only including the needed files (ie, I can keep other files in my development directory and they won't be shipped by accident).
still, if I download something, and install procedure is anything besides "./configure; make; make install", I consider it a significant (though not 100% reliable) warning sign that I just downloaded crap.
Oh yes, I can relate to that sentiment. Having an autoconf-generated configure script makes your project look more mature.:)
Slashdot Mirror
No. In fact it dies on computers faster than 190 MHz. Computers started to cross this barrier right soon after I learned Pascal, so I started to see programs break all over. There's a patcher program for generated binaries, and for the environment itself.
If you're curious, the problem is with the timing code of the CRT unit. (Yay, travel back memory lane!)
Come on, I don't know how this was ever modded up (who am I kidding -- of course I know... just look at the buzzwords).
Anyways, it makes no sense whatsoever to ask "objects instead of an API". I won't explain what objects or APIs are here, but an API can obviously be object-oriented (need an example? the Java API).
Not a lot of people, apparently, since you was modded Informative. Sign of the times... (Sigh)
Not to start a flamewar, but this is what the Bush administration has been basing its entire existence on! And it hasn't just been Bush, it has been our entire government over the last XXX years.
Was I the only one who read that as "over the last 30 years"? :)
(and don't come telling me "yes, and that's what I meant"... :) )
As if when I think "Apple," I think "Beatles."
You don't, but guess what, lots of people do. Millions of people have green apples drawn in their LP labels and CDs, and see the Apple logo and name in the back cover of the albums, in the opening of the DVDs, etc.
I was just going to give you another example with "Vertigo", relating to the music label, and then (only after thinking of the label) I remembered the Hitchcock movie. For tons of other people, they'd think of the movie first, but I'm sure that for a lot of music fans, not.
On the other hand, when my father thinks "Apple", he thinks "fruit".
So don't come saying "Apple"->"Beatles" is unreasonable. It's no less reasonable than saying "Apple"->"Mac".
Good ol' TVGA 8900... :) Yep, 1MB RAM in that SuperVGA (wow) card. Enough to play SimCity 2000 (therefore, enough for everything! ;) ) I remember it wasn't hard at all to drill it. My father did it, using the regular drill we had at home.
;-)
The nice thing is that it is a small chip, rather discrete. Doesn't look geeky to non-trained eyes, and it's instantly recognizable to those of Our Kind.
If I look at System/Executables/Zsh/Settings or whatever they call it, I am catapulted back into c:\progra~1 world.
:-)
/Programs/*/Settings good enough? :)
;-)
Nah, that's just your traumas. We never had Windows in mind when designing it. And for the n^n-th time, no, it's not a pain in the command line, with a properly configured shell (like the one we ship by default)
Are they considering backups? I don't want to backup the binaries, and I don't want to write endless lists of inclusions or exceptions.
Sure! Is tar czvf backup.tar.gz
In this approach, you have the advantage to know what programs each settings files came from, their pathnames will be stored in the backup.
Or are they going to "fall back" to the legacy tree, which was designed to be exactly that: a tree logically divided into groups that make sense to a system.
Why would we? Ours is better!
As I mentioned in another post, the directories were not renamed. They are new directories with different semantics, they function differently. I had to choose names, and I picked descriptive ones (long names in a tab-completion world are a non-issue) and used capital letters (caps in a case-insensitive-tab world are a non-issue) in order not to clash with the (yes, ever-changing) Unix namespace.
/sys instead of /System back then. That would have been a bad, bad idea.
That was back in 2001. Imagine if I had chosen
It won't help at all. After a short time you learn what "etc" means and it doesn't matter anymore.
/System/Settings is not just "renaming /etc to make it pretty". It has different semantics.
/System/Settings is the "global view" of all apps settings. It is a collection of symlinks from each apps' own settings (/Programs/Foo/Settings, /Programs/Bar/Settings...). To Unix apps, /System/Settings looks like /etc, smells like /etc and works like /etc.
It's very important to note that
But when you do an ls -l you know exactly to which program each xyz.cnf belongs to. And when you remove XYZ from your system, xyz.cnf goes away. For sure. Even if you copied the binaries from a friend, compiled it by hand, whatever. No matter what, it just won't get out-of-sync with the filesystem... because it is the filesystem.
I did RTFA, 2 times before posting, and links from it, I just read it a third time, and read the README in the Compile package. Maybe I wasn't clear: I saw something (can't find it now, perhaps it should be on the documentation for compile...) that led me to believe dependencies are made after the package is compiled.
Oh, yeah, sorry, I assumed you just implied there were no dependencies at all, my bad. In fact, dependencies are made after the package is compiled, the first time, by the recipe author, and this information is then reused by the recipe users.
I was thinking more in terms of compile dependencies. I looked at abiword's recipe for example: no reference to GTK or optionally GNOME at all. Does compile just know to build abiword requires GTK, or do you have to have all the dependencies already, somewhere not associated with the recipe file?
That's a bug in the AbiWord recipe, it ought to include a Resource/Dependencies file. This means it was created with an old beta of Compile which did not "export" dependencies. The first release was just released this week (1.0.1; 1.0.0 was in the last GoboLinux release candidate), and many recipes do not explore all Compile features. We are fixing things as we upgrade packages and get reports/fixes; of course, our resources are limited because we are a small distribution.
The other issue you raise, about the GNOME optional dependency, is a current Compile limitation, and a clean way to implement this is still under discussion in the GoboLinux list.
Those are the only two statements I can currently find about it. Perhaps you should be a little less RTFA, or point me to an Article which says more.
You're right, and I apologize. The documentation is currently terse (and the README serves at most as a reference API for the people from the mailing list). I did not spend much time documenting Compile's support for dependencies because it is basically the same as the usual GoboLinux approach for dependencies, so writing "GoboLinux-style dependencies" was enough documentation for the target audience the development snapshots were aimed at (those who were already GoboLinux users).
That's one think I like about linux. I can go around my files faster with the command line (using your point 2) than in any file manager.
Some people would argue that this, instead, is an indication that your file managers are not good enough.
On second though, your screenshots actually serve an even more valuable service; showing me that you haven't sufficiently cleaned up the directory structure to really interest me.
:)
/usr/bin with 600 programs with a /Programs with 300 directories doesn't really solve the problem. /Programs is unusable in this state.
/Programs was not designed to be a "user-friendly view of the system". It is designed to be the "package manager".
;) ). They can use meta-data, organize, show descriptions, as the fashion du jour sees fit.
I told you the screenshot were thought out to be informative!
However replacing a
It is usable, only not for what you may be thinking about.
User-friendly views can always be built with pretty applications (tree? give me a cool 3D layout any day
The paradox GoboLinux tries to break is that package managers rely on a (potentially out-of-date) database to know what's on the filesystem, while the files are already indexed in a always-up-to-date way by a structured database... the filesystem itself! That's why we say "the filesystem is the package manager".
Best of all, a power user has full access to this transparent package manager. If you want you can forget completely about the GoboLinux helper scripts and manage the system only with cp, rm, ln, mv... isn't it ironic that in a sense we're actually going back to the Unix roots?
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.
where in typical unix naming conventions (because i'm lazy) you'd have something like /stuff/include/foo /stuff/lib/libfoo.so
/stuff/foo/include /stuff/foo/lib/libfoo.so
/stuff/foo approach, not the /stuff/lib one. (In very general terms,) in GoboLinux, /stuff/lib is a compatibility layer, or else "all apps would break".
[In NeXT] you'd end up with something like
Yeah, and GoboLinux does make the NeXTish "philosophy change" you mention. We follow (in your terms) the
Incidentally, this is exactly what GoboLinux does, only with different paths... or the same paths, depending on how you look at it: there is a /usr/lib -> /System/Links/Libraries so everything is still "in its place", as far as dumb-apps-that-rely-on-hardcoded-paths can tell.
For modern, $prefix-aware apps, this is a non-issue, of course.
(Actually, there are other aspects to be considered, but if I delved in technicalities, that would get too long.)
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.
Well, I don't use bash myself, and GoboLinux ships with the One True Shell, zsh, as default. ;-)
Now seriously, give zsh a spin in the GoboLinux Live CD and you'll be a convert for life.
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.
:) I was tired of package managers that broke when I compiled stuff "by hand". I wanted a system where those things integrated seamlessly (the /usr vs. /usr/local distinction is not what I call seamless).
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 of recipes "out there".
I believe the modularity of the declarative model will help to keep the code manageable. The impact of side-effects can be much more precisely assessed.
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.
Worry not, we are not blindly going for "simplicity". We are applying it as a means to reduce package maintenance cost. A lower barrier of entry for new contributors is a welcome bonus we get.
And better system maintainability was the reason GoboLinux itself was created, and not to "attract newbie users" as many people say -- I created it for my own use, and I'm hardly a newbie.
Every modern shell supports case-insensitive tab-completion. And in GoboLinux, this is enabled by default.
Try it, you might like it: on bash, just add
set-completion-ignore-case on
on your ~/.inputrc.
You see big Konqueror windows open in the screenshots because they show the GoboLinux filesystem structure. :-)
:-)
I agree screenshots are not something very remarkable for distributions (they basically show off which apps run on the distro, which is, well, pretty much any app). We tried to show something specific in each screenshot (this has the GoboLinux custom theme, this has the GoboLinux custom font, this shows some console tools, etc.)
But yeah, we should update the shots gallery with some new stuff, like the installer (another favorite in distro's shots galleries...). Any better ideas?
To be fair, this isn't even a new idea for Mac OS X. It came from NeXT.
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!
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.
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.
:) )
.tar.bz2 containing a directory and some files). Configuration is being discussed in the mailing list, but currently we rely on configuration detected by autoconf et al: usually, if you have svgalib installed, program foo gets compiled with svgalib support compiled in, and vice-versa. It works well for a surprising number of packages, but yes, we are considering something like that.
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).
Actually, GoboLinux works thanks to symlinks, but the other way around. /etc is a symlink to /System/Settings, in order to maintain good Unix compatibility.
/System/Settings is the "global view" of every apps' settings (ie, /etc).
Each app has its own Settings directory, and
I have to say yes. I just converted my latest project, htop, to autoconf and automake, and don't regret a thing. I just followed the tutorial from the info pages (yes, not the manpages, the other ones, that nobody reads
There is also a very cool program called autoscan which scans your
There are also bonus features by switching to autoconf, like make dist: it packs a clean htop-0.3.tar.gz file, only including the needed files (ie, I can keep other files in my development directory and they won't be shipped by accident).
Oh yes, I can relate to that sentiment. Having an autoconf-generated configure script makes your project look more mature.