You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Imagine that I'm an stupid and idiot Slackware(32) user, I use a Phenom II x6 as main system and secondary I have a little 8 x Phenom x4 (with all bells, ie 2GB RAM, 2x640GB RAID0, per system) cluster. I have the processing power to re-render the entire Avatar in a reasonable time, BUT!

I want to rebuild the entire Slackware Linux, at current/latest version, from a slighty different target: i586 or i686.

My question is: The Slackware Linux sources is published at latest version? I can rebuild the entire operating system from sources without other patches or upgrades/downgrades from the official packages versions?

Not quite. Slackware packages tend to get updated piece by piece. It's not unusual to find a few of the Slackbuilds won't compile under the current release and the binaries you are running were actually inherited from a previous release. Usually all it takes is the odd patch or version bump to fix though.

Also, there are the odd few packages, such as the kernel-headers that don't have a slackbuild script.

Not quite. Slackware packages tend to get updated piece by piece. It's not unusual to find a few of the Slackbuilds won't compile under the current release and the binaries you are running were actually inherited from a previous release. Usually all it takes is the odd patch or version bump to fix though.

Also, there are the odd few packages, such as the kernel-headers that don't have a slackbuild script.

To understand that the current Slackware Linux is NOT able to succeed the old good thing "it's able to rebuild itself"? We can't rebuild the current Slackware Linux from it's sources?

Everything you need to compile is found either within the source directory of the distribution or the patches/source directory. However, there is no indicator of the order in which the packages should be built and installed, as far as I know.

If you have that much horsepower, then I guess that you'll use distcc when you build stuff. You may want to look at https://launchpad.net/slackbot to get some ideas.

A library + headers get updated in current but the library is binary compatible with prior releases so existing packages that make use of it don't need to be rebuilt. But if that library/headers are not source compatible with the previous version then you end up in this situation.

It's also not unusual to see software that won't compile on a newer gcc without change though surely if the upstream projects write standards compliant code, that sort of thing shouldn't happen.

I say you consider using slackware64, because that will give way more performance benefit than going from i486 to i586 or i686, not to mention that slackware is actually mtune for i686, which makes the benefit even less.

Imagine that I'm an stupid and idiot Slackware(32) user, I use a Phenom II x6 as main system and secondary I have a little 8 x Phenom x4 (with all bells, ie 2GB RAM, 2x640GB RAID0, per system) cluster. I have the processing power to re-render the entire Avatar in a reasonable time, BUT! I want to rebuild the entire Slackware Linux

In photography, it's common to find that the people with the most expensive and sophisticated cameras are unable to take really good photographs. The most famous photographers will all tell you that the equipment is not as important as the talent and experience.

Similarly, in computing, sometimes the most powerful and expensive systems are correlated with a "stupid and idiot" owner. In fact, many of us use it as a heuristic.

The best advice for someone who is "stupid and idiot" is: do not attempt "to rebuild the entire Slackware Linux" until you are not "stupid and idiot". This advice is independent of the speed of the user's Turing machine.

Other people have answered "No" to your other question. The reason is, to avoid pointless work. The aim of Slackware is to provide a prebuilt set of binaries that reliably work together, not 'the old good thing "it's able to rebuild itself"'. (If that's what you want, see LFS, and follow the LFS mailing lists if you want to know how difficult it is.)

In photography, it's common to find that the people with the most expensive and sophisticated cameras are unable to take really good photographs. The most famous photographers will all tell you that the equipment is not as important as the talent and experience.

Similarly, in computing, sometimes the most powerful and expensive systems are correlated with a "stupid and idiot" owner. In fact, many of us use it as a heuristic.

The best advice for someone who is "stupid and idiot" is: do not attempt "to rebuild the entire Slackware Linux" until you are not "stupid and idiot". This advice is independent of the speed of the user's Turing machine.

Other people have answered "No" to your other question. The reason is, to avoid pointless work. The aim of Slackware is to provide a prebuilt set of binaries that reliably work together, not 'the old good thing "it's able to rebuild itself"'. (If that's what you want, see LFS, and follow the LFS mailing lists if you want to know how difficult it is.)

And additionally, the reason for dropping Gnome was...

Well, I think different... I said about Avatar. It's something like J.Cameron was shocked in a dream by a idea and few (hundred?) admins was able to transform his idea in a movie.

However, in our case... we talk about an (Linux) operating system. IF Slackware Linux is not able to rebuild itself, it's bad, very bad. Because that seem that Slackware is not really OpenSource and can be sued for Infringement of GPL.

It's something like Microsoft Corporation try to present the sources of Windows 97 SE as the sources of Windows Seven.

I think, in this case, if Slackware can't be rebuild from sources, can be considered at the same level of closed-source Microsoft Corporation solutions, using (barely) open-source software.

It's very important to preserve the "it's able to rebuild itself" in a open-source operating system. It's the guaranty of a true GPL operating system.

BTW. I'm Slackware user starting with version 2.0, the "stupid and idiot" was an expression.

It's very important to preserve the "it's able to rebuild itself" in a open-source operating system. It's the guaranty of a true GPL operating system.

That's crazy talk.

An open source system with the capability to rebuild itself is certainly nice, but it not any sort of requirement or measure of it being open source.

I do wonder though why in the original thread no answer was given about what tools or scripts the slackware team uses to build slackware. There may be no requirement to release that info or tools, but it would seem to be the right thing "in the spirit"....

However, in our case... we talk about an (Linux) operating system. IF Slackware Linux is not able to rebuild itself, it's bad, very bad. Because that seem that Slackware is not really OpenSource and can be sued for Infringement of GPL.

I think you misunderstand what is meant by open source in this regard. I means that the code is public, and developers are free to modify it how they wish. There are no guarantees about compilation. If there were guarantees about compilation, half of the programs I try wouldn't be close to being called open source.

In reading your posts on the thread that dugan linked to, it seems to me that what you want is the build order for the Slackware packages. I believe Eric aka AlienBOB has already answered that question, which is that they don't release it. That doesn't mean you won't be able to recompile Slackware from source. It just means that it will be extremely difficult.

Slackware same level of closed source Miscro$oft, using (barely) open-source software. How could u?? how could u??

Sorry, but that's the truth.

That method is named as "False Open-Source", i.e. imagine that the KDE-3.5.10 sources is presented as KDE-4.4.3 sources. Is common used today, and seems like that one of the "rats" it's called Slackware.