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.

No one was saying anything about removing mplayer. I guess this all stems from this changelog entry a while back:

Code:

Sat Sep 8 20:04:10 UTC 2012
xap/xine-lib-1.1.21-x86_64-1.txz: Upgraded.
This is a bugfix release, and had flown under the radar here due to previous
1.2.x releases. I've tested it and it at least works as well as the package
it replaces. With phonon-xine deprecated, I'm not sure how long Xine will
be included in Slackware, but this update doesn't seem to hurt so we'll take
it. Thanks to Willy Sudiarto Raharjo.

My point is simply that xine still has value to some of us (well, to me at any rate) outside of any requirements KDE (which I don't use) might have.
But it's no biggie. If Pat decides that KDE's deprecation of the xine backend is reason to drop xine-lib then I can continue to build it myself.

Last edited by GazL; 02-23-2013 at 08:40 AM.

Click here to see the post LQ members have rated as the most helpful post in this thread.

IMO xine still does a better job at playing dvds than mplayer does, so if he does get rid of xine then I'll be building it locally for that reason. I also prefer the xine backend over gstreamer for programs that allow the choice. 'gstreamer' has never worked well for me.

Most development regarding media players currently occurs in the VLC department anyway. Xine-ui saw three releases in the last six years and the last one (mid 2012) even did not make it to Slackware yet.

That's one of the things I most appreciate in Slackware: relying on the efforts of others. :-)

But this doesn't mean that all the work should be done by PV. If some software is readily available in trusted unofficial repositories or slackbuilds.org, I have no problem grabbing it from there.

This is particularly useful for applications difficult to build (VLC immediately comes to mind, thanks Eric) as I certainly prefer having our BDFL concentrate himself on stuff at the core of the distribution, like testing new glibc or udev versions, more generally ensuring proper integration of the Slackware Linux System, stability and security while staying in sync with (relevant) upstream evolutions.

and other useful cli tools I am overlooking that I spend time installing on just about every box.

Thank goodness we've got sysstat as part of core, unlike some other distros.

This would be good too, IMO, but I realize that part of the problem is related to space being at a premium, but it would still be nice to have it and add it to the welcome message from Pat in roots inbox:

That's one of the things I most appreciate in Slackware: relying on the efforts of others. :-)

But this doesn't mean that all the work should be done by PV. If some software is readily available in trusted unofficial repositories or slackbuilds.org, I have no problem grabbing it from there.

This is particularly useful for applications difficult to build (VLC immediately comes to mind, thanks Eric) as I certainly prefer having our BDFL concentrate himself on stuff at the core of the distribution, like testing new glibc or udev versions, more generally ensuring proper integration of the Slackware Linux System, stability and security while staying in sync with (relevant) upstream evolutions.

My

I have no problems grabbing it from SBo either. Following your argument, KDE should probably be removed from the distribution (an idea many people would agree with, BTW) yet there it is. I simply think lua is the kind of stuff that depends on basically nothing, is infrastructure by itself, has an unsual build procedure and would benefit from having an official package.

I have no problems grabbing it from SBo either. Following your argument, KDE should probably be removed from the distribution

If not KDE then what, Gnome? That doesn't seem like an option considering it was dropped already.

Quote:

(an idea many people would agree with, BTW) yet there it is.

Many people? I rarely see anyone say they don't want it. I have yet to find any of these desktop environments where everything works, printing has always been an issue for me, but I can work around it.

Quote:

I simply think lua is the kind of stuff that depends on basically nothing, is infrastructure by itself, has an unusual build procedure and would benefit from having an official package.

I think you will agree, it's impossible to keep everyone happy, so Patrick makes decisions based on his sources, I'm OK with that : )

Not that KDE is particularly bad, but IMO, it lately turned from software which solves problems to software which creates problems.
I turned to XFCE, but in reality, I would very much like to have Enlightenment out of the box.