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."
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)
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?
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.
The filesystem is the package manager
We use /appl (/opt in a jam) for all our software. And most production software uses its own /etc, bin,log,lib, directories. /appl/oracle with everything in its own directory.
/usr/X/lib/X11/fonts WTF, I've always hated how X puts files that are not libs in /lib.
/share directory, how about a simple /fonts directory for the entire system?
/home directories. I love how fink is just in /sw for the whole system, and doesnt touch a system file. Even my WinXP box has a cleaner directory structure.
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.
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 default. Applications shouldn't even touch C:\Windows unless they're installing kernel drivers or providing system-level functionality. Any other behavior should be considered bad and unacceptable, and would be similar to Linux programs putting their program executables in /bin or /sbin.
An interesting thing I've noticed is this shift in some places to installing shared libraries such as mfc42.dll to the program's installation directory, eliminating the need to touch C:\Windows at all and avoiding DLL hell at the expense of file space. (IIRC, there are several variants of mfc42.dll.) Yes, this would be bad on older systems with limited hard drive space, but for future OS's like Longhorn I think this would be acceptable. Even my sister's computer has over 20 GB of space right now. Hopefully the view of C:\Windows as a shared dumping ground will go away.
The reason some programs stop working when you move them around is the storage of the program location in the registry. With .NET, Microsoft is encouraging the storage of program settings in an XML config file in the program's directory, and similar storage of user settings in their Documents and Settings folder is completely possible. I see a slow progression to Mac OS X's concept of self-contained applications.
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 installer can process that XML file and set up links and associations automatically. No need for a programming scripting language except in complex installation scenarios.
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.
The filesystem is the package manager
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 justification. Just read the Filesystem Hierarch Standard, and you'll see that there are some very good reasons for the existing structure. Proposed alternatives should include a reason why their ideas will work better than the existing layout.
There's no point in questioning authority if you aren't going to listen to the answers.
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?
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?
The filesystem is the package manager
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!
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