[arch-general] doubts about rolling release

[Ary Kleinerman]

I'm thinking to use Arch for an Asterisk server. Nowadays I'm using
Ubuntu 12.04LTS, but I can see all distribution changing to the new
init system (systemd). I wanna change all my scripts to be compatible
with systemd. Furthermore, my services use MySQL, so I think it's a
good moment to migrate them to MariaDB. In short, I'll use Arch but
I'll have a virtual server (for testing purposes) to make change there
and then if all go okay, I'll apply the updates to the production
environment.


On Mon, Mar 10, 2014 at 12:40 PM, John WH Smith
<jwhsmith at englandmail.com> wrote:
> On 07/03/14 18:09, Ary Kleinerman wrote:
>>
>> Hi,
>> I'm a new Archer and I'm planning to install arch linux in a production
>> server environment, but I have doubts because Arch is a rolling release.
>> My
>> question is: what does it happen when there are big changes? e.g. changes
>> in the filesystem or when Arch has started using systemd.
>> Regards,
>> Ary
>>
> Hi,
>
> As far as the rolling release is concerned, I don't think it should be
> banned just because the servers are production ones. To be honest, I think
> the problem goes a little deeper than that, and as it so happens, I ran into
> a similar questioning recently.
>
> I think there are two important questions to ask :
> - Is the server set up for final users or actual programmers/technical folks
> ?
> - Does the server require maximal uptime, and how much downtime can it
> afford to take ?
>
> For the first one, that's what finally brought me back to Debian on my
> latest install, even though I had absolutely no technical issue with using
> Arch. You see, I work with web developers on this machine, and they need an
> nginx server with PHP and MySQL available for their applications. To me,
> that is the tricky thing : these developers would assassinate me if I kept
> updating PHP regularly, because their local development environment doesn't
> have the same update rhythm, meaning I would probably take down their
> applications very often, because they cannot handle versions of PHP higher
> than theirs. Pretty logical actually, especially with Windows-based
> developers, who need to do a lot more manipulations to keep their WAMP
> install up-to-date (when they can). Same thing happens with other
> applications, even though I can't quote many more right now. Anyway, the
> question reveals an important point when you work with programmers : make
> sure you match development and production environments as much as you can
> (and it *does* require a lot of efforts if one of them is Arch).
>
> Now, if your server aims at final users, like students (out of the computing
> field) or administratives, then I don't see many risks to anticipate.
> Applications do not rely on each other very much, crashing one doesn't mean
> taking the whole thing down. A failed update could be fixed without too much
> services downtime required.
>
> The other question on the other hand remains quite obvious. If your server
> runs a simple Intranet in a company, where documents can still be shared
> physically in last resort, well : install Arch and enjoy the ride! The
> information system can afford longer downtimes, giving you enough time to
> fix whatever update messed things up. By the way, I strongly believe you
> will fix things faster if you like your environment (I assume it is Arch
> here, of course). Being used to your system is much more important than its
> stability when it comes to your sysadmin speed of reaction.
>
> All in all : think about who uses (and messes with) your server, and how
> much they rely on it. To me, those are two important things to take into
> account when choosing your distribution.



-- 
Ing. Ary Kleinerman
Building Networks S.A.
Córdoba, Argentina
+54 351 5544150