[mythtv-users] Backend OS - opinions on Archlinux

[Warpme]

On 1/6/13 1:11 AM, Nick Rout wrote:
> I am looking at updating my backend, made necessary by the fact that 
> it is mythbuntu 10.04 (no myth 0.26 packages).
>
> I really hate this 2 yearly cycle of updating ubuntu distros, even on 
> LTS. I thought maybe a rolling release like Arch would alleviate me 
> from having to do that.
>
Hi,

Some time, when making Myth as appliance in my home, I was on that 
decision point: should I go with dedicated distro or Gentoo or....
When I look on Mythbuntu - I see 10G OS part with tons of software where 
only 20% or so is relevant to things which my server will do.
Generally, I think in MythBuntu level of internal complications 
implemented for achieving external simplicity is non-proportional. I'll 
skip mercifully things like upstart etc.
My last 4y experience is that GNU/Linux is environment where long-term 
quality increases (I mean quality - not features). This leads to 
advantages when OS is rolling release. Price here are rare issues 
related to culture of unstable GNU/Linux config space - so sometimes - 
after full system upgrade - manual intervention is required. Heh - some 
devs wrongly assumes interfaces instability is price for fast/unmatched 
growth/development.
But with proper approach - user can minimize rolling-release effect 
while fully exploiting benefits of long-term quality increase.
Basically I started with precisely controlled Arch upgrades (do them 
when must) and ended with my own set of almost all OS components (also 
with my own pacman repository).

Speaking about Gentoo vs. Archlinux. Brief look at that time showed me:
1\gentoo
+You control EVERY aspect of Your OS (starting from what is on HDD, 
ending on how binaries were compiled)
-compiles and upgrades sometimes are not so easy
-doing full system upgrade means recompile many OS components

2\Arch
+You control all major aspect of Your OS (IMHO it is comparable with 
Gentoo)
+full OS upgrades are really fast & easy (single cmd)... - but as it is 
rolling release - so You have to be really careful. Alternative is to 
create & switch to Your own repo - but still repo have to have only 
delta packages (mainly Your's custom ones). So even if You choose Your 
own repo strategy - labour is still far less than Gentoo (sometimes it 
might be even zero) and additionally You care reuse best on earth 
package distributon system (believe me).

So...I started with Arch + controlled upgrades and ended with OS based 
on Arch concepts (mainly init boot infrastructure, pacman and ABS) and 
complied by me bits.
Looking with +2y experience on such approach I must say I don't even 
remotely meet of 90% of problems mentioned by other ppl on this 
mailing-list.
Maybe this is only luck, but I personally believe it is not.
I believe it is result of past choice where I decided: BE will be based 
on Arch while FE on Minimyth.

If You are interested on routinely maintenance of such system:
-My server has 2 mirror 5G partitions: production & testing
-Before every major change in system I do rsync production -> testing
-Every 6-8 months I do: rsync production -> testing; reboot to testing; 
do full OS upgrade + install per-compilled packages where I have 
customizations (kernel, mythtv, etc); runn such system for month or 2.
-in case of major upgrade issue I can reboot to production part within 
minutes so WAF is OK.
-when upgraded OS passes 1-2 months of tests, I do rsync 
testing->production and reboot to production. I also refresh all 
packages in my repo - so all users of my solution can do safe upgrade of 
whole appliance just by 1 command :-). They do this from GUI - so 
opinion is that system easy & stable.

So far above procedure works OK for me, and think is right balance 
between simplicity & effectivness (no any ZFS shapshots, complicated OS 
re-installs, etc)

br

-------------- next part --------------
A non-text attachment was scrubbed...
Name: warpme.vcf
Type: text/x-vcard
Size: 83 bytes
Desc: not available
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130110/cc464cfb/attachment.vcf>