Earlier quoted context omitted.
Right now in unstable/sid, you get the same Linux 3.2 and GNOME 3.4.
Artifact of the release process; experimental has 3.8.
3.8 versions of Linux and GNOME :)
Debian 7.0 "Wheezy" released
81–90 of 132 posts
Re: Debian 7.0 "Wheezy" released
#82Earlier quoted context omitted.
Who says the original developers stopped supporting it? Head on over to http://www.kernel.org and you'll see that 3.2 has longterm support (ie the kernel developers backport relevant fixes and patches). There are more details at https://www.kernel.org/releases.html including end of life dates. Given the time span between Debian releases, 3.2 is an excellent choice, if not the only one.
Right, this may be true for the kernel, but it can't be and it is not true for all of Debian's packages. Case in point Django: https://docs.djangoproject.com/en/1.5/internals/security/ Since the release of Django 1.4, version 1.2 stopped receiving security fixes by the Django development team. What that means is that a Debian maintainer (which probably is not a Django developer) would have to hack any new security fi…
"stable" does not necessarily mean "better"; In the case of Debian, it can mean "unchanging"... that is you can rely on it to not break your software even if you keep it ("stable") updated.
Re: Debian 7.0 "Wheezy" released
#83For those wanting to upgrade from Debian 6.0 squeeze
http://www.debian.org/releases/wheezy/amd64/release-notes/ch...
Re: Debian 7.0 "Wheezy" released
#84Earlier quoted context omitted.
Just make sure you're not on "testing" if you're doing this for a desktop (note that it is uncommon to run "testing" on a server). This release means that Sid ("unstable") just became "testing". Now, many folks are running Sid fine on their desktops, but historically the Sid -> testing push is volatile in the short term, and you probably would want to wait a couple weeks. Basically, be wary of "testing" after a relea…
Not quite. Sid is always unstable, and the new testing is jessie: http://www.debian.org/releases/testing/ Otherwise you're right - now it probably not the best time to switch to jessie/testing.
I would think Testing is pretty much safe, since all the new packages have to live a bit in Sid (10 days by default) before they reach Testing, so they get some testing. The only issue I know with Testing is temporary removals of some packages to help with these transitions.
Re: Debian 7.0 "Wheezy" released
#85Earlier quoted context omitted.
/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…
Because Oracle cannot install to /usr/local/oracle? I don't see the value of /opt.
You can effect pretty much the same thing by symlinking /opt to /usr/local/opt/ Which is how I manage my systems.
Similarly for /srv
Remember: the filesystem hierarchy and your underlying storage don't have to correspond.
There are other tricks which can be accomplished by union mounts or similar foolishness.
Re: Debian 7.0 "Wheezy" released
#86Earlier quoted context omitted.
Didn't you run into any breakage of packages? I mean there's this mad rush into testing right after a new release. I'm thinking of running wheezy for a couple of months until the storm calms down.
I've found the Debian package maintainers to be quite careful, even when there's a large amount of rapid change to testing. I think they put a lot of effort and thought into avoiding breakage, even in scenarios like this. Any time I've encountered broken packages, the problem has been resolved quite quickly, especially if more important and widely-used packages are involved.
I'm using a mix between unstable and Mint for a Steam box (games, music, movies, web) and found out the label must be mistaken. It's a minimal installation, but everything from ATI drivers to multi-arch support worked perfectly out of the box. It already went through several dist-upgrades without any manual intervention (except maybe a couple of "yes/no" questions).
Re: Debian 7.0 "Wheezy" released
#87Earlier quoted context omitted.
Right, this may be true for the kernel, but it can't be and it is not true for all of Debian's packages. Case in point Django: https://docs.djangoproject.com/en/1.5/internals/security/ Since the release of Django 1.4, version 1.2 stopped receiving security fixes by the Django development team. What that means is that a Debian maintainer (which probably is not a Django developer) would have to hack any new security fi…
For the record, debian also packages up pip and you can install an up-to-date django using that. You essentially get the best of both worlds here.
Well, it also packages tar and I can untar and install any package from source.
Re: Debian 7.0 "Wheezy" released
#88Earlier quoted context omitted.
Right, this may be true for the kernel, but it can't be and it is not true for all of Debian's packages. Case in point Django: https://docs.djangoproject.com/en/1.5/internals/security/ Since the release of Django 1.4, version 1.2 stopped receiving security fixes by the Django development team. What that means is that a Debian maintainer (which probably is not a Django developer) would have to hack any new security fi…
"stable" does not necessarily mean "better"; In the case of Debian, it can mean "unchanging"... that is you can rely on it to not break your software even if you keep it ("stable") updated.
True, but a security update means both better and more stable.
Re: Debian 7.0 "Wheezy" released
#89Earlier quoted context omitted.
Right, this may be true for the kernel, but it can't be and it is not true for all of Debian's packages. Case in point Django: https://docs.djangoproject.com/en/1.5/internals/security/ Since the release of Django 1.4, version 1.2 stopped receiving security fixes by the Django development team. What that means is that a Debian maintainer (which probably is not a Django developer) would have to hack any new security fi…
If the Debian maintainer has any idea what he’s doing, then this is likely to be more stable than upgrading to a new release that introduces new features and possibly incompatibilities. Fortunately, most Debian maintainers have a very good idea of what they’re doing.
Likely yes. But if I had to choose between the original developers and someone that has to maintain 20 different packages, I will chose the original developers.
Re: Debian 7.0 "Wheezy" released
#90Earlier quoted context omitted.
Shows how unbearably slow Debian's release cycle is. Wheezy ships with all the latest packages from 2 years ago.
Use Debian testing for the desktop. Desktop users don't use stable, or at least use it with backports. And what's so unbearable for the server? As others pointed out, RHEL ships even an earlier version of the kernel.
Testing is sometimes problematic from a security POV. Since it's considered a staging area rather than a "proper" distribution, it isn't security-managed, and occasionally vulnerabilities can persist for an extended period of time.
The most common case:
v1 of a package is in Debian stable. v2 comes out, is uploaded to unstable, migrates to testing. Later, v3 comes out, is uploaded to unstable, but its migration to testing is temporarily blocked because it's waiting on a major upgrade, like a new libc version, to make it into testing, which typically is done in a carefully coordinated way.
Now a security issue is found affecting all versions of the package. The upstream will (hopefully) release a patched v3, which will immediately go into unstable. The Debian security team will backport the patch to v1, and make it available to Debian stable users on security.debian.org. But testing is still distributing a vulnerable v2. There is typically no process to specifically patch v2 just for testing, because testing is staged via migrations from unstable; the usual situation is just to wait for blockage to clear and for v3 to migrate. There are occasional exceptions, mostly near releases: if it's determined that v3 won't be able to migrate before the next stable, a specially patched v2 may be uploaded to testing to get it into the next stable.
That scenario doesn't happen that often, but it's worth being aware that testing can lag behind both stable and unstable in security updates.