Review of Sorcerer GNU Linux 286
ladislavb writes: "Sorcerer GNU Linux is not just another Linux distribution. It did not follow the tried and tested path of modifying a major Linux distribution and releasing it under a new name. Instead, the Sorcerer development team embarked on a completely unconventional way of putting together a unique distribution with features not found anywhere else. Once installed, it will be 100% optimised for your hardware, it will include the very latest Linux applications and it will provide an incredibly convenient way of keeping all software, even essential system libraries, up-to-date. The full review of Sorcerer GNU Linux, as written by DistroWatch.com."
Wait a sec... (Score:3, Redundant)
sounds familiar (Score:2, Informative)
or FreeBSD (Score:5, Informative)
they seem to do a bit more hardware detection, but for a running freebsd, the sequence
cd
make update
portsdb -uU
make buildworld
make buildkernel KERNELCONF=mykernelname
make installkernel KERNELCONF=mykernelnambe
init 1
make installworld
reboot
pkgdb -F
portupgrade -arR
will recompile every last line of the OS, and then fetch source code from the distribution site for every port that has an update available (the -a), check checksums, grab the ports upon which these packages depend (the -R [ok, this is overkill:) ]), compile those, compile the updated packages, and then do all packages which depend upon the freshly compiled packages (the -r).
a really cool process, which eats tons of cpu & banwidth
hawk
Re:or FreeBSD (Score:2)
CPUTYPE=p2
CFLAGS=-O2 -pipe
to
Re:or FreeBSD (Score:2)
I dunno.
the first time, close to forever
hawk
Not for everyone, then (Score:5, Interesting)
Where I think this would come into its own is on a site, like a university or large company, where there are (a) hundreds of identical machines with exactly the same specification (down to the position of the sticker on the case), and (b) people who know what they're doing (ha ha) in charge. You could amortize the time taken to create the optimised system over the savings once you've installed it on every PC.
I wonder if they support using a compile farm to perform the rebuild? That would be sweet.
Re:Not for everyone, then (Score:1)
I compile everything from sources nowadays, it really makes a big difference for the graphical stuff (XFree, Gnome , KDE, etc).
You're right about the sites where there's plenty of identical machines (just clone it!), but there's also good use for your average user nowadays. Most people have sufficiently capable hardware to compile their own linux. And if you don't: just type in "make everything-as-i-want-it install" and go outside! get some fresh air, it's good for you
make buildworld (Score:3, Insightful)
I've been wondering when someone would do a linux distro that compiled itself during instalation, or at least a kernel.
Re:make buildworld (Score:5, Funny)
You see where I'm going with this, of course... but compare your situation to mine. I've got one machine that I use regularly that is five years old, and therefore has a P/133 in it (it's a laptop, and it works for the things a laptop should do, there is no reason to go spending hundreds of dollars on newer hardware). That said, I disagree with our erstwhile whiner about the compile times being an issue. It won't take weeks, but it will take some effort and maybe a few days, especially if you don't have an automation tool to help you. Even so, set the larger packages to compile when you go to bed, or off to work, or whenever. And think of this as a one time investment, you won't be recompiling most of this stuff over and over.
If this distro does even half of the hard parts: knowing where to get fresh source code, downloading the code to a local repository, helping configure the build, automating the build process, then it's quite a boon. And yes, you may have to wait for some time for this stuff to compile and install, but through the magic of CVS you might not have to wait so long to upgrade parts of it. *And* you get all the benefits of compiling from source- optimizations, special
Re:make buildworld (Score:2, Informative)
now in saying that yes I believe the packages are a bit bleeding edge, and I had to deal with a kernel which had a broken 1284 driver (IEEE printer) but life goes on and new kernels are released. From what I saw a cast sorcerer has MUCH less chance of breaking your system than apt-get dist-upgrade from debian unstable, and is the next move up the food chain for the bleeding edge software crowd.
all in all if I was rateing sgl I'd give it perhaps a 3 or a 4 out of 5 stars. it's speed and outright power on amd archetectures (like almost every computer in my house) is a huge boon, as well as the rest of the systems, as the scripts continue to advance this distribution will become better and better. that is unless binary distributions would like to give me stock kernels, and packages in
again just my $.02
Trelane
Re:FYI make buildworld (Score:2)
Re:Not for everyone, then (Score:2)
Well, this distro uses a thing called tmpfs, in which it does most of it's compiling operations in a RAM disk. I would assume this means that you need ample RAM, however, but it should speed things up considerably.
\
make world (Score:2, Interesting)
So now we can have packages optimised for out platform at the cost of building everything from source. Sounds like a heavy cost to me. Wouldn't it be more efficient to provide a couple of different binary packages for each package a'la mandrake (i586 and i486) ? Compile once and let everyone install them as opposed to everyone compiling ?
It decreases the CD count (Score:2)
Wouldn't it be more efficient to provide a couple of different binary packages for each package a'la mandrake (i586 and i486) ?
That would cost more for the CDs and for download bandwidth, especially when you take into account Alpha, Sparc, MIPS, and all the other PC-class-or-higher architectures that Linux runs on. See also my Everything 2 article about making Linux distributions smaller [everything2.com].
Re:make world (Score:2)
Yes and no.
If you take into account the LOST efficiency of the enduser not being able to compile their kernel (or glibc, or bash) with their optimizations, then no.
Things like being able to use 2.95.3 instead of 2.96, or being able to use stackguard. These are the beauties of a source-based distro.
Not to mention the architectures that the distro maker doesnt have hardware to test on, nor time to test on. PS/2 anyone?
So, no.
Plus, your argument puts the burden on the distro-maker to compile for all the different architectures, host them, and provide the bandwidth for all of that.
Sorceror (very wisely) has you download the majority of the distro from upstreams upon recasts.
Re:make world (Score:3, Informative)
The software RAID code for example will, during bootup, try it's checksumming using different of the available extensions (think MMX, 3DNOW, SSE, SSE2, etc) and pick the fastest one.
ObPratchett citation (Score:1, Funny)
slashdotted (Score:1)
Its slashdotted, heres the text with paragraphs (Score:5, Informative)
Would you like a Linux distribution which is 100% optimised for your hardware? Would you like one which includes the very latest software packages as they are released by their respective maintainers? How would you feel if we told you about a Linux distribution where the entire download-compile-install process of any software (including the Linux Kernel, glibc, GCC, KDE) is done by one simple command? Intrigued? Then read on. Welcome to the magic world of Sorcerer GNU Linux!
1. Introduction Once you install a few Linux distributions, you will soon get to understand the basic process, which is rather similar in most mainstream distributions. Partition your hard drive, select the packages to install, listen to the CD spinning in your drive and when it calms down, you might do some hardware and network configuration to conclude the process. Less then an hour after inserting the installation CD you will have a fully working Linux system on your computer.
But things can be done completely differently. The beauty of Linux is that there are plenty of ways to achieve the same goal. As long as we are free to exercise our creative abilities and implement the resulting ideas, we can create amazing things.
Just think about this for minute - since the vast majority of Linux software comes with source code, why is it necessary to download binary files that somebody compiled on a particular hardware platform and included all sorts of options to run it on thousands of different hardware configurations? Would it not be more logical to compile everything on your own machine, ensuring that the code is optimised for exactly your hardware?
Enter the magic world of Sorcerer GNU Linux, a Linux distribution with a difference.
2. Basic Information Sorcerer GNU Linux (SGL) is a new Linux distribution. Its first release was produced in July 2001 and subsequent updates were very frequent at roughly twice a month. The project's web site is unlikely to win any design awards, but the essential information with FAQs and mailing lists to get anybody started is present.
The basic philosophy of Sorcerer GNU Linux is amazingly simple - after installing it, you will end up with the most optimised system for your particular hardware configuration and, at the same time, you will be running the absolute latest software available.
How does Sorcerer achieve this? First, you download the compressed ISO image, unzip it, burn it to a bootable CD and boot from it. After answering a few questions, you will watch the installation of a basic Linux system on your hard drive. Nothing really differs much from any other distribution until you get to the kernel compilation stage. And this is when things become interesting...
But we will leave a more detailed description of the installation process for the appropriate chapter. Here, just a basic overview: After your kernel is compiled, you will reboot into a brand new system. You are invited to configure your networking, knowing that soon there will be plenty of interesting code running down your cable or telephone line from various parts of the world. The great fun of selecting, downloading and compiling your packages can begin.
So what is the downside of such a distribution? If it is so great, why isn't everybody using it? The main reason is the fact that it takes a bit of knowledge and a lot of time to get Sorcerer GNU Linux up and running on your computer. Installing most other distribution will last less than an hour before you get a full-featured Linux desktop with several window managers, servers and more applications than you can shake a stick at. With Sorcerer, well, you'd better reserve a rainy weekend for it if you'd like to achieve the same. Some people might find this too time consuming, but those of us who like to tinker and optimise every bit and every byte of our hardware and those of us who like to run the latest software as it is produced, will find that Sorcerer is a dream come true.
3. Installation Let's get going with the installation process. There are several steps to accomplish this:
1. Download the compressed ISO image. 2. Install a basic (binary) Linux system from the downloaded CD image. 3. Compile the kernel. 4. Configure networking. 5. Recompile all the applications from the original CD image. 6. Get, compile and install all applications you need.
We will look at each of these steps separately.
3.1 Downloading Sorcerer The Sorcerer GNU Linux can be downloaded from the project's web site and its mirrors (see the side bar for links). The size of the compressed ISO image is about 80 MB and this swells to about 250 MB after unzipping the archive. You can use any standard CD writing tool to create a bootable installation CD.
Keep in mind that this ISO image gets updated frequently, so your downloaded image will quickly become out of date. This is where a unique feature to update the downloaded ISO image comes handy. This was primarily designed for those on a slow connection - instead of downloading the entire new ISO image, you can opt to download a small patch with the *.xdelta extension. To upgrade the original ISO image to the latest version, simply type:
xdelta patch sorcerer-$OLDDATE-to-$NEWDATE.xdelta sorcerer-$OLDDATE.iso sorcerer $NEWDATE.iso
This command will produce a new ISO image. Now you can verify the md5sum of the new ISO and if it matches the one found on the Sorcerer's download page, the image is ready to be burnt!
Naturally, there is no need to get the latest ISOs if you have Sorcerer GNU Linux up and running, but this feature might come handy in cases when you wish to burn the very latest image without actually downloading it. This way you can always keep the latest ISO image on the hard disk in case you decide to do a new installation or in case you would like to pass the latest image to a friend.
3.2 Installing a Basic System This step is, in most parts, similar to installing any other Linux distribution. The installer offers partitioning tools, such as fdisk, cfdisk and parted to create partitions. You can then proceed with selecting your root partition and its file system (ext2, ext3, ReiserFS and XFS are offered) and a swap partition. You will be advised to create a large swap partition, the basic rule is that your amount of RAM plus the size of swap partition should be at least 1 GB. Do not ignore this advice! Although the installer will complete the installation even if the above condition is not met, you will run into trouble later when trying to compile large programs and get frequent "out of memory" errors.
This memory requirement might seem strange at first, but the logic behind it is that Sorcerer makes use of "tmpfs", a virtual RAM drive which can also use swap space, to accelerate compilation and minimise file system fragmentation. Because of the "tmpfs" file system, Sorcerer expedites compilation by making the most efficient use of RAM. This makes sense as you are about to do a lot of compiling and the compilation speed gains are definitely noticeable.
As soon as the partitioning is done, you can start with the installation. Note that at this stage you are still installing binary files found on the installation CD to create a basic working system. These packages will be recompiled at a later stage.
3.3 Compiling Linux Kernel The next step is where similarities with mainstream distributions end. Yes, you are going to compile the kernel. This is of course where you can spend quite a lot of time tweaking and optimising, but at the very least, you should make sure that you select all the necessary modules for your hardware. Check the modules for your network, sound and video devices as well as any other hardware you need. Of course, you can always recompile the kernel later if something is missing.
After the compiling is done, you will be prompted to configure networking.
3.4 Configuring Networking First of all, you need to load the module for your network card (provided that you have compiled it into the kernel). This is best done by creating an alias in your /etc/modules.conf file: 'alias eth0 network-card-module', then loading the module with 'modprobe eth0'. At this point you should have a working network card. If you had compiled the network driver into the kernel, the above step is unnecessary.
Sorcerer used to provide both DHCP a PPP support to connect to the outside world. Being on ADSL connection, I looked for a PPPoE support which my service provider required. I failed to find any way to connect with the tools provided so I had to install Roaring Penguin's RP-PPPoE package, sources of which I had on another partition. When I mentioned this to Kyle Sallee, the author of the distribution, he promptly produced a brand new Sorcerer release with the PPPoE support built into the installation script! "If you need anything slightly more exotic, just provide me with the details to set it up", replied Kyle.
Ah, the wonders of personalised technical support only available in niche distributions!
3.5 Recompiling Installed Applications You only need to execute two commands in this stage, but the execution is likely to kill an entire evening. The two commands are: 'sorcery update' and 'sorcery rebuild'. The first command simply fetches the latest application database from the Sorcerer web site. This is to ensure that you do not compile older packages if newer are available.
The second command recompiles the existing software on your system. This process is interactive by default and you are prompted to look at the compilation log after each package. It is possible to disable the prompt in the sorcery menu so that you can run this process during your sleeping time. And when you wake up, you will have a 100% optimised system and it is not even necessary to reboot!
3.6 Getting, Compiling and Installing Applications The final step towards a fully working Linux box is downloading, compiling and installing all the software (or spells, in Sorcerer's terminology) you need. The beauty of this seemingly troublesome and scary process (especially if you have tried to do this on other distributions) is that all this is done by a simple command, which is 'cast package-name'. If you prefer a menu-driven way, you can simply type 'sorcery' and you will be presented with a categorised list of applications to choose from.
The list of applications (or spells) is taken from a database called 'grimoire', which is a sorcerer's book of spells containing nearly 700 spells at the time of writing. This database is updated daily ensuring that all new software releases find their ways into the grimoire within a short period of the official release. Trying to impress your friends? Sorcerer GNU Linux will certainly make them green with envy...
So how are all the dependencies resolved, you might ask. Isn't this part the most troublesome of all? The dependencies are taken care of for your convenience and peace of mind. Once you cast a spell (i.e. execute a package installation command), you will be prompted to include all the necessary dependencies into your spell. Additionally, you will be prompted to include or exclude optional dependencies, another feature not found in any other Linux distribution. The most amazing thing about this feature is that the entire download-compile-install infrastructure was written in nothing more sophisticated than Bash.
As soon as the basic stuff is installed, you are free to indulge in the vast packages resources provided by the distribution. You can continue with compiling XFree86 which is a rather lengthy step, taking nearly 40 minutes on the Pentium 4 machine. Casting XFree86 prompts you to run the configuration menu, which is an essential step if you would like to include specific drivers for your graphics card. Afterwards you can proceed with casting a window manager of your choice (the very latest versions of KDE, Gnome, WindowMaker, IceWM, Sawfish, Enlightenment, AfterStep, Blackbox and others are included) plus its associated libraries. Install any other software you need and a few hours of largely incomprehensible messages on your monitor (unless you prefer to turn this output off) will produce a pretty complete system by any standard. The Sorcerer's spells have been cast!
4. Post-installation Now you have a complete Linux system ready to be put to productive use as would be the case with any other Linux distribution. But apart from having the most up-to-date and most optimised system within a considerable radius of your location, there are still some interesting and unique tricks up Sorcerer's sleeves, not seen anywhere else. Let us examine some of the more interesting ones:
1. Software updates 2. Sorcery options 3. Rescue and maintenance
4.1 Software Updates The beauty of this distribution is that it is incredibly effortless to keep up-to-date with the ever evolving Linux application world. With a simple command of 'sorcery update', you can do a system-wide update of your entire installation. Creating a crontab entry for this command to run every night will result in a completely seamless update of your applications. Wouldn't it be nice to wake up one morning to find out that you have a brand new KDE desktop without as much as moving your finger? With Sorcerer GNU Linux, this is indeed a reality.
There are two ways to update software on your system - a menu-driven sorcery and a command-line sorcery.
Beginners might find the menu-driven way easier at first and it is certainly worth a look. The utility is invoked by typing 'sorcery' on the command line. The first option on the list is 'Spell', which, when clicked, reveals a further submenu. From this menu, you can select to install new applications from a categorised list of nearly 700 spells, you can recompile all applications on your system, you can select applications that should not be updated during the next system-wide update and you can remove applications from your system. The menus are very logical and self-explanatory and help is provided in the form of (sometimes humorous) one-line hints at the bottom of the screen.
Updating your system from the command line is equally easy once you master a few simple commands. Installing a new package is done with the 'cast package-name' command; just remember that the term 'install', used by most other Linux distributions is not accurate as 'casting' actually involves downloading, compiling and installing the package. Ever tried to compile KDE on another Linux distribution and gave up because of the hard work involved? With Sorcerer, all you have to do is to type 'cast kde' and off you go, no more studying of installation instructions, interpreting cryptic error messages and searching newsgroups! It really is as easy as that!
The next command you will use frequently is 'gaze'. It offers an amazing array of useful options, which you can view by simply typing 'gaze'. Would you like to see a list of all packages installed on your system? Type 'gaze installed'. Do you want to see the list of available packages? Type 'gaze grimoire'. Fancy to find out the package's description, web site, maintainer or md5sum? How about searching the package list, viewing compile logs or listing the source files for a package? All this and a lot more can be done with the 'gaze' command, which is worth investigating in detail.
4.2 Sorcery Options The Options menu in 'sorcery' offers a range of useful features. We will only mention some of the more interesting ones, but do take your time to find what else is offered.
The PROMPT DELAY option allows you to set the delay time, in seconds, for prompts while compiling and installing multiple packages - if no input is given within the specified time, a default action is taken.
The APPRENTICE option allows you to execute a command even if the associated package is not installed on your system. Sorcery will simply download, compile and install the necessary package before executing it. The list of executables and associated packages is stored in the /var/lib/sorcery/apprentice directory.
The AUTOFIX option, if enabled, is very useful in cases when important system libraries get updated. This would normally break most packages that depend on these libraries, but the AUTOFIX options checks and rebuilds all packages that would otherwise be broken. This option is enabled by default. It is worth noting that any packages that need to be rebuilt as a result of updated system libraries will not be downloaded again, but rather compiled from sources already present on your hard drive.
Imagine for a moment that a new version of glibc gets released. To update it, you can simply 'cast glibc', which will build a new glibc, remove the old glibc libraries and recompile every package dependent on glibc. During this process, there is a brief moment when there is no glibc in /lib or /usr/lib, but despite of that no application already running on your system will be affected! The Sorcerer's magic at its best!
Other options worth mentioning are MAIL_REPORTS, which will e-mail installation reports to the specified e-mail address, VOYEUR, which turns on or off compiler's verbose output and REAP, which, if enabled, causes that upon removing a package, all associated files are also deleted.
Finally, two more useful options to speed things up. To eliminate bandwidth bottlenecks, the software packages do not get downloaded from a central location, but rather from a maintainer's home site, FTP server or mirror. The 'Software Mirrors' option allows you to select a nearby mirror for the Linux Kernel, GNU packages, KDE, XFree86 and Gnome. The last option on the menu is 'Optimize Architecture', which gives you a chance to optimise all source code compiles for one of the available processor architectures - i586, i686, K6 or Athlon.
It should be noted that the list of features is not static, but keeps growing based on user feedback.
4.3 Rescue, Maintenance and Administration It is worth mentioning that your Sorcerer CD can serve as a rescue image as well. If you happen to get into trouble, you can boot from the CD, log in and carry out any necessary maintenance tasks. While this is not a unique feature, it is always nice to see that there is a simple way to log into your Linux system!
The Sorcerer web site provides a categorised list of FAQs in the documentation section and you are encouraged to join the mailing lists where you will receive a warm welcome from the members.
System debugging is handled with the help of extensive log files No other Linux distribution provides this feature, which greatly simplifies bug fixing and bug reporting procedures. The fact that Sorcerer GNU Linux is so highly up-to-date and remarkably bug-free can be partly attributed to the use of these log files Have you encountered a problem during software compilation or installation? Instead of describing it verbally, submit the log file and the bug will be fixed in no time!
The next question that comes to mind is what if you want to install a package not yet available in the grimoire, the Sorcerer's software database? Apart from compiling the package using the standard method of configure && make && make install, you are more than welcome to create your own spells. This way, not only will the new package become part of the sorcery, simplifying the install/uninstall management, you can also share your spell with the rest of the Sorcerer user community. Creating spells is not too difficult and extensive instructions are provided.
Finally, a recently introduced sorcery feature, called 'cabal' provides administration and command execution tools for simultaneous use on multiple Linux systems. It uses nothing more fancy than ssh2 keys, ssh, and scp, a set of simple tools to make a system administrator's life a little easier.
5. Pros and Cons Advantages
1. Sorcerer is 100% optimised. Not many people will argue this benefit. By virtue of compiling every piece of code on your own system, you are making sure that you get as much out of your hardware as you can. Of all the Linux distributions currently tracked by DistroWatch, only three are source-based (the other two being Linux From Scratch and Gentoo Linux). No binary distribution can beat a source-based distribution compiled on its home turf!
2. Sorcerer is the most up-to-date distribution. This benefit might be void in cases where there is no need to run the latest and greatest software, such as in case of some specialist servers. Still, security issues do appear from time to time and having the benefit of an easy path to upgrading the affected application can save many hassles. Because this distribution is so highly up-to-date, all security and bug fixes are applied routinely.
3. Sorcerer offers excellent support, both direct and via mailing lists. In line with most smaller and niche distributions, the author will often personally reply to your concerns and listen to users' suggestions. The PPPoE feature I asked about was placed in the next Sorcerer release literally within a few hours after I e-mailed the author!
4. Sorcerer is continuously being enhanced. While already pretty complete and feature-rich, there are still many new features planned for inclusion in future releases. Of course, many other Linux distributions can claim this, but given the completely unconventional way of doing things at Sorcerer, we can only look forward to more unique features not found anywhere else.
5. Sorcerer is fun to use. Admittedly, this is a highly subjective quality, but I can honestly say that I have never had more fun with any other Linux distro. Period.
Disadvantages
1. Sorcerer takes time to get installed. Installing a Linux distribution is a lot less troublesome than it used to be and most mainstream ones will get you up and running in less than an hour. Sorcerer, on the other hand will require many hours of compiling before producing a full-featured system. However, the benefits of compiling all software are unquestionable.
2. Sorcerer lacks decent documentation. As is often the case with many new projects, the documentation has not been given the highest priority. The current structure of hard-to-navigate FAQs and installation/usage notes resemble a schoolboy's scribbles rather than a carefully designed operating manual. The author seems well aware of this deficiency and welcomes any contributed documentation such as FAQs, man pages or installation instructions.
3. Sorcerer is not for beginners. You don't need to be a Linux megaguru to install and run Sorcerer, but you should be reasonable proficient in basic system administration. There are many choices to be made during installations and configurations of your system, some of which may be vital. You also need a thorough knowledge of your hardware and the kernel modules required by each hardware component. If you are not sure, you can simply accept the defaults, but it helps if you know a little about the Linux Kernel, XFree86, Perl and other configuration options.
6. Summary Of all Linux distributions available today, Sorcerer GNU Linux is positively the most unconventional. Instead of following the tried and tested method of many binary distributions, the development team has not only created a unique product, it has at the same time solved many of the perceived problems, traditionally associated with the Linux operating system. The amazingly simple and fluent method of installing and upgrading software and system libraries makes one wonder why no other distribution has invented anything even remotely similar.
While some may argue that Sorcerer's is a more time consuming method of keeping up with the Linux application development, it is still much less time consuming than resolving library dependencies, interpreting error messages and spending time on newsgroups searching for answers. Because of the sophisticated download-compile-install infrastructure of sorcery (while written in nothing more sophisticated than Bash), keeping your Linux box up-to-date is a painless process. Best of all, every single package is fully optimised for your hardware as it is compiled.
Despite the development team's claim, Sorcerer GNU Linux is, in my opinion, a revolutionary Linux distribution. Do yourself a favour and download the 80 MB file, then find a weekend to explore it. I can virtually guarantee that at the end of the weekend you will be asking yourself questions like: "Why has nobody else thought of this!? Is it possible that installing and upgrading Linux software can be as simple as that?" You will have to pinch yourself to believe that you are not dreaming.
I do not normally indulge in predicting the future. But if only 6 months of development resulted in the product of this sophistication and quality, then I honestly believe that Sorcerer GNU Linux is going to become a major Linux player in the near future.
Re:Its slashdotted, heres the text with paragraphs (Score:2)
But will it do.. (Score:2)
2. reply to my girlfreind's daily comedy emails with replies that actually sound like I was at said site.
Seriously what more besides apt-get do people need for updates? I mean I was so disenchanted with mandrakeupdater that when I got back into the swing of linux after a dry spell I almost gave up. Now with debian at least I can update things without fear of the kernel segfaulting on the next boot.
Re:But will it do.. (Score:2, Funny)
B is to C as A is to B (Score:5, Informative)
I am an avid Debian user, and have moved an entire enterprise over to Debian because apt-get makes a system administrators life so much easier and it halved my work load as a result. For binary distributions apt-get is unmatched, and apt-get source, while not perfect, is a very nice way to get sources and compile them.
However, there are better approaches. FreeBSDs "ports" system comes to mind, where a skeletal directory tree structure and a simple make command are all that are required to automate the download, compilation, and installation procedure for a plethora of third party applications.
No library conflicts. Any necessary patches applied on the fly, optomized and compiled for your system. It was, until this distribution came along, the only installation method I'd ever heard of, much less seen, that beat even apt-get hands down.
If this distribution lives up to its billing, it will be only the second, placing Debian's apt-get, Sorcerer, and FreeBSDs "ports" in a class all their own. Even as an avid Debian user I will be spending much of this weekend playing with Sorcerer.
The real question is, will there be a good replicator or, better yet, automated installation utility so I can build 50 machines on 50 similar but not identical machines, without having to sit in front of each one? Replicator is the one thing that will keep me using Debian at work
Can you be more specific (Score:2)
Can you provide any more details (name of the command, where to poke around for docs, etc.). Even a hint as to what to look for, given that "it is not obvious" would be helpful.
Re:B is to C as A is to B (Score:2)
I may post this again in a different thread just in case it turns out to be hidden down here...
Re:But will it do.. (Score:2, Interesting)
(something like a day after freshmeat).
I wander if simply compiling on the user machine
does so much simplify putting together packages
to make a distribution.
Is this similar to *BSD? (Score:3, Interesting)
Just a question: is this distribution's approach similar to the BSDs? I think if not the same, it is very similar to the ports system, a very useful and clever approach in a lot of respects.
On the other hand, I don't think that many people would be that keen to recompile KDE/Gnome from scratch every time! Specially in legacy (i.e., more than 3 months old) hardware. However, for a (say) dedicated web server or something like that, it might have its uses...
Re:compiling X and KDE (Score:2)
I wonder if I can break a minute on my XP 1600+!
What about Aunt Tillie? (Score:5, Funny)
Does this mean Aunt Tillie gets to build her own kernel [slashdot.org]?
Damn, That was fast! Leave it to the GNU community!!!!
Mirror of distrowatch review (Score:4, Informative)
Gentoo Linux (Score:2, Redundant)
Not totally convinced (Score:5, Interesting)
First they ask that your swap image be at least 1gb in size. I don't know about everyone else, but my linux partition is just 2gb so that's half of my disk already. I know, I know, these days everyone has 30, 40, and 60gb drives so it's not a big deal. Maybe it's just time for me to get more iron.
Anyways, the big feature this distro seems to be claiming is the automatic (and seamless updates). You can run this "sorcery update" command in a cron job at night and have a brand spanking new system the next morning. While this sounds like the cats meow, what if I don't want the latest and greatest? I personally don't to live on the bleeding edge and don't always want the lastest. Also, who decides what's the latest? The latest beta? Is it running the 2.4.17 kernel or something even newer? What version of KDE does it have?
It's also a huge distribution and requires a dedicated weekend to get up and running. The name implies that it's something that a beginner could sit down and startup with, but this is not the case. If you're looking for a simple install, stick with Mandrake/RedHat or something. If you have a few gigs to chew up and a weekend to burn, maybe give it a try.
liB
Re:Not totally convinced (Score:4, Insightful)
The problem behind that is that the 2.4 kernel series recommends double your ram in swap. Since ram is ultra-cheap, and the average computers have 256-512mb ram, voila, 1 gb.
>Anyways, the big feature this distro seems to be claiming is the automatic (and seamless updates).
And compiling from source, using the settings you prefer. And using upstreams sources generally.
>You can run this "sorcery update" command in a cron job at night and have a brand spanking new system the next morning. While this sounds like the cats meow, what if I don't want the latest and greatest?
Then dont run the sorcery update!!
>I personally don't to live on the bleeding edge and don't always want the lastest. Also, who decides what's the latest?
The upstream, actually.
>The latest beta?
No.
>Is it running the 2.4.17 kernel or something even newer?
2.4.17
>What version of KDE does it have?
Umm.. Dont know off teh top of my head, but it is probably listed on the site, at least the current ver #'s used to be.
All in all, they are fairly cutting edge, but you can always choose NOT to be. Just dont cast the latest version!
Re:Not totally convinced (Score:2)
Makes it nice and fast, but at the expense of needing some decent swap space and ram....
Re:Not totally convinced (Score:3)
However, that 1-gig swap file turned me off. I'm on a 2 gig disk, with either a 32 or 128 meg swapfile (16 megs memory), on an aging p166 that's my DHCP server. (Working fine too, other then a problem with
Just my $.02
I've entered a weird parallel slashdot dimension.. (Score:3, Interesting)
I just posted this [slashdot.org] last night...
Optimization (Score:5, Interesting)
There is just one disadvantage; while you are compiling that latest version of XFree86, gnome or kde the computer does not feel really optimised.
Compiling everything is just too much hassle, and takes too much time and computing power.
For a server there are not that many packages installed, so it can be usefull. But on my desktop I have about 2Gb software installed. Keeping that up to date.......nah.
Just let me update everything from binary, be it apt-get or urpmi.
Btw, I have a friend who was horrified when I showed him apt-get. Do you update from binaries? Do you call that security?
He liked to install security-updates from source.
When asking sometime later how he kept his FreeBSD boxes up to date he said he did not do that. He felt safe behind a firewall.
Hmm, I guess it is just too much hassle.
not just about optimization (Score:5, Insightful)
Sometimes (most often in the case of SSL) you'll see multiple versions of the same package to satisfy problems like this. This is a hack to solve the problem. Sure I can install lynx-ssl instead of lynx but what if I want lynx to use slang instead of ncurses?
This is more about control than optimization. While I'm not sure this level of control is necessary for everyone, control is one of the selling points of Open Source Software and something that most people like to have.
Re:not just about optimization (Score:3, Informative)
But instead of compiling everything from source you can just get the specific src.rpm, edit the specfile and rebuild the rpm with your options.
I am mostly just talking from the way I deal with it.
Mostly I do not really care about dependencies or build options. There are just a few packages for which I find it really important.
Another point though.
Building software from source has often its own dependencies. You need a compiler suite and lots of headerpackages.
I recently struggled a lot to get a kernel built on my Alpha firewall with only 300 Mb disk.
Re:not just about optimization (Score:2)
Plus, if your really stripping postgre support from the binary what happens when you latter want to install postgre? Shure, your not going to be installing postgre later if it's a server, but you might be installing postgre if it's your desktop.
Clearly, there is a market for an opimized server distribution, but flexibility is more importent in a desktop distribution. RedHat could just fork it's AMD and Intel distributions to get most of the benifits of opimizing.
Re:Optimization (Score:2)
Doing it in real time is insane, but over night isn't so bad.
Re:Optimization (Score:2)
While paranoia is a valuable quality to have when you're dealing with security issues, it is most helpful when it is carefully directed. One has a limit amount of time and attention to spend on things, and being paranoid about silly things is a waste of those valuable resources.
Paranoia about installing from source instead of binaries is misdirected unless you friend personally inspects the source very carefully for trojans before compiling anything.
The only thing you're protecting against if you compile from source is if the distribution maker has a piece of malware that auto-trojans any binary created with their toolchain. On the threat scale, I would consider that one pretty unlikely, and the energy spent trying to protect against that would be better spent protecting against some more likely threat.
In fact, keeping the FreeBSD boxes up-to-date is probably a good protection against much more likely threats than the one I outlined above.
Re:Optimization (Score:2)
>FreeBSD boxes up to date he said he
>did not do that.
did he call the police after you smacked him?
yikes, it's so bloody easy in bsd you can script it . . . (which I'm to paranoid to do . .
hawk
Re:Optimization (Score:2)
apt-get source package
Don't Pheer the Source! (Score:5, Insightful)
Here's what you do on your distro (if it will let you compile from source without mangling the package system):
Monday: compile the kernel and glibc
Tuesday: compile gcc, binutisl, textutils
Wednesday: compile XFree86
Thursday: compile kde-libs, kde-base (or gnome equivs)
Friday: compile kde-network, kde-utils (or gnome equivs)
etc
etc
etc
The advantages of doing your own builds, summarized (you can get detailed advantages on the sorceror, gentoo and freebsd pages):
Significant performance increase
Customized package configuration (Dia without GNOME, Xmms with mods, etc)
Fewer dependency problems (let configure worry about which exact libs you have installed)
Binary packages are convenient during installation, but they shouldn't be the final product on your box. They're so you can get a system up and running fast. Afterwards you can rebuild everything in the background while you're posting your trolls.
Most of you Linux guys are fanatical about Open Source and Free Software. It's your mantra and credo. Yet you fear the words "./configure; make; make install" every bit as much as the clueless windoze lusers. Free Software is meaningless without source code. Without source it might as well be proprietary freeware. Source code is your power. Don't pheer the source!
A Free Operating System allows you to do whatever you want with it! You are in control. Your box is yours. So why is some release manager at Redhat or SuSE your sysadmin-by-proxy?
Re:Don't Pheer the Source! (Score:2)
Re:Don't Pheer the Source! (Score:2)
I haven't build GNOME in a long time, but I build KDE from source every release. I've never had a problem with it building. I'm using FreeBSD, so it's a completely painless affair, but when I used Slackware it was still a simple matter.
No, there isn't a unified KDE build system for just KDE. Perhaps there should be. But writing a build system for KDE that covers not only building KDE (the easy part) but accounts for and builds all dependencies is a significantly harder thing to do than write an apt-get or ports like system. The reason is that KDE runs on all unices, not just the one you're using. Writing such a system that works for Debian, SuSE, Solaris, IRIX and OpenBSD would be a nightmare. It's tantamount to writing the next generation of autoconf. This system would have to upgrade X11R6, libxml, audiofile, pcre, Qt and png, among others, on all possible systems. Just thinking about it staggers me.
So let the OS/distro handle this problem in small OS/distro size chunks.
You KNOW that your distro has a tool or set of tools to build the whole distro from scratch. That's how they make the distro to begin with. So maybe people should be bugging Redhat, Mandrake, SuSE, etc., to make these tools available in a unified end-user format.
Re:Optimization (Score:2)
Also, building from source; a lot of packages need other packages like tetex to even build.
And compiling kde on my previous amd300, kdelibs took already 6 hours or so.
I am sure my dual celeron will be somewhat faster at it though.
Depends on what you've got. (Score:2, Interesting)
If I was on a 56K modem and a slow machine I'm not so sure that this would be worth while. But slow machines are getting rare now.
TWW
Re:Depends on what you've got. (Score:2, Insightful)
Memory Requirements (Score:4, Funny)
You will be advised to create a large swap partition, the basic rule is that your amount of RAM plus the size of swap partition should be at least 1 GB. Do not ignore this advice! Although the installer will complete the installation even if the above condition is not met, you will run into trouble later when trying to compile large programs and get frequent "out of memory" errors. This memory requirement might seem strange at first, but the logic behind it is that Sorcerer makes use of "tmpfs", a virtual RAM drive which can also use swap space, to accelerate compilation and minimise file system fragmentation. Because of the "tmpfs" file system, Sorcerer expedites compilation by making the most efficient use of RAM. This makes sense as you are about to do a lot of compiling and the compilation speed gains are definitely noticeable.
Reminded me of a quote from an old fortune file: Virtual Memory ? Wow! Now we can have really large RAM disks...
Similar to an idea I've been mulling over (Score:5, Interesting)
The user would then pick what software they want installed on their system, as per any other distro.
The server site can then take the source, recompile it for that configuration, and generate a set of ISO images containing the optimized setup for that machine.
One advantage of this approach is that if you're installing on multiple identical machines, you would only go through the process once. Once it's done, you'd have a set of "instant" install CDs. No menus, no further tweaking, just a direct blast onto the hard drive(s).
A second advantage is that a server site can have a compiler farm, making the build process MUCH quicker than would be possible for an individual.
A third advantage is that if someone sends in a configuration which matches one that's already been done, the compiler farm only needs to rebuild updated packages. The rest has already been done. The CDs can then be built out of freshly-compiled binaries and pre-compiled ones.
A fourth advantage is start-up time. Because you're downloading a very basic bootstrap, rather than a mini-distro, the time to download, install and run is going to be much much less.
The last advantage is when it comes to updating your system. Again, with all the compiling being done on a remote compiler farm, the time it would take to do a basic update would be minimal, compared to Sorcerer, and far more optimal, compared to Up2Date or Red-Carpet.
The key to something like this would be the detection of hardware and (on networks) servers. Kudzu is good, but it's limited. sensors-detect is OK, but it's specific. I don't know what Anaconda uses to detect the graphics stuff, but again that is good, but specific. Any router can detect other routers working with the same protocol. There's plenty of stuff that none of the above detect, but would need to, for a truly optimized build & auto-configure. (Is the network multicast-aware? Will the network support ECN? What is/are the IP addresses of routers on the network? Where is a DNS server? Is the sound device better supported under ALSA or OSS? Do memory constraints indicate optimizing for speed or size? etc.)
An optimized build is more than just tweaking the configure options. It's also choosing the right compiler (where multiple options exist). It's setting up the configuration files for those things that can be discovered. It's about asking for the information that's needed, rather than the information that can be found out.
My idea would be that the servers would have a database, containing source and binaries, identified by a 1-way hash of the relevent hardware information. This avoids any privacy issues, as there's nothing private stored. Each access would amount to a search for all records where the hashes of the relevent hardware match. For updates, the user's machine could then select/deselect stuff it already had. The rest would be put into ISO form, and be available for download.
Re:Similar to an idea I've been mulling over (Score:3, Insightful)
All of the other things you mention are matters of choosing which binary package to install, or how to configure them. There's nothing to be gained by automatically recompiling.
Re:Similar to an idea I've been mulling over (Score:5, Insightful)
Nobody in their right minds would spend money on a brand-new Athlon or P4 system for a printer server, so you're likely looking at needing 486 and 586 options.
The ARM/StrongARM architecture is probably just as important as the PPC and PPC64 architectures. Then, as you say, there's the Sparc and Sparc64, the Alpha, the s390 and s390x (hey! IBM are spending big bucks on promoting these!), the parisc (HPUX is carp, which means Linux is a viable option for HP boxes), the Motorola 680x0 series (lots of VME crates out there, and not everyone likes VxWorks), the Itanium (yeah, that does exist), MIPS and MIPS64, and the User-Mode Linux architecture. There are other architectures (eg: the VAX) and other OS layers which can sit on Linux (eg: FreeVMS), and the list is continually growing. Rather than pre-compiling everything for a system combination you don't know will ever be used, it really does make more sense to wait until someone says they want to use it.
Ok, so we've plenty of architectures, and at least five compiler options that need to be considered, depending on the hardware. What other possibilities are there?
Well, if you don't have a sound card, and you don't desire a network sound daemon, then you probably don't want sound support compiled into applications. Likewise, if you have a text-only system or a headless system, and don't want any X support, then you don't need GUI support in your apps. (For something like emacs, this is quite significant.) Linuxconf has support for remote administration. If you don't want external network suport, you're not going to be needing that.
On the flip-side, let's say you opt for a MOSIX configuration, or have an SMP system. If an application can support threads, you probably want to include that. You can't get any benefit out of the system, if you prevent it from sharing the work. Then, there's X itself. You only need the drivers for the hardware you're going to use. You also might want to enable extensions, where applicable. Dual-headed systems do exist, but they're not much use if the software isn't told about them.
If you've opted for a secure system, you might well want applications compiled with SE-Linux support enabled. Setting up a development box, rather than a high-performance server? Then maybe libraries need to be compiled with debugging & profiling, and no optimization.
Setting up an embedded box? Then compile with maximum stability in mind. Performance isn't so important, in these cases, but you'll notice any downtime. If it's a home-user box, hey, they can handle an application crashing once a week. No big deal. Tell that to a robot explorer on Mars, an oil flow control system in a pipeline, or an air traffic control system at peak time.
Then, there's the ability to link to different libraries, depending on what's installed. That, in turn, depends on what people want installed, what the system needs to function, and what else is necessary to meet both of those two requirements.
At this point, the number of options has totally exploded. There is simply no way on Earth you could handle all those possibilities, as pre-generated setups. Indeed, most distros have dropped support for many architectures, because they COULDN'T do it as pre-generated setups.
I think compiling on-the-fly, on a server farm, would be the only realistic way to provide this level of support. "But who would WANT to provide that level of support?" Me. Because I'm not satisfied with second-best, especially when the best is easier and requires less effort.
Why put out extra effort, in order to do less than you could? That sounds so....... stupid!
Re:Similar to an idea I've been mulling over (Score:2)
Realistically speaking, general-purpose options hit all but one in a hundred installations. Actually, I'd be willing to bet that i386 optimization is perfectly good for that amount of people. Throw in i686/athlon optimization, and add a high-stability/high-performance split, and you've down to something like one in a thousand.
For the rest, including the cases you mention -- the Mars explorer team, and those who are just "not satisified with second-best" can certainly compile their own apps without the overhead and potential extra problems -- not to mention expense -- of the server farm idea. The return on investment (in many senses) just isn't worth it.
Re:Similar to an idea I've been mulling over (Score:2)
No offense meant to the others, but x86 is probably the most popular architecture. Maybe:
i386
i586
i686
k7
At least for the kernel! That way you hit the low end print servers, the P5-166s that are running as gateways, and the higher end machines.
Re:Similar to an idea I've been mulling over (Score:2)
Re:Similar to an idea I've been mulling over (Score:2)
:-)
Re:Similar to an idea I've been mulling over (Score:2)
Now, if you were to combine the schemes (central repository & P2P), you'd have something a lot more powerful than either solution, and both the above problems would be resolved. (You could ensure that the central repository -started- at the critical mass point, and because that would handle "common" queries, only the unusual stuff needs to be distributed P2P, which would eliminate all the real bandwidth killers.)
Re:Similar to an idea I've been mulling over (Score:2)
Please don't ever ever ever ever design something like this. For if you do, I shall smite thee.
Re:Similar to an idea I've been mulling over (Score:2)
Well was just an idea that came on top of my mind.
Too bad that this would not work, because compilation is one thing that requires much CPU and would benefit from a distributed service.
Re:Similar to an idea I've been mulling over (Score:2)
Re:Ever did `make config' yourself?! (Score:2)
Yes, this is why modules were invented. It's basically a problem that's been solved, modulo a few issues. Precompiling a million different types of kernels isn't really the answer.
Re:Ever did `make config' yourself?! (Score:2)
As the maintainer of the FOLK series, I probably encounter more Linux compilation options than most people. The number of #'s for the COMEDI network support is impressive, and even the binary compatibility code offers a fairly comprehensive set of possibilites.
However, how many of these options are VITAL for the user to tweak to producing a working kernel? Very few. The processor, memory available, SCSI drivers, IDE drivers, serial drivers, sound drivers, network drivers, etc, can all be set by software, through detecting what is present.
Network protocols can be detected by snooping and testing what works and what doesn't. Frame buffers aren't accelerated (yet), so you don't want them if you have a card that X supports in accelerated mode (assuming you install X).
As a rule-of-thumb, I compile ONLY frequently-used code into the kernel, and have everything else as modules. This gives me a balance between performance and memory consumption.
Of the options that are left, some can be compiled as modules. In those cases, just do that and have done with it. ONLY in the remaining cases do you need to ask the user ANYTHING.
Remember, we're not talking about a self-maintaining, "can't tweak it, or it'll break" type of system. We're talking about a system that'll do its damnest to give you the best, so that your tweaking can concentrate on making it better yet, not merely "good enough".
That's one of the major differences between this dynamic approach, and the static ones others use. This allows you to play with the system, in unpredictable ways, without breaking the mechanism. In fact, if I were to ever build this kind of meta-distribution, I'd encourage people to "post" tweaks to it, so that future personalized builds for everyone can be that much better.
In short, Open Source the process of building the distribution itself.
Re:Ever did `make config' yourself?! (Score:3, Interesting)
eg: Does the machine have an ISA bus? This is one of the points you mentioned. Easy to find out. You probe for an ISA bus. If there's nothing there, you don't need ISA support. If there's something there, but no cards can be detected, then any ISA option the user picks for the build will probably be better off as a module.
Let's also look at the PPP/SLIP stuff, for a second. If someone has a modem, you cannot determine by merely probing the system whether that modem will be used for PPP or SLIP (or even just raw connections). If it uses PPP, are they wanting ATM over PPP? There are many possibilities, as you rightly say, and many configurations to suit each.
My proposal here is to use the detected hardware to generate a list of questions that need to be answered for an optimal solution, with a "likely" default, based on known patterns.
eg: I'd say that if a user has an ethernet card, a built-in modem, and a modem on the serial port, then the built-in modem is probably "extra" and, if there's a specific driver for it, that driver would be best compiled as a module. However, if the first 1000 people who access such a distribution say "hell, no, I want that compiled directly into the kernel", then there's a decent chance that the 1001th person will have the same reaction, so that then becomes the default.
In other words, the optimizations I'd select will not be fixed. The system would be capable of simple learning and pattern recognition. The most basic form would be to give every possible hardware/software combination an index number, and then use the ordered pair of (kernel option, index) to find the option that most people who had that combination preferred.
How this would work, in practice: Person A has an internal modem, and specifies that they want networking software and a dial-up client. The default for this combination would be for PPP to be built into the kernel. However, person A says "no, I don't want PPP at all." The weighting now shifts, for that specific combination, and no other.
An extremely trivial way to do this is to store the weighting as a floating-point value between 0 and 1. 0 to 1/3 is defined as "don't include". 1/3 to 2/3 is "include as a module". 2/3 to 1 is "include in the kernel". If a value somehow hits a boundary perfectly, then the default would be to go to the lower of the two options. A choice is given a value of 1 for "kernel", 1/2 for "module" and 0 for "not at all". You then simply find the average value, to compute the default most likely to be what's wanted, or close to.
So, back to person A. The value started at 1, but is now 1/2, because they chose not to include PPP. This means that the next person with that same setup will be offered PPP as a module, as the default. If they, too, say that they don't want PPP at all, then the value drops to 1/3, which pushes it into the camp of not being included, in any form, by default, unless otherwise specified.
The most complex such system I can readily imagine for this would be to set up a database as above, but instead of storing a simple value as the data, you could store a simple neural network. The network generates the default. Where the default is different from the selected value, the network is trained with the data set of the selected value, plus any related non-hardware data.
Would such a phenominally complex, massive, overwhelming system have any benefits over just handing over some pre-compiled binaries, plus source?
THAT, IMHO, is a difficult question to answer. At first glance, the answer would be no. The speed/size variations would be too small for Joe Average to notice, under normal conditions. (Although, under real stress, they might notice SOME improvement.)
However, let's examine a few things here. This kind of system would not be aimed at Joe Average, because Joe Average doesn't give a damn about the kinds of optimizations this system could perform. This kind of system would be used by power users, who need damn close to maximum performance with the minimum of resources.
It's that specific combination that this whole convoluted mess of spaghetti-logic is aimed at. How to get the absolute most out of the absolute least. Generic binaries won't do that, and for some people, the "absolute least" will preclude compiling monsters such as GCC or XFree86 for themselves.
(The docs for X say that it requires something like 50 megabytes to hold the source, and another 50 to compile in. This is over and above the space requirements for GCC (and related tools). True, most people have 100 MBytes of free disk space handy. What if it's for an embedded card, with 16 MBytes of flash RAM, doubling as "hard drive", though? You can't even put the sources for GCC or X in that kind of space. For that matter, you couldn't even compile the Linux kernel itself in that kind of space!
Optimal solutions for these cases requires some form of cross-compiling, by someone, whether that someone is the admin, or an online compiler farm.
What about other cases? Low-end servers, for companies that can't afford Unix admins with the skills needed to precision-tune a machine? Schools, where very specific requirements need to be met, quickly, with nobody knowledgable enough to meet them? Hardware geeks, who want to test the limits of their machine, but who don't know enough about the software to find those uttermost limits?
These people don't really have a distribution that works for them, because what they need is too fluid. You can't pin it down, excactly, and even if you were to produce a "good guess" for one case, the next case would be too different for generic solutions to work well. What's worse, these are often cases where the user often doesn't have all the skills needed to do the work themselves. Sometimes they do, more often they'll have -some- of the skills, and in many cases, they'll have no skills in this area at all.
The challange, IMHO, is to find out how to optimize for everyone, asking only as little as absolutely possible.
Re:Similar to an idea I've been mulling over (Score:2)
Since compiling is one of the slowest parts of the process, I tend to lean towards providing some mechanism for doing that remotely.
Further, if you've got a custom image made, for a given hardware setup, then there's absolutely no point in doing any of the initial stuff again. The data has been collected, the binarys built (regardless of where), so you should be able to just drop the CD in the tray and watch a complete custom install fall onto all the computers you want, without ever having to type in a single command, or click a single button.
Since we do seem to have similar ideas, but yet have enough difference in perspective to see where ideas could be improved, would you be interested in turning these ideas into a reality?
Good Distro, for limited people. (Score:2, Interesting)
Who is this for?
NOT EVERYONE!
There has been so many threads about people saying this is not good for them. Well, you know what, then it isn't. This distro is for the people that want to have everything up to date. It won't be the Best distro in the world since the combination of all the different apps you are installing has not been testing, but it leaves you with something that is setup the way YOU want it setup, not the way some developer over at (insert distro name here) decided to do it.
Look for the good in the distro, don't just go hounding it.
Sorcerer: FGWTMTOTH (Score:3, Informative)
(not that this is a bad thing)
Paraphrase of the FAQ:
"This distro is new and different. It will take a lot of tinkering to get it running. Be prepared to blow a rainy weekend before you even see a decent window manager. You'll have to learn to cast spells. But when you finally succeed, rest assured that you'll have the very latest software, all compiled on your machine. Cool, huh?"
Seriously -- reading through the FAQ, I got the impression that it was BRAGGING about the complex, time-intensive, processor-intensive, memory intensive nature of the installation and maintenance procedures.
Diff'rent Strokes for Diff'rent Folks, I guess.
My complaint. (Score:4, Insightful)
Sure, it's gonna' take a while to compile X, KDE and the like. But this is the other half of the operating system, many people will be using this exclusively, right? Wouldn't you want that to be optimized? It's the GUI, in my experience, the most demanding part of the system.
But, I'm just a user. The whole thing sounds damn cool. I don't mind taking a day to compile *all* the software, just don't make me sit there in front of the machine the whole time hitting 'Y' and enter.
The thing that intimidates me [still, yes] is the fact that I have to configure the kernel. I have never really got this to work for me. I think [complaint coming] there should be an choice for "Auto-configure" or "Configure Now".
I'll understand if this isn't possible, but that seems to be the only thing in my way. I'm still going to download this and try it. The kernel config gets me though. I always seem to leave something out.
Question: Are we using the same config utility that comes with the kernel tarballs? And does the configuration menus come up blank or does it 'best-guess' and let you add and remove the things you need?
Re:My complaint. (Score:2, Insightful)
Re:My complaint. (Score:2)
Don't get me wrong, I've configured and compiled the kernel before. I even get it to boot... all the way. It just seems that I screw up when it comes to network cards or the like.
I am going to poke around with this distro. Seems perfect for my older K6-2 that mainly sits there waiting for me to log in.
Updating. (Score:3, Interesting)
I've tried Debian, but I don't know if it was the weird hardware (Using the m68k build) or just my newbieness (more likely) that made me dislike it so much.
This Sorceror distro, on the other hand, sounds like all the ease of maintenance of the FreeBSD "make buildworld" setup with the greater driver base of Linux. Win / win. I might just have to check this out.
--saint
There more then $CFLAGS= (Score:4, Insightful)
No. I don't know what all the fuzz about those optimizations is, but the real advantage imho is the configuratibility.
You want your ftpd, mta to have kerberos support, ldap ? You want KDE to user alsa only instead of OSS ? You do not use Netscape Plugins and there do not need this motif dependency ?
Here is your way to go:
You want to provide a binary for every "architekture" with every possible combination (dependency) ?
No. usually you are eating what your distribution serves you and don't care about having your postfix make you also require to install slapd, too. Even if you don't use it at all. Fair trade of convenience vs. bloat.
I do not know how those "source based" Linux Distros (rocklinux, lrs-linux, gentoo, sorcerer) handle this, but for FreeBSD you have either your make.conf or your configure-args in your port makefile. Or even a curses based selection menu. Latter one rocks.
Sure, for a "base system" one usually does need to many selectins (maybe include acl support, glibc support for 2.2 kernels or use pam or not), but for "applications" I consider this essential.
Anyway, I will sooner or later give either of those four known-to-me source-based distros a chance and see how tey stad up to mighty-ole slack
Its about choice, not binaries.
Anyone actually DONE it? (Score:2)
Let's stop reviewing the review and the concept, and actually review the distro for god's sake.
--SC
Re:Anyone actually DONE it? (Score:2)
--SC
PS. I'm working on installing it now. I've never compiled a kernel, though, so that part might throw me for a bit. We'll see. :-)
Re: (Score:2)
New Trend... (Score:5, Informative)
RockLinux [rocklinux.org]
Gentoo Linux [gentoo.org]
and Sorcerer Linux...
From my experiences and what I've heard Gentoo is the by far stablest and easiest to install of them and recently got a really good review [newsforge.com] at Newsforge [newsforge.org].
I don't really know if that is good concept, because the time/use of self-compiling every bit of software is quite low IMO. What is needed is a new Distro, that builds the Kernel itself and installs all the other application through RPM. That would maximize Speed and usability. My friend and I are working on something like this right now
Cool name suggests sinister connection (Score:2)
Secondly, it is important that we tip off "investigators" from the counter-cult movement about this new, occult Linux distribution (former Linux programmer, now saved, reveals Satan's plan for open source software!). Nothing drums up good PR like being an instrument of the great beast. Religious Tolerance keeps a list of these fruitcakes. [religioustolerance.org] These people have suffered fundamental damage to the credulity centers of their brains and will believe anything packaged as evidence of Satan's machinations.
Bullsh.. (cough) (Score:4, Insightful)
The whole idea of a kernel is that it provides an abstraction layer to the hardware: the optimization based on all these "thousands of hardware configurations" takes place in the kernel.
Let's take a look at the most important pieces of hardware that are in the computer:
The conclusion is that it is really nonsense to compile _everything_ from source. Have the users compile their kernel based on their hardware. Make sure they have the correct xfree driver for their video card and a correct xfree config file. That's all the "hardware optimization" you're ever going to need.
So why do people nowadays compile programs, then? That has nothing to do with hardware, but with the myriad of libraries Out There. Binaries will of course change if you compile them on libc5 or glibc2.1. But if you stick with one distribution, that is never a problem. The problem is there if you want programs that don't come with your distro. Again, there's really no reason to compile the programs that do come with the distro.
But that's just my opinion. Of course these people should be praised, because they had a Good Idea [tm] and did something with it.
Re:Bullsh.. (cough) (Score:2, Insightful)
There is for example memory allignment for the variables, which differs depending hardware. There are the different execution costs of certain asm comands, so the compiler can chose the best for every arch.
All these things have nothing to do with Kernel or Librarys, and no (Binary) Distro can do this optimizatons for you, since these binarys won't run on every arch. (e.g. i686 binaries won't run on i586)
And belive it or not, this realy makes a difference. Especially huge Programs, like X or KDE gain noticiably from this Optimisations.
The other advantage of Compiling yourself is control, you can control any aspect of the build process. Take Mozilla as an example, you can choose whether you want Mail/News client, SVG, MathML, you can prefer certain librarys over others (each of which has its own pros and cons) you can even choose which kind of garbage collection you want it to heav, if any.
And another upside is that you can also do any step manually, which teaches you many things, and gives you even more freedom.
I never leard more about the inner workings of Linux, as when I first installed it manually from sources for the first time. (see http://www.linuxfromscratch.org, IIRC the devel Team from Sourcerer used this as a Starting point)
Re:Bullsh.. (cough) (Score:2)
You're confusing abstraction with optimization. Abstraction makes sure that you do not have to recompile all your applications, and, in fact, not even the kernel.
Optimization includes making use of the latest features and optimizing for a certain architecture (e.g. Pentium vs. AMD). This usually doesn't make sense if you're shipping precompiled binaries, and abstraction makes sure it's not required. But that doesn't mean optimization shouldn't happen.
Free Software is about having the software configuration you want. Why not extend that to having it tuned for your hardware?
You don't think a Pentium 4 optimized or Athlon optimized executable is much more performant than a generic 486 executable? Besides, even if it's just a 10% increase in speed, why not? You get it for free (well, maybe the installation takes longer due to the compile time, but that's a one-time effort).
Mispelt name? (Score:4, Funny)
Will it download the patched sources as diffs? (Score:5, Insightful)
It would heavily reduce bandwith, were it possible to grab just the diffs (and maybe an MD5 sum of the package complete with diffs), and not everyone has a T1 out there. With binaries that wouldn't make much sense (until one applied a very specialized diff), but with source-updates it would work well.
.
Not to be a distro zealot, but... (Score:2, Informative)
Then you can
The required development packages can be installed with apt-get build-dep packagename by the way, so you don't have to worry about that either.
eeeep.. that sounds like a LONG install.. (Score:2)
Uh KDE can take a day to compile and with gnome there are hundreds of apps. That could take a week.
Great its optimized, how long does the install take, and how fast of a machine do they recommend having?
A kernel compile is not a problem on my athelon as that takes 4 minutes from make dep to make bzImage / make install, but on my old P133 it takes about an hour.
I wonder if they have the newbie in mind here. Does your grandma really want to be compiling her own kernel? I think not. Most people don't want to know that much about their computer, I guess that is why so many people use windows is cause it allows people to stay ignorant about their computer (until something goes wrong).
It does however sound like something worth trying. I am wondering if this would work on my old P133 and how long it would take to do a full install.
Redmond Linux (Score:2)
http://www.redmondlinux.org/
Hmmmmm. I'm not sure what to think.
Mirror online at: (Score:2, Informative)
wget http://distro.ibiblio.org/pub/Linux/distributions
Happy downloading!
finally.. (Score:2)
sorcery metaphors (Score:3, Insightful)
To the Nay-Sayers (Score:2)
I once had a slashdot sig to the effect of "Slashdot is not news for geeks, its a battleground for wannabe managers." Again I'm seeing the tendancy for people to offer their opinions as if they were managing a project.
What these people are doing is pretty cool. Its something that I've been hoping would come out for a while (actually it has, at rocklinux.org and has been mentioned on slashdot as much as two years ago.) Back in the days of StampedeLinux I found out first hand the benefits of a hand-optomized compilation. It easily ran at 20% faster speeds than anything else for desktop use.
Now that the optomizations of yesteryear found in egcs and pgcc are done pretty well in in gcc 3.0, I wonder why I still run packages for an i386 on my Athlon. Rock linux is by far the most real-man linux out there, and is the most stable and unbreakable. If Sorcerer is only a bit more managable I'll have to try it out too.
Can't wait for the newbies to try this one (Score:3, Funny)
Hmmm...
[newbie@home newbie]$ startx
"Damn, X sure does load slowly on this box!"
(Seriously, it does sound like a cool idea, even if I'm not convinced it's practical, but I may try it.)
Re:I just started downloading... (Score:5, Funny)
They're going to wish they had a +25 magic staff of bandwidth in the next little while.
Re:I just started downloading... (Score:1)
Re:There is no free lunch (Score:3, Informative)
With a single command that has command-line overrides, and a config file that is easily editable, a single command optimized-compile is entirely possible.
Re:Oh Dear (Score:2)
And you prefer Debian? Debian (whole) takes MULTIPLE CD's. Sorceror is LESS than a single CD.
> It'll be obsolete tommorow
Again, you prefer Debian, which is obsolete TODAY. Its a SOURCE BASED INSTALL, so, you can update every DAY if you want, from the very latest on the net. You can even set it to automagically do so from a cronjob!
I'm not saying Sorceror is better than Debian, but your arguments dont hold much water by themselves, and DEFINITELY not with Debian in the context.
Re:Damnit! (Score:2)
Re:It IS out ... read the post next time troll (Score:2)
Perhaps if you clicked through, you might have seen that, troll-boy.
Re:Is this backed by Intel, or by Time Warner Cabl (Score:2)
Re:Lose the GNU and I might Try It (Score:2)
Re:You buttwipes have slashdotted the site #@!!!*& (Score:2)
Err..what do you mean "mistake"? Does running sorcery trash the system or does it just tie it up until the magic happens?
I guess that could be a problem with it that needs attention. It is a small, new distro lacking in mirrors. Running the sorcery tool tries to get the magic from a single site(?), but everyone else and their mother is also running sorcery.
They need a bunch of mirrors through which sorcery could traverse until it gets a connection and succeeds.