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!
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.
Me, I like my three letter unpronounceable paths all the same :)
/usr/bin and /lib are both easy to pronounce: "user-bin" and, well, "lib". /etc is really the only hard one.
I don't mean to nitpick, but
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.
They're trying to replace an arcane directory structure, not mask it.
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?
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.
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)
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.
Sent from my ASR33 using ASCII
/etc is really the only hard one.
Pronounce it the same as you would if you saw it in a normal sentence, "et cetera".
"Madness is something rare in individuals - but in groups, parties, peoples, ages it is the rule." -- Nietzsche
Yeah, but who the hell starts them with capital letters?!?!?!
Even with tab-completion, I just got my time quadrupled! Frickin' shift keys.
Then many of the binaries in
Now
I don't see anything intrinsically wrong with a complete bottom-up rewrite of the current system. The whole point of Free Software and Open Source is that, if you don't like it the way it is, you can change it. Clearly the current GoboLinux system isn't for the faint of heart, but something really good may come out of it that would increase the usability of Linux by an order of magnitude -- but magic like that doesn't happen if people are constrained to the old way of doing things.
It may be that, in 10 years, most Linux users will be going "/etc? What's that for?". (hmmm. Some may already be doing that!).
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
The authors apparently don't have a clue about ebuilds, otherwise they would try to use simplicity as this system's selling point - ebuilds are already there, they are about as simple as they can get if you want it to be useful for a real distro. Looks more like a manifestation of Not Invented Here syndrome than anything else to me.
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
There is plenty.
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.
Comment removed based on user account deletion
The simplest and most obvious reason to make the computer case sensitive is because it's much, much easier to program that way. Any time you want to know if two filenames are the same you can just compare them bit by bit and see if they're exactly equal. Making the computer understand which characters are upper or lower case versions of which other ones adds some complication in a coding system as simple as ASCII. If you want to use something more complex, like Unicode, the problems multiply tremendously. Including a full Unicode library in the kernel- which you'd need to do in order to make things case insensitive at the filesystem level- would be a source of innumerable bugs and performance problems.
There's no point in questioning authority if you aren't going to listen to the answers.
That works on any Unix based system.
If need be then a distribution could be packaged up from the portage system, so that you could generate rpm's, deb's or gentoo files from the higher level.
I generally don't think it's a good idea. It's additional clout that is pretty much unnecessary, seeing as how everybody is already used to /usr/bin, /lib, etc. If there were an advantage, I'd go for it, but there isn't: It's longer to write, you're mixing upper- & lower-case letters, and it's confusing sometimes. No real advantage.
Take OS X for instance. Here's a sample of what's in my root directory on my Powerbook:
/Applications
/Desktop DB
/Desktop DF
/Developer
/Library
/Network
/System
...
etc.
It's confusing and convoluted as hell. There's not necessarily only one type of file in each directory. Not to mention the structuring: there are applications left and right, many of which are actually directories containing more varied data. Madness, I tell you.
Stick with tried and true. It's been proven to work, and there is no major advantage over the new method.
This is however ignoring the fact that many things computer related are already English centric since many of these items have their origins in English speaking countries.
Languages like C, BASIC, Pascal, FORTRAN, etc all use terminology and syntax that's English derived, one way or another.
Even the UNIX commands like "cp" or "mv" etc are tied to English verbs such as copy or move.
How often do you find yourself using a computer system where the language is set to something you don't speak? If you couldn't read/write Chinese, would you be, for example, altering source code written by a Chinese person (and understanding their comments which you can't read) on THEIR Linux machine?
To continue to use an archaic and cumbersome system because it would require modifications for other countries seems like a weak argument. We use products designed in other countries and we're able to do so because someone translates instructions and text...the same could be done here.
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....