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.

I am considering one of two options for contributing to the "cause" in the form of (yet another) audio/video creation distro. Having used demudi and JackLabs versions of debian and opensuse respectively, I like the features, but don't like the lack of control I feel when working outside of a slackware install. I'm trying to gather opinions on whether I should just create some add-on packages for this purpose, or if I might venture into creating an entirely separate install for a slackware based audio/video distro. My question is:

Are there enough slackware geeks out there who also do recording/editing to make use of an entirely new/copied distro??

I'd like to think that I'm not the only one out there who would make use of such a thing, and I'm already running it at home (custom low latency kernel, tons of audio and video editors etc...) so mainly I'd just need to figure out how to package it all up. The idea is, that since I've used slackware from the beginning of my linux experience, I don't really like venturing out and learning new package management techniques, and I hate having to install a ton of "dependencies" that don't need to exist. Sorry for the rambling post, just give me some opinions!! Thanks,
MAD

May I ask, why yet another fork of Slackware? It will likely die a slow death like so many other specialist forks. If you would instead build a set of packages (using SlackBuilds) that install cleanly on top of real Slackware, you would gain a lot bigger audience. And start a Wiki with information on how to tune Slackware for realtime audio processing.

That's precisely the kind of response I'm looking for, and truthfully, the direction I'm leaning anyway. It makes more sense to me to do things that way, but was unsure of which would be a more acceptable way to proceed. Thanks Eric.

Yep, I agree with Eric.
I think you'll find that a lot more people are willing to help you, whether it be with testing, writing build scripts, or whatever, if you're doing this as an *addition* to Slackware rather than as a *replacement* to Slackware. I certainly won't speak for anyone else, but that's my take on the matter. :-)
Good luck with the project, and let us know how it progresses...

If you would instead build a set of packages (using SlackBuilds) that install cleanly on top of real Slackware, you would gain a lot bigger audience. And start a Wiki with information on how to tune Slackware for realtime audio processing.

I support what was already said. Some clean packages to be used on a real Slackware installation would be great. However, for stage appearances there's an alternative that might also be interesting: What about a specialist version of SLAX? With its module concept it could be a real good platform for your ideas to build upon.

I've definitely decided to go the packages route. After such a resounding (and much appreciated) response that that is the accepted way to go.

Ludist: yes, there is a benefit to recompiling the kernel for audio, if you're doing multi-track recording to cut down on latency (delays) with "what you hear" vs. "what you play"

"development" (if you can call it that) has begun, and I'm mostly testing on my own hardware at this point to see how it's working.
I have access to a pretty wide range of hardware to test on, but should be letting some release candidate stuff escape in the next few weeks. My biggest challenge at this point is learning to allow for a wider range of hardware, having focused on tuning the kernel and other apps for my hardware in particular. Once I feel reasonably confident that the kernel I use is portable (will work on a wide range of setups) I'll pkg it up and turn it loose for real world testing.

Thanks for the pointer, I've been using alsa up till' now, and have been looking at oss this morning, will report back on results when I have some
now... off to re-install on another box, I've kludged this one all up and want to start "fresh"
A.

I am very interested in such a project. I use Studio To Go for my audiowork right now, but I would really like to have my studio run on Slackware. Not that STG is bad, on the contrary, I bought it and fully enjoy and can recommend it, but as a Linux-based system I just happen to prefer Slack.
SlackBuilds is indeed the way to go, I think; perhaps SlackBuilds.org could have a separate section for these scripts? Audacity's already there, so....
Instead of building a kernel that runs everywhere, wouldn't it be an idea to post a configuration of the specific options and the patches that might be necessary?
You don't know what everyone's running, but you DO know which options are absolutely needed for realtime-audio, I guess. That'll save you a lot of work, and we'll probably end up compiling a kernel to our own specs anyway.
I'm willing to participate in such a project, but I've at this point 'only' ran SlackBuilds and edited them, not written them from scratch. I agree a Wiki would be very handy, because I've found that I had to scrape audio-info from all over the Internet, and good user-documentation on audio is pretty lacking. Especially for newcomers (but you could ask yourself how many new users start out with Slack, but then again, I switched to it pretty quick and totally love it, so....)

1. I would like the Wiki
2. I would like updated SlackBuild-s
3. I would like kernel-patches + custom-config (a traball?)
4. Ready to install packages would be user-friendly but not a must.
5. Port to SLAX (pkg2mo amd pkg2lzm) would rock (only if 4.==true)

I think it's a brilliant idea. I currently use musix and dyne:bolic for all my creative work. It would be awesome to do the same thing with slack. I always come back to slackware after brief periods of distro surfing and only recently I was considering building a audio tuned slack box to put in my studio.
I would love to get involved testing, package building, whatever...