[mythtv-users] Myth backend: Console or GUI OS ? Init level 3 or init level 5 ?

Warpme warpme at o2.pl
Mon Sep 12 19:34:50 UTC 2011

On 9/12/11 8:18 PM, linux guy wrote:
> I'm about to start building my Myth backend and I can't seem to find 
> anything that discusses the pros and cons of installing the OS (Fedora 
> 15) as console only or GUI, ie install KDE as well.
> So, other than a bit of disk space, is there any reason why I 
> shouldn't install KDE when I set it up ?
> Is there any great disadvantage to running the server in init level 5 
> (ie KDE, xorg, etc) running in the background, but not being logged 
> in, versus init level 3 ? (Or whatever they call these things these 
> days..., ie F15 uses systemd...)
> FWIW, my backend hardware will sit on a server rack in the utility 
> room.  I might drag a display and keyboard down there once in a while 
> to troubleshoot and/or do maintenance, but mostly I'd ssh in and 
> probably use a remote desktop app to work on it.
> FWIW, I'm OK doing things via the CLI, but sometimes its really nice 
> to have graphical tools.
> I look forward to your input.
> Thanks
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
I'm assuming You are building distributed system where BE will be on 
dedicated machine serving frontends connected via local network.
If so, Your situation is quite similar to mine. Some time ago I was on 
exactly the same decision point and I decided to take GUI less approach.
Initially I was using Debian, but soon I observe that I have 10G OS part 
with tons of software where only 20% is relevant to things running on 
server. The same for files on system HDD. I like orderliness so I decide 
to trash Debian based solution and build something where I will have all 
under my control.
I started consider distro which is "build exactly for purpose" type of 
OS. Appliance is probably good word here.
Choice was two-fold: Gentoo and Archlinux. Brief look on both shows me:
+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

+You control all major aspect of Your OS (when use ABS - IMHO it is 
comparable with Gentoo)
+upgrades are really easy...but it's rolling release. My stability 
policy is: not touch if it works - so this is not argument.
+has IMHO BEST package management subsystem.

So I ended with OS having only installed & running bits which are needed 
with all non-core binaries compiled by me.
Now it is stripped to minimum core of Arch with replaced init sybsytem 
(systemd; love it), majority packages, etc.

systemd has nice feature: it can initiate app/daemon i.e. only when 
there is incomming comm.request for it.
For daily management I use console (well, in reality I have set of 
PHP/Perl scripts allowing me to manage server via HTTP).
For GUI needing apps (myth-setup) I use VNC, which - when requesting - 
fires XORG via systemd socket activation.

Results are nice:

[ 0.000000] Kernel command line: root=/dev/sda1 ro vga=0x305 loglevel=3 
init=/bin/systemd --sysv-console --default-standard-output=syslog 
--default-standard-error=syslog vmalloc=512M acpi_enforce_resources=lax
systemd 30 running in system mode. (+PAM -LIBWRAP -AUDIT -SELINUX 
Set hostname to .
Sys-Production: clean, 89170/320000 files, 878686/1279167 blocks
New seat seat0.
Startup finished in 2s 407ms 707us
(Sure - for server OS boot time isn't important. Right.)

 From resources point of view - it is nice that I have running only what 
is needed at given moment. - this applies especially after boot. All thx 
socket based activation.

systemd is also really nice in terms of cgroup use for sandboxing 
resources for running processes.
For me it was important as sometimes I have hang daemon which consumes 
100%. Before systemd, server becomes dead on HTTP and really crawl on 
console. Now it is not case. No mater what happens - I can enter daemon 
management page and restart errant process (well at least so far I was 
able to do so).
Grouping child processes in cgroup is another nice for proc.management. 
No any escaped CGI childs, etc.

Oh I can write about it another hour.....

Summarizing: I'm strongly believer of minimalistic, GUI less approach 
for BE server.
For FE I'm fan of disk-less, network booted small appliances (but this 
is another story).


-------------- 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/20110912/f31da037/attachment.vcf 

More information about the mythtv-users mailing list