101–110 of 152 posts
dont wont to criticize any of the great & mainly voluntary work of the debian folks, but not quite sure how to interpret these statistics [1] looks like jessie is going to be the first debian stable to be released with rc-critical issues and not "when it's done" some of the bugs referred [2] seem quite critical indeed, maybe someone with more insight could comment on this? [1] http://richardhartmann.de/blog/posts/201…
Earlier quoted context omitted.
> Debian 8 has support until 2017 Wow, really? That's nothing! No security updates after that? > Ubuntu 1404 LTS has support until 2019 That sounds more reasonable. But still a bit short. > RHEL 7 has support until 2024 (and Centos). Interesting. Now I understand why I hear "centos" so often lately. So far, I only know Debian based distros. I wonder how much work it would be to switch to one of these two.
There was an article complaining on how RHEL support a flavor of python that is very old but it doesn't work with any other popular python libraries. (update: RHEL 5 and below is stuck with Python 2.4 apparently) Long term support is great and all but Red Hat can only support so much, the libraries and any other ecosystem that is part of that software or programming language will be dropped by group that are responsi…
Earlier quoted context omitted.
Best strategy is having a backup image and testing the upgrade procedure on a test machine beforehand, if possible. This release may be especially problematic because of the systemd change (it is possible to boot with sysvinit in Grub menu, but remote upgraders should beware). Did your last upgrade issues stem from the upgrade procedure or were they because of new versions?
Were your last problems stem from the upgrade procedure or were they because of new versions? I can't remember all of the different problems now, but one I do remember is that if you had a typical set-up with mirrored (RAID1) drives but the boot-related partitions cloned rather than mirrored, one of the bootloaders got upgraded but not the other. That is, the drives were left out of sync and booting from one of the d…
If you did something unorthodox, such as building a boot process dependent on a manual step to clone drive, you surely must be prepared to deal with this in any number of situations that can arise?
All non-standard solutions carry a debt where all future admins must understand what you built and how this affects operation.
Earlier quoted context omitted.
> All I care about is that stuff just works for as many years as possible, gets security updates and does not break I would go with FreeBSD or Debian.
Why not do both? https://www.debian.org/ports/kfreebsd-gnu/
[0]https://www.debian.org/releases/testing/amd64/release-notes/...
Earlier quoted context omitted.
Were your last problems stem from the upgrade procedure or were they because of new versions? I can't remember all of the different problems now, but one I do remember is that if you had a typical set-up with mirrored (RAID1) drives but the boot-related partitions cloned rather than mirrored, one of the bootloaders got upgraded but not the other. That is, the drives were left out of sync and booting from one of the d…
How could any update to the bootloader have been installed properly in that setup? If you did something unorthodox, such as building a boot process dependent on a manual step to clone drive, you surely must be prepared to deal with this in any number of situations that can arise? All non-standard solutions carry a debt where all future admins must understand what you built and how this affects operation.
The point remains that this doesn't matter. Before the upgrade, there was a fully working system. After the automated part of the upgrade, there wasn't. The original question was how safe the upgrade from 7 to 8 is, and this is a demonstration of the fact that such upgrades can carry risk. I'm not saying don't do them, I'm not expecting Debian maintainers to be omniscient, and I'm not telling you your child isn't beautiful. I'm just saying if you're thinking about moving from 7 to 8, be aware of the potential that there will be things the automated tools can't or won't do for you that may break your system, and plan your upgrade or other migration strategy accordingly.
Earlier quoted context omitted.
> All I care about is that stuff just works for as many years as possible, gets security updates and does not break I would go with FreeBSD or Debian.
Why not do both? https://www.debian.org/ports/kfreebsd-gnu/
As an AWS user, I switched from Amazon Linux to Ubuntu 14.04 because it's easy to replicate the development environment. No performance/stability issues so far however I'm curious if Debian 8 has an edge over Ubuntu 14.04 for a medium sized website on AWS. My only gripe with Ubuntu is that apt-get doesn't have the latest stables packages (like Amazon Linux does). I'm guessing it would be the same with Debian.
Since the freeze is around 6 months, this means you get 6 months old software when Debian is released. There are some exceptions, like browsers that are too difficult to maintain at the same version.
We believe most people like this definition. This can be frustrating when you need the latest version of nginx but you are happy that upgrading some basic stuff won't break anything on your system: no deprecated configuration option in X, no command-line flag that doesn't exist anymore in Y. All should work exactly as before, with fewer security holes and bugs at each upgrade.
However, if you really want to have the latest version of a selected set of software, have a look at the official Debian backports. This is a great strength of Debian over Ubuntu (where backports are almost inexistant with the notable exception of the kernels): there are many backported packages. For example, if you need a more recent version of nginx and you are running Debian Wheezy, you'll get nginx 1.2.1. If you need something more recent (because you want to get SPDY), you can get nginx 1.6.2 through backports. See here: https://tracker.debian.org/pkg/nginx.
Backports are packaged from the versions that will be in the next Debian release. So, they should keep the same quality than the packages which are currently in Debian. This is a great strength over random PPA. Some of them are maintained by skillful people, some others are not. If you trust Debian for its packages, the backports are made by Debian Developers too.
For nginx, there is no 1.8 because backports are taken from the next release. As this next release is currently frozen, the version proposed in backports is still 1.6.2.
Using a Debian Stable with backports should allow you to get what you want: stability for most packages but latest releases (and latest bugs/changes) for a selection of packages.
Earlier quoted context omitted.
I also wonder the reason for that. As a speculation from an outsider, I'll list these reasons: Release team was very motivated in this cycle (auto removal of packages, not letting any new package in freeze, very strict exceptions even for packages that fix bugs etc.), most of current rc bugs are lurking there for months without any progress (and since Debian is all volunteer work, they can't force anybody to fix 'em)…
Has there been a significant loss of Debian senior development resources to the https://devuan.org fork, as a result of the systemd debates?
edit: I don't know if he is going Devuan, but is related.