SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
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.
Click Here to receive this Complete Guide absolutely free.
What should happen Pat would finally accept and start to release Slackware packages with (transparent) dependency meta informations widely used in unofficial repositories like Linuxpackages ?
F.E. upcoming VectorLinux ver. 5.0 (Slack's derivate) will now officialy support them incl. slapt-get package updating tool. It would make things much easier without affecting to continue to handle packages in the traditional way.
I can pretty solidly say that Pat will not include either slapt-get or swaret in the near or even far future. Simple is better, if you don't know the dependancies you shouldn't be installing the package.
Thats one thing I dislike about Slack even though it's one of my favorite distros, there are so many packages, so it's unrealistic that you are going to know all the dependencies of all the programs you may want to run. Swaret helps in a way but it's not perfect.
thats the only problem I have with slackware, the dep. thing. I am pretty sure I.m changing to Arch linux within the next two months... the whole compiling stuff just takes ages, esp. with missing libs and whatnot... it really annoys me after about four years on slackware... and what I read somewhere, computing in linux should be fun, and ./configure make make install is not my kind of fun...
It's not about decisions being made for you by your PC, it's about making sure that when you install Slack packages, dependencies are automatically resolved. It can be a bit aggravating when you install something but the package fails to work due to missing dependencies. I think dependency checking can be implemented in Slack without disrupting the distros simplicity.
Originally posted by dns21 Slackware is made simple. It seems to me that if I wanted a computer that made decisions for me, I would run windows. If slack doesn't make you happy, try debian.
there.s just no point in that argument. if you don.t want a computer that makes decisions for you, do Linux from Scratch. or even better, create your own kernel source... you see what I mean, gradations.
and btw when I install a distribution which supports dep.check, I can still turn it off, so the decisions are still up to me. The main problem is the time it takes to get new software running, it.s not that I.m lazy.
Originally posted by reddazz It's not about decisions being made for you by your PC, it's about making sure that when you install Slack packages, dependencies are automatically resolved. It can be a bit aggravating when you install something but the package fails to work due to missing dependencies. I think dependency checking can be implemented in Slack without disrupting the distros simplicity.
thats right. thats why I will try archlinux... and that distribution is definitely leaves you even more freedom than slack. there.s not even a netconfig or something...
I understand what you are saying and agree to a certain extent, which is exactly why I am about to try Mepis out on my my desktop/server. After experiencing the horror of swaret, I concluded that such a distro is going to be much better for my desktop/server because I want updates and installs to be quick, accurate, and easy. However, my laptop will run slackware (minus swaret) mainly because of iits simplicity. I think the focus on simplicity forces people to obtain a greater knowledge of how and what makes each program work. You get a better feel of exactly what is required when you are forced to keep it simple which backs up what sh1ft said. Also, I don't want to turn this into a which distro is better debate. I am just giving my input on how I think, among others, that Slackware should be. I support all distros mainly because they all fill a different need or niche. I may not choose to run Mandrake or SuSe, but I can understand their place. Perhaps Slackware just isn't your distro.
I would like to see some dependency warning system rather than an automated dependency resolving program or script. I'd prefer not to have an automated process control updates, but installation of new programs can sometime be a little fraught.
Example: I have an old laptop with a small hard drive, so I'd prefer not to do a full install if I can avoid it, but I've had to install GNOME even though I use Fluxbox/ROX as my desktop. This is because some of the programs I use- Abiword, Bluefish, GAIM - rely on a multitude of GNOME packages and it's easier to install the full GNOME than pick out individual packages.
It would be nice if the command line package commands could (optionally) flash up warnings saying "You have installed Abiword. I can't detect the following packages required by that program: foo1, foo2, foo3. " That way, you don't get the problem with conflicting or circular dependency requirements, just a heads up as to what you need to get things running. And for those who know exactly what they're doing, the warnings could be turned off so as not to irritate!
Incidentally, for those who will complain you should just install everything because disk space is cheap - sorry, I don't buy it. If Microsoft were to advance that argument as a reason for everyone to buy a new computer to accomodate Longhorn, we'd accuse them of sloppy coding and needless bloat. There are a LOT of older PCs out there that are still perfectly viable for most home users, but which don't have huge hard disks - a huge potential market for a Linux with tight memory control and lower CPU requirements.
That's ok, but what happens if you want to install an external package which requires libraries not include in the basic Slackware distribution? That's when you need at least some kind of tracking system. A system which would force the installation of packages it thinks are necessary wouldn't really fit in with Slackware, where much of the attraction is in the degree of control you have over the system, but a basic tracking and warning system would be a nice compromise between ease-of-use and the "geek-hair-shirt-I-compile-everything-by-hand-on-an-old-Casio-calculator" thing...
Originally posted by erraticassassin That's ok, but what happens if you want to install an external package which requires libraries not include in the basic Slackware distribution? That's when you need at least some kind of tracking system.
you're describing apt and the FreeBSD ports (both of which are awesome, btw) -- I can't see how Patrick could maintain something like that, and even if he could, why reinvent the wheel? Debian and FreeBSD already do a great job at it. but if you want to, try linuxpackages.net - I'm sure they'd like another volunteer, and maybe you could devise or improve a 3rd party-tracking system - it would take a ton of work, but I'm sure a lot of people would welcome it.