> [snip] > > > For a normal usage, testing is better, even if the project claims it > > is not for production environment. More recent kernels and drivers > > which means more supported hardware, and updated web browsers are > > some obvious interesting points here. They are simply the most > > obvious.
Merely a voice from out in the user land here, but felt I could chime in. Personally I want a system to work and do not need the latest version of everything or anything. The vendor shipped OS should "just work" and pulling in an update should never cause the system to become unbootable or unstable etc. As a philosophy this works well because it then allows me to build my own binaries into /usr/local if I choose. I think, and this is a WAG ( Wild As* Guess ), there is a defacto undocumented standard in the linux world which seems to say that stuff in /usr/local is just local to that given system and never touched by a package update. This is in violation of the much older SVR4 and XPG4/POSIX world ways that state you must place software into /opt/vendor/packagename with conf data in /etc/opt/vendor and var data in /var/opt/vendorname. The linux world seems to be a wild west where you can drop binaries into the /usr file tree. Sure, under /usr/local but still they are referenced BY DEFAULT in the PATH env var of users .bashrc and .profile etc. This is just insane as I see it but such is life. Expose users to uncontrolled changes? Bizarre. So I generally run RHEL 6 on anything important to me, like my personal workstations and some servers. I run Debian stable on some edge servers with custom builds of Apache, mod_ssl, libcurl and PHP etc etc. Lastly I do venture into the "testing" space on one laptop. Never further out than "Wheezy" ever and this is only because I expect things to work from one boot to another. Just a comment, setting up wireless networking with WPA2 auth seems to be a bit of a wild west still and it took a day of fussing to get it to work. Sad but true. Dennis -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fb89e20551e1.50fd4...@blastwave.org
