The commond way to start tasks automatically in Linux is to use a daemon. For example, sshd (ssh daemon) starts listening for ssh connections at boot, mpd starts up the music player daemon at boot. If you can find a daemon that does what you want, you just have to tell your machine to start it up on boot. This can be done with chkconfig in Fedora, and I imagine this would also be true on other distros which use a systemd init, but I'm not 100% on that. On Arch and other distros using a Sys V style init, you simply add the daemon you want to your daemons array by editing the file at /etc/rc.conf. Then the daemon will start up on boot after you add it, and wait for you to execute a command that it handles.
If you don't need a daemon running all the time or can't find one that would be appropriate for the task, or you just need to execute it once when you start, you can add the command to your ~/.xinitrc before the exec line that starts up your DE/WM. I'm not sure if gnome reads the file, so that may not help for you. You could always edit the login manager's configuration to make sure it does that by making it use the startx command. You could also switch to a login manager that uses startx by default. I find the simplest method for me is to just make my computer boot to the console. I can screw around and does stuff from a tty if I want, don't need to fiddle with a login manager, and if I want to fire up a graphical display,I can just run startx myself. If you use one of these methods that execute the startx command, you just need to edit the ~/.xinitrc file and make the last line
Code:
exec foo
with foo being whatever the command is that launches your favourite DE/WM. The lines before that last one can contain various commands typed as you'd enter them at a terminal, and they'll run as soon as you use startx. I believe you should be able to just toss your ssh command on one of these lines, and it should work. If I'm wrong, hopefully lx or devilock can come along and tell you the correct way of doing it.
For example in my .xinitrc on BSD where I use fluxbox mostly, conky is executed automatically. I dare think of the length of my /etc/rc.conf on that machine considering all the services it starts...
Sweet, thanks guys! My newest problem is that it say my home drive is full and has no more space I only have 20 gigs for the home partition because everyone said that would be enough but I need about 4x that amount of space because I plan to install some things. Is there any way of expanding this partition without frying my Windows partition? I am just really scared after destroying my mom's computer while trying to partition it, I can not afford to lose the data on my computer. Is there any relatively safe way to reduce the amount of space on the windows partition and give that the the linux partition?
NO! Seriously, don't dick with the partitions without backing up. For /home, 20gb should be plenty unless you're storing tons of media. You don't have to do that. You can put media on your Windows partition, an external drive, or a network share.
Sweet, thanks guys! My newest problem is that it say my home drive is full and has no more space I only have 20 gigs for the home partition because everyone said that would be enough but I need about 4x that amount of space because I plan to install some things. Is there any way of expanding this partition without frying my Windows partition? I am just really scared after destroying my mom's computer while trying to partition it, I can not afford to lose the data on my computer. Is there any relatively safe way to reduce the amount of space on the windows partition and give that the the linux partition?
NO! Seriously, don't dick with the partitions without backing up. For /home, 20gb should be plenty unless you're storing tons of media. You don't have to do that. You can put media on your Windows partition, an external drive, or a network share.
I don't have any media at all, no pictures, music, videos etc. All I have is the humble indie bundle 3 and 4 but that's it, plus whatever other programs I installed in Yum but there were only a few. Not sure why it's so full. Each game in the humble indie bundle is like 2gb though, which is where the space is coming from.
The problem with backing up is that I don't have a drive big enough to back up my windows partition, it's over 2TB. Can't exactly burn that to a DVD or anything. Oh well, I guess I will just work with what i've got. I should have made the partition way bigger, like 200GB, would have been easier at the beginning.
Programs should be installed to /. There should be almost nothing in /home; just some configuration files, and data. Here's the entire contents of my /home. It's about 3gb total...
Well the big space suck is my 'Downloads' folder, the humble indie bundle games don't have to be installed, they are just executables so I can run them straight from the downloads folder. So you are saying that I should instead put them over in /? I'm still not too familiar with the directory structure yet, everything ive been doing is in the home folder, but I imagine Yum was smart enough to install everything to / hopefully. How do I go about seeing how much space is allocated to each directory/partition? Is that du-h?
How do I move things to /? In the file directory I see:
bin
boot
dev
etc
home
lib
lost_found
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var
Should I be putting things in /usr? I see a games folder in there, is that a good place? I am not sure where / is.
You could put them in /usr/bin. When you install via package manager it puts them in /bin, /sbin. /usr/bin, or /usr/sbin. I haven't paid that close attention, as it just gets handled, and don't have to deal with it. There's been some rumblings about streamlining the file system, but that'll take awhile to happen, if it ever does. Here's a guide on the file structure...
and you'll be able to just type the name of it anywhere to launch the games from the terminal. Now for a different question, is your /home directory on the same partition as /, or on its own partition? I've recommended having it on a separate partition before because you don't run out of space in there if you install a bunch of programs. I'll have to disagree with lx on space needed though. Not storing all your media and documents in /home will eventually lead to clutter, and runs counter to nearly every program you'll run. Music players will all scan your ~/Music directory by default, for example. Sure, you can click through menus and add stuff, but it doesn't encourage a very organized file/directory layout.
When I do an install, I give myself maybe 20-30GB for my / partition, 2GB for swap, default for /boot, and all the rest goes to a separate /home partition. If you don't need to run programs with huge data files, or tons of dependencies, you can certainly get away with trimming / down some. I can think of no real reason why, on a computer with one user you should not use the remaining space after all the other partitions are done for a separatte /home partition.
Edit: To give a quick breakdown on the executable directory layout (as I understand the justifications myself), it's mostly a remnant of back when UNIX was initially starting up on some PDP-11s. /{usr/}sbin are supposed to be executables that require elevated priviledges (ie, a sudo or su password) at some point when they're run. All other executables which could be run with normal priviledges were placed in /{usr/}bin. /bin and /sbin are a remnant of programming UNIX on some massive 1.5MB floppies or so, back in 1970. The programmers couldn't fit everything in just those two directories and still have it all fit on one floppy. To fix this, only the executables that were necessary to run at initial boot were placed in /bin or /sbin. Everything else (should have) got placed under the corresponding directory under /usr, which could be mounted later on a separate partition.
Just toss any executables you need to into the right file under /usr based on its required priviledges. Fedora is already starting to move everything to /usr, and Arch is likely to be close behind them on this one. Several more distros are poised to follow suit after Arch. Honestly, Fedora (and Arch if they agree to do it) will probably have this filesystem pruning done by the end of the year. So, should all be streamlined for them by this time next year, and should happen for Debian stable in an update sometime around spring 2025.
I'll have to disagree with lx on space needed though. Not storing all your media and documents in /home will eventually lead to clutter, and runs counter to nearly every program you'll run. Music players will all scan your ~/Music directory by default, for example. Sure, you can click through menus and add stuff, but it doesn't encourage a very organized file/directory layout.
A small /home is suboptimal, but it doesn't have to be big. All my media is on separate physical drives, and it's easy enough to manage. I use the stock media folders in /home to store temporary files until I decide exactly what I want to do with them. For partitioning, I use 10gb /, 1gb swap, and the rest to /home which is currently 30gb. I left the disaster on my drive alone, and when I get motivated, I want to try to recover the lost files with forensic tools.
I usually build on a dual boot machine a fat 32 partition called /Store that I keep my major share of data, media, etc. On non dual boot this partition is usually ext3 or ufs (freebsd). My home tends to be about 40 gigs, just in case. In arch for examplu I keep all th aur stuff under home.
This looks cool, get an SD card with this loaded onto it and plug it into your Raspberry Pi and you have a mobile meia center. It's an OS that is only a few MB and is builty only for running XMBC and is pre-configured to work as a mobile media center so you don't have to configure it. This will be great since I can finally utilize some of those old sd cards I have that are <1Gb.
Then get SAMBA ona server and load it with movies and you can just stream all your torrents or whatever straight to your TV. Pretty nifty.
The guys at OpenELEC, an embedded OS built specifically to run XBMC, have announced their first ARM port and with it, support for Raspberry Pi.
What is OpenELEC?
OpenELEC is an embedded operating system built specifically to run XBMC, the open source entertainment media hub. The idea behind OpenELEC is to allow people to use their Home Theatre PC (HTPC) like any other device you might have attached to your TV, like a DVD player or Sky box. Instead of having to manage a full operating system, configure it and install the packages required to turn it into a hybrid media center, OpenELEC is designed to be simple to install, manage and use, making it more like running a set-top box than a full-blown computer.
OpenELEC is tiny, at 85-115MB, and for RaspberryPi it comes in at only 70MB, which comprises the whole OS including XBMC, Python, and all services/tools needed to run XBMC. This means that at the moment, it’s the smallest distro for Raspberry Pi that we’ve seen.
cost SD card + Rasberry Pi + Shipping > the $50 Sony Streamer you can get at Best buy that will support DLNA sources as well as Netflix, Hulu, Crackle, Amazon VOD, etc...
cost SD card + Rasberry Pi + Shipping > the $50 Sony Streamer you can get at Best buy that will support DLNA sources as well as Netflix, Hulu, Crackle, Amazon VOD, etc...
Ken
Yah APPLE TV is also similarly priced and does pretty much the same thing too. I guess the difference is that the R Pi is also a full blown computer, and this is just one of many features you get. Kind of like how I could buy an Xbox for gaming at only $199 and it comes pre-configured for just that purpose, but it doesn't really compare to buying a whole computer which can do gaming amongst other things.
I got my R Pi for $35 shipped (they keep changing the price but had to honor the original prices), and already have a bunch of SD cards but the whole thing is just a toy anyways, I already have a roku and an xbox lol. Just thought it was cool that it had a distro just for XMBC that had such a small footprint.
As a follow up question, is there any way to make an FTP client log in via SSH and encrypt all download traffic during the session, so if for example you were downloading something from a server, the ISP couldn't see what it was? Hypothetically. Or is this how FTP works anyways?
Comment