TiVo Community
TiVo Community
TiVo Community
Go Back   TiVo Community > Main TiVo Forums > TiVo Home Media Features & TiVoToGo
TiVo Community
Reply
Forum Jump
 
Thread Tools
Old 06-09-2012, 01:29 PM   #31
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
Quote:
Originally Posted by unitron View Post
Is

Deb--eee--an

not correct?
Yes, with the accent on the second syllable.

Quote:
Originally Posted by unitron View Post
I don't see how the spelling would suggest anything else.
Well, first of all, the accent could be on the first syllable, or even the third. Secondly, the "Deb" could be pronounced deh, duh, or dih. The ian could be pronounced eean or eyeun. Finally, the b could be part of the first or second syllable: deh-bee-un or deb-ee-un.
lrhorer is offline   Reply With Quote
Old 06-09-2012, 02:48 PM   #32
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
Quote:
Originally Posted by markmarz View Post
I get the picture (literally) . I was speaking loosely when I said Leafpad was a gui; of course it isn't itself a gui like windows. Then again, it's not a command line text editor; it has a graphical user interface.
Well, to be pedantic, it requires a GUI. It's a graphical app. Windows desktop, KDE, Gnome, CDE, etc are all GUIs, sometimes called "desktop environments". (Note the "DE" in KDE, CDE, LXDE, etc.)
lrhorer is offline   Reply With Quote
Old 06-10-2012, 04:17 PM   #33
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
Quote:
Originally Posted by lrhorer View Post
If he really, really wants to minimize resources, though, as I say he can disable his DM for the console but leave it active for remote logins.
Sounds good. How do I do that? If it's somewhere in your reply, sorry I can't find it after numerous re-reads.

KDM is my (default) display manager, though GDM is installed, and LXDE is my desktop environment.
markmarz is offline   Reply With Quote
Old 06-11-2012, 09:18 AM   #34
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
I think you're using a DM with which I am not familiar, so I'm not sure. The man pages should tell you, or the configuration file may make it readily evident. Again, look under /etc/default-display-manager. It will list something like /usr/bin/lxdm, /usr/bin/kdm, etc. Assuming it is /usr/bin/lxdm, then there is probably a directory something like /etc/lxde/lxdm. That will contain the config files. One of them should be able to specify that the console not run the GUI. Barring that, you could probably just put a trap in /etc/X11/Xsession or /etc/X11/xinit/xinitrc to check for the active display.

Last edited by lrhorer : 06-11-2012 at 09:25 AM.
lrhorer is offline   Reply With Quote
Old 06-11-2012, 10:29 AM   #35
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
Thanks, I'll dig around.
markmarz is offline   Reply With Quote
Old 06-12-2012, 06:38 PM   #36
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
Quote:
Originally Posted by markmarz View Post
KDM is my (default) display manager, though GDM is installed, and LXDE is my desktop environment.
Oh, heck, how did I miss that? I'm very familiar with KDM. I don't recall at the moment off the top of my head how to disable KDM on the console, but are you really sure you want to bother? KDM just really does not eat up much in the way of resources. If you insist, I can dig into it, though.

I don't recall if you mentioned. How much memory is on that box?
lrhorer is offline   Reply With Quote
Old 06-13-2012, 04:50 AM   #37
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
Quote:
Originally Posted by lrhorer View Post
Oh, heck, how did I miss that? I'm very familiar with KDM. I don't recall at the moment off the top of my head how to disable KDM on the console, but are you really sure you want to bother? KDM just really does not eat up much in the way of resources. If you insist, I can dig into it, though.

I don't recall if you mentioned. How much memory is on that box?
4GB ram, but I could easily up that if there's a reason; I'm trying to conserve energy as much as practical and so far haven't seen a need for more ram. Right now without anything really going on the server consumes 50 watts with 3 out of 5 drives in standby. When it's humming around 80 watts tops.

I don't insist of course! I've been digging around this whole issue and unfortunately getting more and more confused. Considering taking LXDE out of the equation, so I can more easily follow instructions for KDM/KDE. Mainly I just want to be able to turn off X unless I'm remotely logged in.
markmarz is offline   Reply With Quote
Old 06-13-2012, 12:59 PM   #38
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
Quote:
Originally Posted by markmarz View Post
4GB ram, but I could easily up that if there's a reason
No, that should be more than sufficient, with or without KDE or LXDE running on the console.

Quote:
Originally Posted by markmarz View Post
I'm trying to conserve energy as much as practical and so far haven't seen a need for more ram. Right now without anything really going on the server consumes 50 watts with 3 out of 5 drives in standby. When it's humming around 80 watts tops.
That's not bad, at all.

Quote:
Originally Posted by markmarz View Post
I don't insist of course! I've been digging around this whole issue and unfortunately getting more and more confused. Considering taking LXDE out of the equation, so I can more easily follow instructions for KDM/KDE.
Well, that's not necessary, unless you like KDE more than LXDE. You may find yourself using neither one. As William pointed out, it is quite workable to administer the server via ssh / PuTTY and the odd X-window here and there. If you like and prefer using KDE or LXDE, then I suggest you not let performance considerations hinder you. There is a performance hit, but it is a small one, especially in a case like yours. I seriously doubt you would ever know the difference. It's also not going to impact the power consumption.

Quote:
Originally Posted by markmarz View Post
Mainly I just want to be able to turn off X unless I'm remotely logged in.
Well, it's not a matter of "turning X off". Indeed, unless you want to exclusively administer the server using ssh or PuTTY (or telnet) directly, then you probably won't be "turning X off". OTOH, it is possible if one really wants to shut down the X listener, and this would be one option - albeit a bit of a clumsy one - for disabling KDM for the console. Note there is a significant difference between shutting down X entirely and merely not having any X sessions running. It is the individual X sessions that can potentially eat up some resources on the server, not merely having the X framework and X listener in place. It is having permanently running X sessions to which William was referring.
lrhorer is offline   Reply With Quote
Old 06-13-2012, 05:01 PM   #39
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
Quote:
Originally Posted by lrhorer View Post
If you like and prefer using KDE or LXDE, then I suggest you not let performance considerations hinder you. There is a performance hit, but it is a small one, especially in a case like yours. I seriously doubt you would ever know the difference. It's also not going to impact the power consumption.
That's all encouraging! LXDE and KDE are equally new to me; haven't used a windowing environment on the AIX or Solaris servers at work. But then I haven't administered Linux before. Thought maybe a GUI would help me ease into that, and it has been helpful at times. Other times I just get exasperated with the limitations and drop to the command line.

I'd like to keep the GUI around as an option. From what I've read LXDE is particularly suited to low-power boxes like my own.

Quote:
Originally Posted by lrhorer View Post
Note there is a significant difference between shutting down X entirely and merely not having any X sessions running. It is the individual X sessions that can potentially eat up some resources on the server, not merely having the X framework and X listener in place. It is having permanently running X sessions to which William was referring.
I think grasping this is what's really hanging me up. Right now my server when booted brings up LXDE (and I guess KDM behind it, and X behind them both .. unless that premise is wrong, too). Anyway, isn't the GUI itself an X session on the server? Or are we only talking about X sessions in terms of remote X sessions when I'm using X-Ming on my pc?

I think an ideal working scenario would be that Debian boots up in console mode. From there I could bring up the GUI if I wished, whether locally on the server or when remotely controlling the server. But as an option in either case. But with all the information you've given me re resources, I'm fine with having the server come up as it does now with LXDE running. If that doesn't mean I have an X session up all the time.

Clear as mud, right?
markmarz is offline   Reply With Quote
Old 06-13-2012, 11:52 PM   #40
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
Quote:
Originally Posted by markmarz View Post
Thought maybe a GUI would help me ease into that, and it has been helpful at times. Other times I just get exasperated with the limitations and drop to the command line.
Well, that's good. It proves the CL is not daunting to you, so it always exists as an easy option, whether primary or secondary.

Quote:
Originally Posted by markmarz View Post
I'd like to keep the GUI around as an option. From what I've read LXDE is particularly suited to low-power boxes like my own.
Yours isn't all that low power, in terms of CPU and memory horsepower. For low power think: 512M of RAM and 800MHz Pentium 4. Yours is in the middle. That said, I am indeed given to understand LXDE is light on processor and memory demands, while KDE is on the heavy side. 'Still nothing like Windows, though.

Quote:
Originally Posted by markmarz View Post
I think grasping this is what's really hanging me up. Right now my server when booted brings up LXDE (and I guess KDM behind it, and X behind them both .. unless that premise is wrong, too).
It depends on what you mean by "behind". X is the graphical system. It is the basis for all windowed operations in Linux. One cannot run any sort of graphical application, either remotely or locally, without it. The Display Manager ( XDM, KDM, GDM, LXDM, etc ) is merely a gateway to the local Desktop Environment. If a local DE (KDE, LXDE, Gnome, CDE, etc. ) is not being used, then the DM is not necessary. This is the case for text logins and for graphical apps using a remote DE. In the example of using ssh or PuTTY to log in to the workstation and bring up a window on a Windows machine, the DE is Windows, and neither a local DM nor a local DE is required for that instance. In the case of a local DE either from the console or via XDMCP, the local DM provides the login facilities and also typically allows one to select between several DEs. It's only a gateway facility, though, and essentially evaporates for the current terminal after it hands over control to the DE.

Quote:
Originally Posted by markmarz View Post
Anyway, isn't the GUI itself an X session on the server?
Yes, it is.

Quote:
Originally Posted by markmarz View Post
Or are we only talking about X sessions in terms of remote X sessions when I'm using X-Ming on my pc?
Not exclusively, no, but that is one example.

Quote:
Originally Posted by markmarz View Post
I think an ideal working scenario would be that Debian boots up in console mode.
In this context, Debian doesn't exactly boot up in any mode. It sounds to me like you are thinking of Linux as if it were a single user system like Windows. Each terminal has its own display attributes, and any one can be graphical or text mode. It just happens that by default Linux outputs its boot display to the console. That can be easily changed, however. Many Linux boxes output their boot display to a serial port, for example.

Quote:
Originally Posted by markmarz View Post
But with all the information you've given me re resources, I'm fine with having the server come up as it does now with LXDE running. If that doesn't mean I have an X session up all the time.
It isn't running, though, unless you log in to the console (or set up an automatic, password-less console login) or through one or more XDMCP sessions. That's my point. The system you have in place right now is quite considerate of your PC's resources, and will operate swimmingly as a general purpose server, just like it sits.

Try the following. Log out of the console, leaving the greeter (this is KDM) running. If you have any XDMCP sessions running, log out of them, as well. (You don't need to shut them down, necessarily, just log out.) Use telnet, ssh, or PuTTY to open a text terminal on the server and ps | grep for kde (or lxde, or whatever). You will see something like the following:

Code:
Backup:~# ps -ef | grep kde
root     18775 18774  0 23:18 ?        00:00:01 /usr/lib/kde4/libexec/kdm_greet
root     25883 18792  0 23:23 pts/0    00:00:00 grep kde
As you can see, KDE is not running, only a single thread per active terminal for the KDM greeter. The CPU resources used by the greeter are totally trifling, and the memory eaten up by it is quite small, especially compared to 4G. Now if you log in to the GUI on one of the terminals and run the same command, you will get something like the following:

Code:
Backup:~# ps -ef | grep kde
root     20883 18774  0 23:42 ?        00:00:00 /bin/sh /usr/bin/startkde
root     21054 20883  0 23:42 ?        00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
root     21057     1  0 23:42 ?        00:00:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
root     21099     1  0 23:42 ?        00:00:00 /usr/lib/kde4/libexec/start_kdeinit +kcminit_startup
root     21100     1  0 23:42 ?        00:00:00 kdeinit4: kdeinit4 Running...                  
root     21101 21100  0 23:42 ?        00:00:00 kdeinit4: klauncher [kdeinit] --fd=9           
root     21103     1  0 23:42 ?        00:00:00 kdeinit4: kded4 [kdeinit]                      
root     21109 21100  0 23:42 ?        00:00:00 kdeinit4: ksmserver [kdeinit]                  
root     21169     1  0 23:42 ?        00:00:00 /usr/lib/kde4/libexec/polkit-kde-authentication-agent-1 -session 10b7d1636b000127518319700000031170007_1339647497_902533
root     21171     1  0 23:42 ?        00:00:00 kdeinit4: konsole [kdeinit] -session 10b7d1636b000125714857500000109760011_1339647497_902916
root     21231     1  0 23:42 ?        00:00:00 kdeinit Running...                      
root     21234     1  0 23:42 ?        00:00:00 dcopserver [kdeinit] --nosid --suicide  
root     21236 21231  0 23:42 ?        00:00:00 klauncher [kdeinit] --new-startup       
root     21240     1  0 23:42 ?        00:00:00 kded [kdeinit] --new-startup            
root     22674 21100  0 23:43 ?        00:00:00 kdeinit4: kio_trash [kdeinit] trash local:/tmp/ksocket-root/klauncherT21101.slave-socket local:/tmp/ksocket-root/krunners21132.slave-socket
root     24090 18792  0 23:44 pts/0    00:00:00 grep kde
Those are some of the resources of which William was speaking, and although they are not massive, they do represent a little something in the way of a drain on the server. This can be completely avoided, however, by simply not logging in.
lrhorer is offline   Reply With Quote
Old 06-14-2012, 05:46 AM   #41
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
Big Grin

Quote:
Originally Posted by lrhorer View Post
It depends on what you mean by "behind". X is the graphical system. It is the basis for all windowed operations in Linux. One cannot run any sort of graphical application, either remotely or locally, without it. The Display Manager ( XDM, KDM, GDM, LXDM, etc ) is merely a gateway to the local Desktop Environment. If a local DE (KDE, LXDE, Gnome, CDE, etc. ) is not being used, then the DM is not necessary. This is the case for text logins and for graphical apps using a remote DE. In the example of using ssh or PuTTY to log in to the workstation and bring up a window on a Windows machine, the DE is Windows, and neither a local DM nor a local DE is required for that instance. In the case of a local DE either from the console or via XDMCP, the local DM provides the login facilities and also typically allows one to select between several DEs. It's only a gateway facility, though, and essentially evaporates for the current terminal after it hands over control to the DE.
Yes! The fog is clearing!

Quote:
Originally Posted by lrhorer View Post
In this context, Debian doesn't exactly boot up in any mode. It sounds to me like you are thinking of Linux as if it were a single user system like Windows. Each terminal has its own display attributes, and any one can be graphical or text mode. It just happens that by default Linux outputs its boot display to the console. That can be easily changed, however. Many Linux boxes output their boot display to a serial port, for example.
I knew nothing about this; this explanation helps a lot.

Quote:
Originally Posted by lrhorer View Post
It isn't running, though, unless you log in to the console (or set up an automatic, password-less console login) or through one or more XDMCP sessions. That's my point. The system you have in place right now is quite considerate of your PC's resources, and will operate swimmingly as a general purpose server, just like it sits.
Great! But I'm unclear on whether or not I'm running an XDMCP session ever. I think this is the protocol that would be used by (say) X-Ming, right? If that's the case then I'd only have such a session if I kicked off X-Ming, I reckon. Tried grepping xdmcp variations from ps, no show.

Quote:
Originally Posted by lrhorer View Post
Try the following. Log out of the console, leaving the greeter (this is KDM) running. If you have any XDMCP sessions running, log out of them, as well. (You don't need to shut them down, necessarily, just log out.)
See above re XDMCP. Here's something I didn't notice before: the login (greeter?) screen has a menu option at the bottom of the screen which offers Console Login as an option. Great! That gives me half of what I need.

How, after logging in on the console on the server, can I switch to a GUI session on the server? I tried logging out and that will pop up the initial greeter screen where I have this option. The Samba daemon (for example) still is happily running. But I imagine if I were to kick off a program from the command line, say pyTivo, then logging out would kill it. Right? Soon I'm going to attempt your init.d scripts for pyTivo and pyhme so they run as daemons. That'll probably open some questions on that thread!

Quote:
Originally Posted by lrhorer View Post
Use telnet, ssh, or PuTTY to open a text terminal on the server and ps | grep for kde (or lxde, or whatever). You will see something like the following:
Indeed I did.

Quote:
Originally Posted by lrhorer View Post
As you can see, KDE is not running, only a single thread per active terminal for the KDM greeter. The CPU resources used by the greeter are totally trifling, and the memory eaten up by it is quite small, especially compared to 4G. Now if you log in to the GUI on one of the terminals and run the same command, you will get something like the following:
I didn't. Tried grepping lxde, xde, kdm .. still same display as before. What I did was open a new Putty session using SSH, as usual. Then I kicked off X-Ming and then Leafpad, which displayed correctly on my pc. Then tried ps -ef | grep lxde and so on with no change. This I'm sure is not an essential point; something is running somewhere to support my X session!

Thanks a million!

markmarz is offline   Reply With Quote
Old 06-14-2012, 11:26 AM   #42
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
Big Grin

BTW .. and this is amazing to me .. now at idle the server is pulling 25 watts , and when doing all I can imagine I'd want it to do at once .. ie, pushing an avi, syncing raid (using SnapRaid, my bad), and just for the heck of it adding a file through Samba on my windows client & pulling another at the same time .. it uses 35 - 40 watts with a momentary peak at 45. In other words, the energy bill is halved!!

I might replace the 160gb boot drive with a solid state drive and should be able to chop off another 6 watts. Man, 19 watts for a server with 12TB+ ?! Woo hoo!!

Quote:
Originally Posted by markmarz View Post

Thanks a million!
Worth repeating!
markmarz is offline   Reply With Quote
Old 06-14-2012, 02:13 PM   #43
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
Quote:
Originally Posted by markmarz View Post
Great! But I'm unclear on whether or not I'm running an XDMCP session ever.
You certainly don't have to, but in some cases it can be convenient. For example, having multiple Xterms active using the tabbed terminal feature of KDE can be very handy. Cut-and-paste is much easier and more powerful under KDE than under Windows, etc.

Quote:
Originally Posted by markmarz View Post
I think this is the protocol that would be used by (say) X-Ming, right?
Well, it is one of them. X-Ming provides all the protocol support for X-Server operation, including XDMCP, X-Windows, etc. It allows you to import an X display into a window, export a DE into a window, replace the Windows DE with a foreign one, and so forth. The latter two are done via XDMCP. XDMCP stands for X Display Manager Control Protocol. Basically, it is a means of bringing a DM remotely. If the user is not going to log in to a DE, then he doesn't need a DM. If he doesn't need a DM, then he doesn't need XDMCP. Using ssh or PuTTY to log in to an X machine and export an X client to some other machine (not necessarily the machine from which the ssh / PuTTY session is spawned), then no DE, DM, or XDMCP is required or will be running on the local server for any sessions spawned from that Xterm. An X-server (in this case X-Ming) is required, however.

Quote:
Originally Posted by markmarz View Post
If that's the case then I'd only have such a session if I kicked off X-Ming, I reckon.
Well, X-Ming is required for any X-server operations, not just XDMCP. It supplies the display(s) on the remote machine, whether for XDMCP, X-window client sessions, whatever.

Quote:
Originally Posted by markmarz View Post
Tried grepping xdmcp variations from ps, no show.
Oh, well, yeah, you won't. XDMCP is not an application, it is a protocol supported by most X-servers, plus it runs on the X-server, not the X-client machine. The DM and then the DE run from the client machine, at the behest of the XDMCP protocol running on the X-server.

Quote:
Originally Posted by markmarz View Post
See above re XDMCP. Here's something I didn't notice before: the login (greeter?)
Yep.

Quote:
Originally Posted by markmarz View Post
screen has a menu option at the bottom of the screen which offers Console Login as an option.
Yep, as well as options to spawn one of a number of different DEs (if installed) and the ability to spawn a DE from a different X-client machine.

Quote:
Originally Posted by markmarz View Post
Great! That gives me half of what I need.
I think it gives you all of what you need, really.

Quote:
Originally Posted by markmarz View Post
How, after logging in on the console on the server, can I switch to a GUI session on the server?
Well, it might be possible to run KDM, but there is no reason to do that. You already had KDM running, and simply exiting will take you back to KDM.

Quote:
Originally Posted by markmarz View Post
I tried logging out and that will pop up the initial greeter screen where I have this option. The Samba daemon (for example) still is happily running. But I imagine if I were to kick off a program from the command line, say pyTivo, then logging out would kill it. Right?
That is an entirely different matter, and it won't make any difference if pyTiVo or anything else that has not been daemonized is run from a parent session. Killing that session will kill the child process, whether the parent is a text app or a GUI.

To daemonize an app that is not a daemon binary (like SAMBA, FTPD, telnetd, etc.) requires two steps. The first is to spawn the app in the background, rather than the forground. This is very easy to accomplish. Simply add an ampersand (&) to the very end of the command line. This sequesters the app into a separate, non-interactive thread tree and returns console control to the parent. Note this won't work very well if the spawned app requires any input from the user.

The second step is to use a detachment utility to spawn the app as a detached process. At a high level, what this does is prevent the spawned app from responding to signals from the parent app. At a low level what happens is the app is detached from the PID of the parent app and attached to the init thread (PID 1). The utility most often used to accomplish this is called `nohup`, which is short for NO-HangUP. It provides for a number of options, including automatic re-direction of stdout and stderr.

In the simplest incantation, daemonizing pyTivo can be done by merely typing

Code:
nohup python pyTivo.py &
Whether invoked from a GUI, an ssh text session, or an automated script, that session of pyTivo wil not terminate when the parent terminates.

Quote:
Originally Posted by markmarz View Post
Soon I'm going to attempt your init.d scripts for pyTivo and pyhme so they run as daemons. That'll probably open some questions on that thread!
OK. That is precisely what I would recommend. The System V init utility provides some very powerful and elegant ways to handle the starting and stopping of system daemons. If you are at all familiar with modular scripting methods, then the init files will be a breeze. If not, then it can take a bit to understand the structure of these utilities, but the use of them is dead simple. One simply types the qualified name of the init file and then the single option start, stop, restart, or reload. Any time the init utility implements a runlevel change, the scripts are all invoked in appropriate order with the command tail appropriate to the runlevel being entered.

Quote:
Originally Posted by markmarz View Post
I didn't. Tried grepping lxde, xde, kdm .. still same display as before. What I did was open a new Putty session using SSH, as usual. Then I kicked off X-Ming and then Leafpad, which displayed correctly on my pc. Then tried ps -ef | grep lxde and so on with no change. This I'm sure is not an essential point; something is running somewhere to support my X session!
No, no. It is an essential point to your stated intent. LXDE and KDE were NOT running. That is why nothing but the KDM reference showed up. I think this has in fact accomplished everything you really want to happen. If you spawn an XDMCP session from the Windows PC, or if you log in to the console on your Linux machine, you will see quite a few threads related to KDE (or LXDE, or both) running on the machine. Just spawning an X-window or ten won't.

Quote:
Originally Posted by markmarz View Post
Thanks a million!
Really? Small bills, please.

Last edited by lrhorer : 06-14-2012 at 02:21 PM.
lrhorer is offline   Reply With Quote
Old 06-14-2012, 02:27 PM   #44
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
Quote:
Originally Posted by markmarz View Post
BTW .. and this is amazing to me .. now at idle the server is pulling 25 watts , and when doing all I can imagine I'd want it to do at once .. ie, pushing an avi, syncing raid (using SnapRaid, my bad), and just for the heck of it adding a file through Samba on my windows client & pulling another at the same time .. it uses 35 - 40 watts with a momentary peak at 45. In other words, the energy bill is halved!!
Go green.

There's some cool stuff going on there, isn't there?

Quote:
Originally Posted by markmarz View Post
I might replace the 160gb boot drive with a solid state drive and should be able to chop off another 6 watts. Man, 19 watts for a server with 12TB+ ?! Woo hoo!!
Yeah that would work just fine. A USB thumb drive would save a bit more even and would cost less, too. The server performance would not suffer, and the UI performance would not be hideous.
lrhorer is offline   Reply With Quote
Old 06-14-2012, 06:11 PM   #45
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
As usual you've given me a lot to absorb, but I'll study what you've given me and of course do some background reading as well. Can't tell you enough how grateful I am to you!
markmarz is offline   Reply With Quote
Old 06-14-2012, 06:16 PM   #46
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
Quote:
Originally Posted by lrhorer View Post
A USB thumb drive would save a bit more even and would cost less, too.
You know I actually have installed Debian on a thumb drive and ran it from there fine. Only concern is I've been picking up .. right or wrong .. that thumb drives tend to be less reliable than ssd's, and even the latter has problems. It so happens that I had been storing a few movies on a 64gb thumb drive and when I tried to pull them off, I had read errors on a couple. There's also wear leveling considerations, etc etc. So I haven't yet come down on the ssd/thumb drive decision.

I'll be reviewing your comments in another thread about backup strategies for the boot drive.
markmarz is offline   Reply With Quote
Old 06-14-2012, 06:24 PM   #47
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
Quote:
Originally Posted by markmarz View Post
that thumb drives tend to be less reliable than ssd's, and even the latter has problems. It so happens that I had been storing a few movies on a 64gb thumb drive and when I tried to pull them off, I had read errors on a couple. There's also wear leveling considerations, etc etc. So I haven't yet come down on the ssd/thumb drive decision.
That is quite correct, which is why if you do go with a bootable thumb drive, you want to make some changes to the Linux configuration. First of all, you want to have /var, /tmp and the swap plus any other directories that get written on a continual basis on the hard drive, not the thumb drive. Then there are certain other changes that need to be implemented to place certain Linux facilities either on the hard drive or in memory. Basically, you want to make sure the system is not writing to the media continuously.
lrhorer is offline   Reply With Quote
Old 06-15-2012, 04:37 AM   #48
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
Quote:
Originally Posted by lrhorer View Post
First of all, you want to have /var, /tmp and the swap plus any other directories that get written on a continual basis on the hard drive, not the thumb drive.
Yes, I'd like to move as much as possible to part of that 4GB of ram I'm not currently using. If I'm going with flash I'd rather avoid writing to a spinning hard drive as well. The more I do that, the less it makes sense to use flash.
markmarz is offline   Reply With Quote
Old 06-15-2012, 04:44 AM   #49
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
Also even if the boot drive is spinning 24 (though usually idle & spinning) hours a day .. which may be the case since for some reason it ignores my spindown command .. the rough average cost per day is 2 to 3 cents.

Maybe I'm getting a bit crazy on the green side. Of course there's more to the cost than dollars and cents. But that's a whole other discussion. Mainly just trying to get some perspective.
markmarz is offline   Reply With Quote
Old 06-15-2012, 01:30 PM   #50
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
Quote:
Originally Posted by markmarz View Post
Yes, I'd like to move as much as possible to part of that 4GB of ram I'm not currently using. If I'm going with flash I'd rather avoid writing to a spinning hard drive as well. The more I do that, the less it makes sense to use flash.
Well, using loop devices, it is possible to move all writes off any sort of drive. That's how a lot of embedded Linux systems do it. The down side is one looses any log information whenever the system crashes or gets rebooted. That in turn can make it devilishly difficult to troubleshoot kernel panics or other problems. OTOH, on a very stable system like a server, it is not at all an unreasonable thing to do, and in such a case the frailty of a USB drive is minimized. One can even boot from CD-ROM. It doesn't get cheaper than that, or easier to make backups.
lrhorer is offline   Reply With Quote
Old 06-16-2012, 05:39 AM   #51
markmarz
Registered User
 
Join Date: Feb 2002
Location: Chicago, IL
Posts: 80
Quote:
Originally Posted by lrhorer View Post
Well, using loop devices, it is possible to move all writes off any sort of drive. ... One can even boot from CD-ROM. It doesn't get cheaper than that, or easier to make backups.
Both very interesting subjects to explore, thanks!

Just one question re CD-ROM boots .. why would a backup of the boot drive be necessary? I'm presuming all write activity to the boot drive is suppressed, so there would be no adjunct files on some writable media to backup, right? If that's the case then you might backup the CD-ROM once for safety and never again. Unless you change things. Right?
markmarz is offline   Reply With Quote
Old 06-16-2012, 01:27 PM   #52
lrhorer
Registered User
 
Join Date: Aug 2003
Location: San Antonio, Texas, USA
Posts: 6,858
That's right. Of course, at about $0.10 a copy, I think you could afford at least two.
lrhorer is offline   Reply With Quote
Reply
Forum Jump




Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Advertisements

TiVo Community
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
vBulletin Skins by: Relivo Media

(C) 2013 Magenium Solutions - All Rights Reserved. No information may be posted elsewhere without written permission.
TiVoŽ is a registered trademark of TiVo Inc. This site is not owned or operated by TiVo Inc.
All times are GMT -5. The time now is 06:16 AM.
OUR NETWORK: MyOpenRouter | TechLore | SansaCommunity | RoboCommunity | MediaSmart Home | Explore3DTV | Dijit Community | DVR Playground |