[mythtv-users] Myth backend: Console or GUI OS ? Init level 3 or init level 5 ?
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.
> mythtv-users mailing list
> mythtv-users at mythtv.org
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
+SYSVINIT +LIBCRYPTSETUP; arch)
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...
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