Slashdot Mirror
Review of Sorcerer GNU Linux
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."
A decent amount of software you can get for linux nowadays comes with a ton of compile options. When I get a binary package from debian or redhat I have no say over which of those options were turned on. Maybe I don't want postfix to be able to support ldap and mysql and postgresql lookups? Well, tough, I don't have any choice in the matter and so I have to download and install those libraries to satisfy postfix's dependencies.
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.
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!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
When updating packages rpm-style (especially something like KDE) it's really annoying that some of them are so large, while the change from the last version (that might still lie around on your platter somewhere) is probably less than a few percent of that.
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.
.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
You don't have to compile your 2Gigs every night. Nor do you have to compile it all at install time. I don't think Sorceror will let you install from premade binaries, but that's irrelevant if you aren't using binaries.
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?
A Government Is a Body of People, Usually Notably Ungoverned