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.

Just thought I'd see what the slackers think of this. Will anybody try it out?
It's based on Nix, does anybody have any experience with that?

It looks like it supports rollbacks, and the dependency management uses a hash of the dependency graph, so you'll always get the exact packages you need. If you're worried about control, it uses Guile Scheme so it's extendable and hackable. Looks like it will eventually grow into it's own full distribution.

Just thought I'd see what the slackers think of this. Will anybody try it out?

Asking a bunch of die-hard Slackers what they think of a distro-independent package manager handling rollbacks and dependencies seems to me like showing up at a meeting of Monogamists Anonymous and asking everybody if they can warm up to the idea of screwing all these women out there.

If I understand what I read correctly and the developers keep it going and they can get it adopted by all of the other distros out there, then this could be just what Linux needs to rid itself of the disparity between themselves. It would though mean there would be little to choose between them of course, so that's the other side of the double edge sword. But anything that can completely do away with dependency management whilst making it robust and reliable must surely be a good thing.
An interesting project to watch.

The current slackware approach only requires the user to understand shell-scripting to build packages: which any self-respecting linux/UNIX user will already know.
I've already been exposed to far more programming languages than I care to mention and I really don't want to have to learn any new ones just to package up software.
"Guile Scheme"? No thanks.

The current slackware approach only requires the user to understand shell-scripting to build packages: which any self-respecting linux/UNIX user will already know.
I've already been exposed to far more programming languages than I care to mention and I really don't want to have to learn any new ones just to package up software.
"Guile Scheme"? No thanks.

But you have time to spend downloading compiling installing testing finding missing dependencies etc etc. Or would you prefer to be using your PC more productively?

But you have time to spend downloading compiling installing testing finding missing dependencies etc etc. Or would you prefer to be using your PC more productively?

I see this argument often and always think: "What do those people that claim to want to work more productively with their machines so that a lot of their time would be lost with installing software?" Do you really everyday install new software on your productive system?
I see normally two possibilities when it comes to production systems:

1. Either you are a user (maybe also in the admin role) of a single production system. In that case you setup the software you need exactly once, not everyday. Since you know already which software you need and which dependencies that software needs it shouldn't be as time-consuming as many people think to setup a new machine and you get the benefits from a) knowing exactly how your machine works, b) knowing exactly which software runs on your machine, and c) having the possibility to install only the optional dependencies that you need/want. This should lead in general to systems that only have needed software installed, which in turn should lead to more stability.

2. You are an admin that often has to setup a larger number of machines. In this case you still have to track down dependencies only once and testing the software is a part of your job. If compiling is a problem for you you are doing something wrong, any admin that has to do a job more than only a few times will come up with a script to do that work for him. In case of Slackware it would be nothing more than writing a few Slackbuilds, if necessary, and a queue-file for sbopkg.

Dependency tracking may make sense in case of Debian, when you have a repository with 30.000+ packages, where a large number of packages is not part of the default install. it doesn't make sense in case of Slackware, where the number of packages in the repository almost equals the number of packages that are installed in a recommended default install.
Also, many people still forget that there is no such thing like automatic dependency resolution. A package maintainer has to track down the dependencies and integrate that info into the packages. The maintainer also has to decide which optional dependencies should be compiled into the packages, which may or may not fit your needs.

I prefer to be my own package maintainer and Slackware makes it very easy to do that. Slackware is the only distro without dependency resolution (except LFS) and I am still wondering why there is such a great effort from people that are even using it to convince other users that it needs to have dependency resolution. If you want dependency resolution go for Salix, simple as that.

You are an admin that often has to setup a larger number of machines. In this case you still have to track down dependencies only once and testing the software is a part of your job. If compiling is a problem for you you are doing something wrong, any admin that has to do a job more than only a few times will come up with a script to do that work for him. In case of Slackware it would be nothing more than writing a few Slackbuilds, if necessary, and a queue-file for sbopkg.

Fine for a server environment, but in a large mixed one, where different people have different requirements, different access rights and the need to use different programs, even a system admin needs to be able to get people up and running and keep them that way as quickly as possible. Go ask an admin team that has to regularly look after 1000's of PCs every day and see what they would prefer when a customer asks for program A. They can either grab it, complete with all required runtime libs, dependencies et al and install it on the recipients computer, or they can spend the next X hours scouring every corner of the Internet to get all the needed component parts, compiling etc etc ad nauseam.
Meaning a) the customer gets fed up waiting, b) the admin gets fed up listening to the customer complaining and c) the admin gets grief from their paymasters for being less than efficient due to the amount of time wasted to get program A running when they should be spending their time more efficiently supporting 1000's of customers and not just 1.

You know, if it were such a bad idea, then all the other distros that currently do something similar wouldn't be doing so. Neither would some other more commercial offerings out there.

But you have time to spend downloading compiling installing testing finding missing dependencies etc etc. Or would you prefer to be using your PC more productively?

It only takes a couple of minutes to download a build from slackbuilds.org, extract and run it (and that's assuming one doesn't use a helper like sbopkg) so I don't accept your argument that it is time consuming to do this stuff manually. I certainly don't spend that much time downloading and building stuff.

However my objection is not about the time involved. It's about having to remember the details,syntax and idiosyncrasies of yet another programming language. A long career in IT has resulted in my mind already being far too cluttered with this sort of stuff