LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   MEPIS (http://www.linuxquestions.org/questions/mepis-64/)
-   -   why does antiX use Debian testing? (http://www.linuxquestions.org/questions/mepis-64/why-does-antix-use-debian-testing-907665/)

newbiesforever 10-11-2011 06:52 PM

why does antiX use Debian testing?
 
Hey, Anticapitalista...since you created antiX, could you explain one of its design features? Why is it based on Debian testing rather than stable? Is there a factor in its design or purpose that requires bleeding-edge [correct word?] software, or did you simply like it that way? It's the first distro I've used that was made from Debian testing...

snowpine 10-11-2011 07:55 PM

I certainly can't speak for AntiC :) but let's look at the facts:

http://distrowatch.com/table.php?distribution=debian
http://distrowatch.com/table.php?distribution=ubuntu
http://distrowatch.com/table.php?distribution=fedora

If you compare Debian with the other major distros such as Ubuntu, Fedora, etc. you'll see that Debian Testing is not "bleeding edge" at all.

Debian Stable is fantastic for servers and enterprise, but most home/educational/hobby users will find that Debian Stable is a bit outdated compared with other distros. Debian Testing hits the "sweet spot" for a lot of users. :)

rokytnji 10-11-2011 09:04 PM

Being a user. It is easy enough to Change AntiX over to Debian Stable (Squeeze) if one so wishes.

http://antix.freeforums.org/antix-de...eze-t2949.html

I figure that AntiX is based on testing so apt-get upgrade && apt-get dist-upgrade keeps you from reinstalling AntiX every time Debian changes Stable release.

Quote:

As antiX is a 'rolling release' distro it is advisable to run regular dist-upgrades.
Code:

inxharry@Biker:~$ inxi -F
System:    Host: Biker Kernel: 2.6.38-7.dmz.1-liquorix-686 i686 (32 bit)
          Desktop LXDE (Openbox 3.4.11.2) Distro: antiX-core-686-a1 20 June 2010
Machine:  System: Intel (portable) product: Montara Family of Chipsets
          Mobo: Phoenix model: RT786EX version: 41118 Bios: Phoenix version: MGM-ALL1.86C.1009.D.0604271130 date: 04/27/06
CPU:      Single core Intel Pentium M (-UP-) cache: 2048 KB flags: (sse sse2) clocked at 598.154 MHz
Graphics:  Card: Intel 82852/855GM Integrated Graphics Device X.Org: 1.10.3 driver: intel Resolution: 1024x768@60.0hz
          GLX Renderer: Mesa DRI Intel 852GM/855GM x86/MMX/SSE2 GLX Version: 1.3 Mesa 7.10.3
Audio:    Card: Intel 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller driver: Intel ICH Sound: ALSA ver: 1.0.23
Network:  Card-1: Realtek RTL-8139/8139C/8139C+ driver: 8139too
          IF: eth1 state: down speed: 10 Mbps duplex: half mac: aa:00:04:00:0a:04
          Card-2: Atheros Atheros AR5001X+ Wireless Network Adapter driver: ath5k
          IF: wlan0 state: up mac: 00:0b:a2:1c:eb:8f
Drives:    HDD Total Size: 30.0GB (26.8% used) 1: /dev/sda IC25N030ATCS04 30.0GB
Partition: ID: / size: 17G used: 3.9G (24%) fs: ext3 ID: swap-1 size: 0.58GB used: 0.00GB (0%) fs: swap
Sensors:  System Temperatures: cpu: 35.0C mobo: N/A
          Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 91 Uptime: 37 min Memory: 166.6/492.4MB Client: Shell inxi: 1.7.23
harry@Biker:~$ cat /etc/issue
Debian GNU/Linux wheezy/sid \n \l

My AntiX 8.5 i686 core install started out as Debian Squeeze when it was in testing in 2010. Just apt-get update && apt-get dist-upgrade with Sid Liqourix kernel repos also enabled besides testing keeps this old military/cop laptop humming right along on 512MB of ram. Been running AntiX for ages. Command line tools like smxi,inxi,ceni and other command line apps is what keeps me using AntiX plus the bleeding edge libraries also.

craigevil 10-11-2011 10:38 PM

LMDE from the Mint guys is also based on Testing.

newbiesforever 10-11-2011 10:56 PM

Then what do you testing users do when you want to install software that comes from outside the testing repos (possibly just because it has no testing version yet) and has dependency conflicts with the testing versions? I've encountered that problem repeatedly. It seems to be generally a messy business...

craigevil 10-12-2011 05:07 PM

Quote:

Originally Posted by newbiesforever (Post 4496076)
Then what do you testing users do when you want to install software that comes from outside the testing repos (possibly just because it has no testing version yet) and has dependency conflicts with the testing versions? I've encountered that problem repeatedly. It seems to be generally a messy business...

Care to post an example?

Easiest thing would be to pull from sid.

Or backport the package from sid:
Quote:

How do I backport a sid package to testing or stable?

Install the Debian source (and the development tools, especially debhelper), and then build the package. Step by step:

add a deb-src line for sid to your sources.list
apt-get update
apt-get build-dep packagename
apt-get -b source packagename
the resulting debs should be in the current directory
Only things I have installed that aren't in Debian repos are Google Chrome, Opera and Skype, Minus and vulture-nethack.

newbiesforever 10-12-2011 05:37 PM

Sid? I thought "unstable" meant unstable (as in, it might break). The nickname Sid implies that too, as I understand that the character is a psycho who damages toys for amusement. If the stuff in sid is merely untested and might be perfectly usable, "untested" would be a less confusing name and would also indicate the difference between it and the testing repository.

As for your question, I'm trying to remember which of my distros I encountered my dependency messes on--MEPIS 11 or antiX. It had to have been MEPIS 11, because it doesn't use testing and was more likely to have had dependency issues with testing software. Maybe I'll reinstall it to duplicate what happened. But if I recall, it was an issue with Pidgin: the recent but older versions of Pidgin wouldn't work because of some kind of gstreamer bug (a "segmentation fault," whatever that is). I upgraded to the testing version, hoping it would get around the bug. It did, but installing the testing version of Pidgin was a pain in the ***, because it required installing the testing versions of a number of other things underlying the system, such as libc. I started drawing the conclusion that if I install any Debian testing software in a Squeeze installation, I may be forced to replace a large part of the system with testing to accomodate it.

snowpine 10-12-2011 06:31 PM

In Debian-land, "stable" means "no big updates," and "unstable" means "constant updates." That's all. (Testing is somewhere in the middle.)

We also use the word "stable" in everyday conversation to mean "reliable, won't break" but that's a complicated question when it comes to software. Imagine that you have the latest & greatest hardware: maybe it's a nightmare under Debian Stable, but runs swell using the newer drivers in Debian Unstable. In that scenario, Stable is actually Unstable for you, see what I mean?

Anyways the software in Debian Unstable isn't wild, scary, experimental. It's more or less current with the latest branches of Ubuntu, Fedora, Gentoo, Arch, etc.

Debian Testing is somewhere between the two. Just after a Stable release, a whole bunch of new stuff floods in from Unstable to Testing. Over the course of about 2 years, they gradually "freeze" Testing as the upcoming release starts to take shape. Then on release day, Stable becomes Old-Stable and Testing becomes Stable. Then the whole cycle goes "rolling" around again. So you see why a lot of users like Testing, because it isn't as wild as Sid but never gets completely stale like Stable.

newbiesforever 10-12-2011 07:00 PM

And what if you mix testing (or unstable) software with stable software, probably for the above reasons (e.g., the stable software has a bug or other problem. and the easiest solution you can find is to upgrade that particular software to testing)? Am I right that problems (often dependency problems) are almost bound to happen and upgrading the one program will often force a chain reaction of upgrades?

snowpine 10-12-2011 07:13 PM

Quote:

Originally Posted by newbiesforever (Post 4496940)
And what if you mix testing (or unstable) software with stable software...

I would never do that, personally. Rather, I would use Stable plus Backports. The packages in Backports have been specifically built against Stable to avoid any "dependency hell."

However there are plenty of users who have successfully mixed the different branches of Debian. The correct way to do it is called "apt pinning" and if you drop by the Debian forums you will find plenty of how-to's.

anticapitalista 10-13-2011 05:50 PM

Quote:

Originally Posted by newbiesforever (Post 4495937)
Hey, Anticapitalista...since you created antiX, could you explain one of its design features? Why is it based on Debian testing rather than stable? Is there a factor in its design or purpose that requires bleeding-edge [correct word?] software, or did you simply like it that way? It's the first distro I've used that was made from Debian testing...

Other posters have mentioned very good points, I'll just add that Debian Testing was chosen because it offers a (sort of) rolling release model that has (relatively) less breakages than Debian unstable/sid. The advantage of a rolling release is that all user needs to do after initial install is to do a regular apt-get dist-upgrade to keep the apps up to date(ish) and the chances of your system being totally borked is very slim (in Sid it is also very unlikely, but it has happened especially if users use the big desktop environments like kde/gnome).

Personally, I use antiX with unstable/sid repos on my desktop, antiX-M7.2 (released May 9, 2008) fully dist-upgraded on an old PIII using Testing repos and on an old Dell laptop, antiX-M8 (released Mar 11 2009) fully dist-upgraded using Stable repos.


All times are GMT -5. The time now is 05:44 AM.