1) I'm curious how many would like use Debian testing for development.
2) If someone has experience major problem regarding service that don't go after some minor upgrade.
3) How long is the support for testing (for stable i think is 1 years or i'm wrong?).
I have read something on the debian site but regarding testing is quite obscure.
4) After that section on this forum about Debian exist one big forum only for Debian?

Thanks.

forums.debian.net is that "one big forum."

Debian testing starts out as a copy of stable whenever the previous testing repos get accepted as the new stable version. Packages spend some time in unstable, usually 10 days unless a rush is pushed to get depending packages in so it becomes 5 days, and if there are no new release critical bugs, no dependency problems with existing testing packages, and during this time its installation in testing doesn't appear as if it will break existing packages, it is released into testing.

Testing, although having a security repo, at present is not supported by the security team. So testing will receive necessary security updates to packages only when they undergo the process described in the previous paragraph, ie the necessary time in unstable. Generally this means that stable gets a security update a bit faster but only by a few days. Stable will get its package patched whereas testing will get an entirely new package version.

For development of Debian, unstable is where one would hang out. But for general software development combined with a much better chance of system stability then testing would be fine. The software is quite up to date and sometimes even newer than what a stable version of another distro that waits 6 months to release a new version with updated software would give you.

One would generally install stable with just the standard task, use editor (nano) to change the lenny lines to squeeze and add the sid lines, add contrib, non-free, and debian-multimedia.org, remove debian-volitile, make an /etc/apt/apt.conf setting the default release to testing, reinstall dpkg, apt. aptitude, and perl, do an aptitude full-upgrade, and then install ones favorite desktop environments. I use the tasks in the aptitude gui for that but many prefer to install their favorite software one by one (yucch!).

http://forums.debian.net/viewtopic.php?f=16&t=15612

That how-to in the debian forum is a good read. Saves you from bothering to setup apt pinning in a preference file and gives some pointers.

Try to stay away from the testing or unstable installers until they reach release candidate status. Use the stable (lenny) installer because it works.

2 members found this post helpful.

That's a really good answer dahveed3.
Far better than i could manage.

Thanks for the answer and for the link.

Perhaps i will try stable because i would like minimize eventually headache due to major changes version.

For the moment i have installed the stable release on virtualbox.

There are few software that i like have update (gimp and ufraw) but they are only for personal pleasure while for developer i use java and database (postgresql, sometimes mysql) without use specific function on that databases.
Sometimes i use even openoffice, i see the version available on the stable is old but on the producer i see there is a debian package, i don't known if it function, perhaps yes. Boh.

Perhas i give a try even in the debian forum although I have some uncertainty.

If you run stable and need newer versions of some apps like OpenOffice you can use backports.org's repo. A lot of the time the packages in backports are actually newer than what is in the testing repo.

Sometimes even Testing has something that's too old for your needs (in my case, the single app that created a problem was Iceweasel -- I needed 3.5.5 so I could share data between distros, and Testing was stuck on 3.0). When this happens, you can grab the app from Unstable using pinning:

http://jaqque.sbih.org/kplug/apt-pinning.html
http://wiki.debian.org/AptPinning
http://www.debian.org/doc/manuals/ap...pt-get.en.html

Yes i like have even firefox update but for me this isn't a real problem because is sufficient go on the mozilla and download the binary.
So you have everything (that you put generally in your home) and the system remain untouched. Very simple.

It's cleaner to get it as a Debian package and update it through apt.

Yes, it's especially handy to keep this stuff together since I rsync it to a couple of different places for backup. I can also add and delete distros pretty easily without accidentally losing stuff I value.

But the package on the stable release are more older or is the browser firefox an exception?
Also from some times is possible update the browser download from the producer directly without download and reinstall over and over on each major change version.

I use the same system even for install java, i put everything on my partition data (i don't like make two partition one for data and one for common program) so i avoid to reinstall the same thing over and over again.

However on the meantime i have noticed that the openoffice on the backports is however more older then the package present on the producer.
Also the package on the producer is installed on /opt so, even in this case, when i should install an office suite, i think i install openoffice in this manner so, even in this case, my system remain untouched.

By following the how-to I linked to it will not be necessary to have an /etc/apt/preferences file or do any apt pinning. You'll have defined the default distribution (testing) so aptitude full-upgrades will not install any sid packages except for updates of packages you have installed from there using the -t unstable switch.

Mixing packages from testing or unstable into an installed stable distribution is a big no-no. Simple dependencies often call in major system file upgrades that wreak havoc on the system and all sorts of not fun things happen. Advanced users, for small package needs but not major suites like openoffice.org, sometimes will do the same thing that backports.org does and rebuild unstable packages against the stable distribution so that it all blends well. So then, if you are using the stable distribution it is really not a good idea to include the testing and unstable sources in your /etc/apt/sources.list at all.

In general, if the packages in stable, debian-multimedia.org, and backports.org do not satisfy then you should really be a user of debian testing. Testing is where a majority of desktop users are. My case in point is I use testing but want the nvidia driver in unstable. That works fine. But I wouldn't take it from there if I were using stable. In that case I would, assuming nvidia still supports the libraries in stable which they do, download and install the binary from nvidia.com. But I would even do that as a last resort and only if the nvidia driver in stable didn't work properly on my hardware.

Debian users use Iceweasel, which is a simple rename of Firefox due to mozilla.org taking issue with Debian fixing things in Firefox and mozilla not going along with letting Debian do so. There is a sticky thread in the debian forum regarding this. The newer version is making its way into testing shortly as all the holdups appear to have been solved and it is simply awaiting the 10 day holding period for xulrunner to pass.

A major benefit of using Debian is its package management ease and integrity and, well, fixed bugs within packages. Stable is boring by design. But testing, while fun watching it get newer stuff in, is still quite better in having stuff work and stably than most distro's finished release. I, for one, enjoy mostly trusting the release managers decisions regarding when a new upstream release is ready to get installed on my computer.

A small example of how I see things is what I do with Wine. It has the latest versions as wine-unstable packages in sid, and packages are built for us by gracious maintainers from a repo at winehq.org, but on testing since I want the latest version AND certainty about its build against my system will not use the version in sid nor the one offered by the wine repo. I download the source and compile it on my machine instead.

So to sum up. For packages in the Debian distro I use, I'll use those with very occasional exceptions such as nvidia from sid. If a package is not in Debian at all, well, it's rare (GoogleEarth), but that's probably the only sort of thing I digress from the Debian System with. I did the same when realplayer from debian-multimedia.org wouldn't start on the newer testing libraries. I went ahead and installed real.com's binary. (Bad boy!)

Regarding openoffice.org, you may enjoy learning that since the versions in stable and backports.org use the go-oo.org packages as a base you get the Microsoft format compatibility that is the major new feature of newer versions of openoffice.org. If that still doesn't satisfy I really recommend you using testing instead. The use of a very stable kde4 in testing is a benefit as well if you're a kde fan.

Well, a stable version you could call it, as long as you compare it to the famous BSOD's in the still not so far past with another OS.
But what about the total functionality the enduser expects when using it?
Version 4.3 indeed was a major leap towards that goal. But still there were quite some shortcomings and bugs. The KDE-guys worked and are still working hard to improve there and to eliminate these.
4 weeks ago they released 4.3.3 to fix bugs and add some more translations (well, the last one isn't very significant here).

And where is Debian-testing?

The (quantitative) majority of *their* release is 4.3.1.1. They are still floating on an almost 3 months old release. The (again quantitative) few packages of 4.3.2.1 were 2 months ago released and now already found fit to go into Debian-testing. NOT stable, only testing! Why?
Was/is KDE so bug-stricken, that they (Deb) need such a long time to sort that out before releasing it to their own community or are they so fixed on Gnome or are there - in their eyes - very important matters regarding GPL-licenses, that they have to spend an enormous lot of time to fix that?
And also to construct dependencies, that don't allow a truly follower of Debian to anymore quit the path, that they and only they think is the right one?

Stable doesn't get newer version, in this case stable has kde3.5 and will continue to have kde3.5 until Squeeze is released as the new stable. As for kde4 perhaps by the time it reaches something like kde4.10 it might be as usable as kde3.5.10 was. I was a big kde fan until kde4 came along, as far as I am concerned it is the vista of the linux world. Lxde is much lighter and once I replaced all of my kde apps with the exceptions on k3b, smplayer and k9copy I was quite happy. Newer isn't always better as kde4 proves.

Same goes for Iceweasel but then it started to lag behind the Mozilla version by a lot so I said the hell with it and switched to using Firefox, which by the way uses less cpu/ram than iceweasel even using flash or java.

Debian testing is just that testing, the packages there have lots of bugs, and at times even get removed from testing.

Hang out in the #debian irc channel for a while more people come in there having weird issues with testing that almost any other issues, other than weird apache issues.

As for myself I will stick with sid as I have done for the past 5 yrs, since I have had very few issues. The combination of apt-listbugs and using smxi has kept me from having any major issues. Now if I could just figure out why I can't get a debian kernel to boot while the liquorix kernel works perfectly.


$ inxi -F
System: Host craigevil Kernel 2.6.31-6.dmz.2-liquorix-686 i686 (32 bit) Distro Debian GNU/Linux squeeze/sid
CPU: Single core Intel Pentium 4 (UP) cache 1024 KB flags (sse3 nx lm) bmips 5592.14
Clock Speeds: (1) 2792.941 MHz (2) 2792.941 MHz
Graphics: Card Intel 82915G/GV/910GL Integrated Graphics Controller X.Org 1.6.5 Res: 1280x1024@60.0hz
GLX Renderer Mesa DRI Intel 915G GEM 20090712 2009Q2 RC3 x86/MMX/SSE2 GLX Version 1.4 Mesa 7.6 Direct Rendering Yes
Audio: Card Intel 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller driver HDA Intel
Sound: Advanced Linux Sound Architecture Version 1.0.20
Network: Card Intel 82562ET/EZ/GT/GZ - PRO/100 VE (LOM) Ethernet Controller driver e100 at port dcc0
Disks: HDD Total Size: 160.0GB (15.8% used) 1: /dev/sda WDC WD1600JS-75N 160.0GB
Partition: ID:/ size: 103G used: 24G (25%) fs: ext3
Info: Processes 99 Uptime 2 days Memory 216.5/493.7MB Client Shell inxi 1.2.7

Yes, of course all software has bugs and kde, just like in the kde3 days, is continuously fixing them and gathering nice new features with new bugs. I recall that kde 3.5.7 was beset with some weird ones too and that it was only in the final days when 3.5.9 and 3.5.10 came out that the most important user complaints were patched up. It didn't stop people from using and upgrading as each new kde version was released just because it all wasn't absolutely perfect. Folks happily used KDE3 for years along with all the bugs.

With respect I did have a tee-hee moment when all the testing complaints were mentioned and so it was decided to instead use unstable?!?!! Hah!

I just was pontificating so the OP would be aware of the design of Debian and how it is used as far as choosing a distribution and generally sticking to the packages it comes with, or at least using system responsible methods (debian developers semi-official backports.org and debian-multimedia.org stuff) if newer or not in Debian packages are desired. Especially not to just plop testing or unstable packages into a system with stable on it.

I further pointed out that many of the most desired features of openoffice.org new versions are already in the version in stable, and, if using testing, it wont be long now before the latest iceweasel is let in. I'd say less than a week, but don't quote since it isn't a guarantee until it happens. Just looks that way when checking out a "qualified" iceweasel and its dependency xulrunner having "new" bugs but those actually having been fixed in the current unstable version now counting down the days until it is "qualified" for testing release.

Those were the two packages the OP seemed most interested in. It seems like he'd be satisfied with using testing, but there certainly is nothing at all wrong with sticking to the officially released Debian stable. I'd just like him to tread carefully when choosing what packages that aren't built on stable libs he chooses to plop into his system. I'd be more inclined to think that would mess things up more so than full-upgrading a testing distro daily (what I do) with official Debian maintainers choosing the software.