41–50 of 132 posts
Earlier quoted context omitted.
So then run ArchLinux on your servers, and godspeed? Debian is not aimed at having the latest and greatest, but its packages do tend to be more up-to-date than RHEL/CentOS, which is its main competition in the "stable server distro that doesn't get you fired" category.
So our options are either bleeding edge versions or prehistoric ones?
Would this be a good time to migrate from Ubuntu?
If you're running Ubuntu Desktop and want to run modern game systems like Steam then I think you'd want to stay on Ubuntu.
Earlier quoted context omitted.
It's an interesting fact I suppose. It's interesting to see why certain distros chose certain kernel versions.
Debian has a long release cycle and uses the stablest versions available - and I believe that 3.2 is a "long term support" kernel, like 2.6 - getting large numbers of patches, and stability updates backported.
Earlier quoted context omitted.
/srv will continue to be ignored just as /opt and other one-offs are ignored. Reason being that they duplicate existing functionality, in this case under /var, /usr, or /usr/local. What /srv/ really stands for is NIH.
/opt is justified. /srv is indeed NIH (redundant with /var/ whatever ).
/srv is a bit questionable to me. Basically it's another /var. I always used directories like /var/local and /var/share (sambd and nfs shares). However, I am understanding the FHS crew wants to freeze the /var filesystem because it was getting too crazy with all kinds of stuff being placed under /var, and the likelihood of conflicts was getting high.
Earlier quoted context omitted.
Debian's 3.2 kernel includes backported support for much newer hardware from more recent kernels. Debian's primary kernel maintainer, Ben Hutchings, also serves as the upstream maintainer of the 3.2 stable kernel series.
And that I think is the biggest problem of Debian. They aim stability but how can you possibly claim that your custom backports are stable when e.g. the original developers have stopped supporting it? They may be able to pull it off with the kernel, but they can't possibly do it for all their packages. As an example: How are the Django backports to 1.2 more stable than upgrading to 1.3 when the official Django projec…
Earlier quoted context omitted.
Debian's 3.2 kernel includes backported support for much newer hardware from more recent kernels. Debian's primary kernel maintainer, Ben Hutchings, also serves as the upstream maintainer of the 3.2 stable kernel series.
And that I think is the biggest problem of Debian. They aim stability but how can you possibly claim that your custom backports are stable when e.g. the original developers have stopped supporting it? They may be able to pull it off with the kernel, but they can't possibly do it for all their packages. As an example: How are the Django backports to 1.2 more stable than upgrading to 1.3 when the official Django projec…
Which sucks, because application software needs to handle environments with Locale::Maketext 1.19 differently to environments with 1.23, else you get double-escaping bugs.
The response? Reporting the actual, correct module version (or god forbid, sync the comments/POD as well) instead of the incorrect, unchanged version number "would break stuff". As opposed to incorporating a breaking API change without bumping module version, which also breaks stuff... Ouch.
I guess I only have myself to blame, I should be more involved with debian maintenance of packages I care about.
Earlier quoted context omitted.
Shows how unbearably slow Debian's release cycle is. Wheezy ships with all the latest packages from 2 years ago.
So then run ArchLinux on your servers, and godspeed? Debian is not aimed at having the latest and greatest, but its packages do tend to be more up-to-date than RHEL/CentOS, which is its main competition in the "stable server distro that doesn't get you fired" category.
Earlier quoted context omitted.
I was under the impression that a newer kernel ment more hardware support. Am I wrong?
Of course. The tone of the top-level comment, I think, is "woah, Debian, you call this kernel updated?" Rock-solid distros like RHEL/CentOS and Debian are deliberately conservative. Some folks don't like that.
https://access.redhat.com/support/policy/updates/errata/
So I don't think RHEL/CentOS can be compared here to Debian.
Earlier quoted context omitted.
/opt is justified. /srv is indeed NIH (redundant with /var/ whatever ).
/opt is basically for 3rd parties to install software, because they can't be trusted to behave and integrate with the regular filesystem. The last thing you want is Oracle farking around with anything under /usr or /var, because they will fuck up your entire OS for their benefit alone. That is why /opt exists, in my understanding. /srv is a bit questionable to me. Basically it's another /var. I always used directorie…
But I think /srv actually makes more sense as /var is often on separate disks because /var/lib/ gets very IO heavy.
Earlier quoted context omitted.
I was under the impression that a newer kernel ment more hardware support. Am I wrong?
Of course. The tone of the top-level comment, I think, is "woah, Debian, you call this kernel updated?" Rock-solid distros like RHEL/CentOS and Debian are deliberately conservative. Some folks don't like that.