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.

With a new never-before attempted port there are going to be issues that are unresolved or problematic. Best we put our cards on the table now before we ante up.

If you actually try what bartgymnast provides and find bugs, issues or problems, we will be grateful of your reports. Till then, couldn't you please leave us alone?

Quote:

Actually someone recently did audit the code of Slackware with it's current code and patch set and with only a few minor fixes, Slackware was able to rebuild against itself.

IIRC Slackware is not a source distribution and can't be rebuilt from scratch, at least not without a lot of work, but maybe I am wrong. Would you mind to tell us a little more about this recent successful attempt and what were these few minor fixes?

Thanks for the advise but I did follow this thread and had it in mind while posting, so there was no need for me to use the search function in that specific case

But tuxbg himself warns in the first post of this thread that he uses "minimal system installation". This is easily confirmed, as he rebuilt 291 packages, out of 1142 listed in PACKAGES.TXT in Slackware64-14.0. So yes, tuxbg's endeavor is interesting and helpful but no, it does not support your claim that "Slackware was able to rebuild against itself".

Thanks for the advise but I did follow this thread and had it in mind while posting, so there was no need for me to use the search function in that specific case

But tuxbg himself warns in the first post of this thread that he uses "minimal system installation". This is easily confirmed, as he rebuilt 291 packages, out of 1142 listed in PACKAGES.TXT in Slackware64-14.0. So yes, tuxbg's endeavor is interesting and helpful but no, it does not support your claim that "Slackware was able to rebuild against itself".

The minimal GNU developer and tool system along with the Linux kernel and module handing tools is all you technically have to build, and tuxbg did actually get it built, with some work mind you but he did get it built. The rest is just add-ons. If you follow the LFS handbook with exceptions according to the Slackware packages, build scripts, and patch works, you need a handful of packages to get a working system without adding in extra software.

His audit of the packages and available sources was actually invaluable in a research perspective that the system is self-buildable, though it will take work, but then again which OS doesn't take some elbow-grease?

It's a shame we don't have more audits done to the Slackware source to see if it is minimally buildable. It could be useful to a researcher to see if there are any incompatibilities and problems that could be lingering in a package, especially those from even SlackBuilds, and not just the main project itself.

For Bart, having a Slackware from source buildable unit, could prove key to his research to look for potential problems and incompatibilities. This link below was from the LFS attempt at getting it working. It's unmaintained, but it does have some insights that could prove useful. I've built it in a VM, but it had some issues with service daemons not shutting down properly as others have noted and an improperly dismounted disk image that resulted in a corruption and data loss in the VM, though luckily it was only a virtual disk.

Unlike other distros, Slackware is not built from scratch on every release. Live with it. The old mantra "if it ain't broken, don't fix it" is quite strongly adhered to. Also, tuxbg was not building Slackware "from scratch", but rather rebuilding on top of a pre-installed minimal Slackware.

If you want a real "from scratch" experience you may be able to adapt my Slackware ARM bootstrap for x86_64 or i486 (should not be hard to do: http://taper.alienbase.nl/gitweb/?p=bootstrap.git . Note that this port to ARM was started from absolute scratch and modifications to the official SlackBuilds went into that git repository when a package would not compile out of the box. I intend to use my X-mas holiday to polish up that port and bring the bootstrap, but also the remaining packages, on par with Slackware 14.1.

@ReaperX7: I know the link of the systemd of LFS,
it has been useful in some ways.

However beteen v204 and v208 is a period of 5 months.
I started with these slackbuilds with version v204 (after reading the LFS systemd attempt) and at that time I had some different issue, shutdown hanging, mounts not always working etc.

Since the v206 release these things seems to be solved, and since the v208 release I have not notice any issues so far.
every single release of systemd has solved a lot of issues.
This is also the reason that I started to post here to see if other people have any issues or not.
and if so, we can use it to improve the slackbuild or submit patches upstream, so that in future systemd releases we dont need to use patches and it would be easier to adapt to systemd for slackware if it comes that far.

Unlike other distros, Slackware is not built from scratch on every release. Live with it. The old mantra "if it ain't broken, don't fix it" is quite strongly adhered to. Also, tuxbg was not building Slackware "from scratch", but rather rebuilding on top of a pre-installed minimal Slackware.

If you want a real "from scratch" experience you may be able to adapt my Slackware ARM bootstrap for x86_64 or i486 (should not be hard to do: http://taper.alienbase.nl/gitweb/?p=bootstrap.git . Note that this port to ARM was started from absolute scratch and modifications to the official SlackBuilds went into that git repository when a package would not compile out of the box. I intend to use my X-mas holiday to polish up that port and bring the bootstrap, but also the remaining packages, on par with Slackware 14.1.

I have a very different idea when I read the word "audit" by the way.

Eric

Even better would be to look in the yocto project (based off of openembedded).

What I knew before this thread: systemd sucks
What I learnt on it: why

Quote:

Originally Posted by ReaperX7

With a new never-before attempted port there are going to be issues that are unresolved or problematic. Best we put our cards on the table now before we ante up.

Actually someone recently did audit the code of Slackware with it's current code and patch set and with only a few minor fixes, Slackware was able to rebuild against itself. Fedora has just about as many if not more patches than Slackware does.

Distribution: Slackware 14 is Main OpSys on Main PC, 2ndary are OpenSuSe 13 and SolydK

Posts: 841

Rep:

For the record, with the Thread Title formatting with all the dots.... everytime someone posts a new reply my screen shows in bold blue print "...Slack needs systemd" and it feels like someone defecated on the kitchen table and I have to suppress a choking, gag response. Sheeesh! Just sayin'.....