Hello. I have a lot of questions about repos and I don't know quite how to focus my thoughts. Here goes:

AntiX uses the testing repos. So

The Good: I have access to apps and newer apps that aren't available in the stable repos.
The Bad: I have bad luck with broken packages and bloat. (I'm still having trouble with ffmpeg and awhile back I had trouble copying dvd's - the audio and video were out of sync.)

Some questions:
1. Will antix always be based on the testing branch or will it continue to be based on lenny once it goes stable?
2. Will my system be more stable if I sidux my system?
3. If I sidux my system, then how? (I have tried to keep up with some of the topics on this issue but I have never quite understood it. This is one reason why I stopped using sidux - all this talk about h2's script, but I don't get it. I'm missing the big picture, the dots that make up the picture, etc. I'm not mad, just frustrated that I can't figure out what everyone's talking about.)
4. If antix always points to the testing repos, is there a way to point them to the stable?
5. Are there other issues you can think of that I haven't?

Thanks.

john

I'd edit the etc/apt/sources.list file and change testing to stable or whatever you need or want. (#4). It will probably be more stable using the Stable/Etch repositories, just like Mepis is, with the exception that you still have a base of Lenny/Testing to start with.

If you sidux your system you are going to Sid/Unstable repositories. I think what you mean is using the smxi script. That only semi-automates upgrades and installation of software. It does not use the Sid/Unstable repositories. It uses the repositories that are in etc/apt/sources.list which for the default antiX is I believe Lenny/Testing. (#3)

No. If you sidux your system it will be only as stable as Sid/Unstable is at that time. (#2)

Good question (#1)

I believe that h2 has set up his smxi scripts so that you can run, if you wish, with Stable, Testing, or Sid. Pure Debian systems will use only Debian kernels, for example. With antiX you can get a version with either Testing or Sid, but you could, in theory, go back to using Stable, and with a bit of effort, you could get it to work.

The combination of antiX with smxi and Sid may actually help you. Perhaps some packages in Sid have flaws, but at least from my usage - I have been using sidux now for over a year, AntiX for at least that long, and AntiX with smxi and sidux for a couple of months - I have not encountered any issues at all with adding smxi and sidux into the AntiX mix.

Thanks. Then what exactly is the smxi script? Could I get a link that will give me some info on it? Is it the same script that they talk about at the sidux forums - known as h2's script? Thanks.

john

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"antix.freeforu ms.org/siduxing-antix-t680.html"
linktext was:"antix.freeforu ms.org/siduxing-antix-t680.html"
====================================


for the smxi script. Yes it is the same script by h2 and they talk about and lots use at sidux.

masinick is right, though I guess you'd have to change Testing to read Lenny in apt/sources.list

(The smxi script will fix your ffmpeg issue. Or do this:
apt-get update
apt-get remove --purge libavutilcvs49
apt-get clean
apt-get update
apt-get install ffmpeg

Yes John it's the same script. Here the link on how to get it installed. Just a one-liner and your off.


========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"antix.freeforu ms.org/siduxing-antix-t680.html"
linktext was:"antix.freeforu ms.org/siduxing-antix-t680.html"
====================================

@ anti - thanks for the ffmpeg recipe. this one really hit the spot.

@ anti & erie - thanks for the link; I'm reading it now.

@ lucky9 & masinick - thanks for the replies. it's time to start digesting.

john

OU812 wrote:@ anti - thanks for the ffmpeg recipe. this one really hit the spot.

@ anti & erie - thanks for the link; I'm reading it now.

@ lucky9 & masinick - thanks for the replies. it's time to start digesting.

john

Good luck and good digestion, John, and thanks for all the help that you have been in testing and setting up some of the features for the upcoming release!

Thanks! I was trying to post on that other thread when firefox crashed on me. Here's basically my question(s):

I may only need the pure sidux repos for my video drivers (laptops - nvidia, desktop - ati). So will it be worth converting to pure sidux repos for this alone? It might be worth it if sidux is actually more stable than testing. In testing now, things may break, but usually we can usually find a fix. Recently, only ffmpeg has gone nuts. I really need stability when doing ripping and burning of any kind (and disc access, etc., of any kind). I can pretty much tolerate crashes in other areas. Thanks.

john

Well I use sidux and sid repos alone and I don't experience any problems. I would get everything up to date and then add the smxi script. then usuing the smxi script do a dist-upgrade again. If you wish you can then move to sid and dist-upgrade again.

You may want to watch the sidux forums for warnings about dist-upgrading as they watch pretty closely.

OU812 wrote:Thanks! I was trying to post on that other thread when firefox crashed on me. Here's basically my question(s):

I may only need the pure sidux repos for my video drivers (laptops - nvidia, desktop - ati). So will it be worth converting to pure sidux repos for this alone? It might be worth it if sidux is actually more stable than testing. In testing now, things may break, but usually we can usually find a fix. Recently, only ffmpeg has gone nuts. I really need stability when doing ripping and burning of any kind (and disc access, etc., of any kind). I can pretty much tolerate crashes in other areas. Thanks.

john

I would assert that sidux repos ARE superior to Debian Testing. What happens with Testing is that it is active for a while, but it gets pretty dormant near a new stable Debian release. Testing is not highly bug prone, but should you encounter an issue, chances are it will take significantly longer to resolve it in testing than in Sid (unstable). Sid has packaging stability issues, but sidux deals with that, and h2's smxi scripts do an awesome job of handling the issues and actually make it easy to support Sid. With sidux and the smxi tool there are few, if any, reasons, at least for desktop use, NOT to go with Sid - and sidux. The antiX value of adding a lightweight infrastructure makes sidux and smxi all that much more appealing, at least in my opinion, and I believe anti feels the same way based on the direction he is going with antiX.

In sidux, it was recommended to update your system no later than once a week. What is the current recommendation? Thanks.

john

OU812 wrote:In sidux, it was recommended to update your system no later than once a week. What is the current recommendation? Thanks.

john

Weekly updates are a recommendation and a guideline. I update my systems, at least the ones I regularly use nearly every time I use them. As long as you update at least once a month, or keep an eye out for security related issues, you should be fine.

Corporations, such as the one where I work, routinely update their systems on a monthly basis and they are stable. However, if they discover a security bulletin about any particular issue, they push updates out immediately as soon as they are verified and tested. To me, that would be the standard to follow.