Electronic Circuits and Projects Forum

Kinda curious why you decided to go with something like Crunchbang (first I've heard of it - but there are more flavors of *nix distros than there are grains of sand, it sometimes seems), rather than something more "mainstream" like Ubuntu or Mint (or heck - just plain Debian)?

I mean, for a linux noobie - going with a cut-down distro seems like a potential path to frustration; then again, maybe it is better to go that way. I started playing with Linux in 1995, with a "distro" called MonkeyLinux, which ran on top of a DOS filesystem (I had it running on an old 386 laptop with 6 meg of RAM). I later moved to playing with TurboLinux 2.0, then on to Redhat 5.1; back then, you had to have the patience of a saint sometimes to get things working, and compiling your own kernel was pretty well mandatory (I'd suggest you give it a try - even today, if you want some certain obscure features, or you want absolute performance, compiling your own kernel is the way to go - but I haven't done it in years; I have better things to do).

Anyhow - good luck with your new hobby; I'm not sure what you mean by the documentation not being good - there seems to be tons of it out there (and man pages are your friends, too); generally, if you have a problem, start googling around, and don't always insist on finding a specific "crunchbang" solution (there's been more than one time where the solution I was looking for was found in documentation for Unix or BSD variants!).

Originally Posted by AtomSoft

Heh i just love the look of crunchbang. It makes me feel 1337 (leet) or something lol

It does look cool; as long as that doesn't get in the way of anything, it should be OK. On modern hardware, KDE/Gnome aren't really that bad (and if fiddling and tweaking things are what you like to do, check out Enlightenment).

Originally Posted by AtomSoft

But since its basically debian, i heard debian is nice. So i chose it.

Debian is nice - I used to run Woody a long time ago (then I got a new motherboard that Woody didn't support the chipset on, and I had to move to Mandrake). If you want real "l337", then slackware is where it's really at. And if you want uber-l337 - well, you have to "roll your own" distro (easier to do today than it used to be, I might add; for the most part, you should never have to do this, unless you are doing some kind of embedded development, or you just want your own "branded" distro - or you think you can do things better - or...?).

Originally Posted by AtomSoft

what are "man" pages ? i see man used so much but dont know what it means or is. Im telling you i just installed and trying to learn what i will use

Man page are the standard help documentation reference on any *nix system; if you open up a terminal (command line), and type in "man man", you should get (if you have the documentation packages installed) a help page on the "man" command. Just about all software you install from a package will have a man page (but not -all- software; some packages may have little to nothing, or just a web page, or just a text file stuck somewhere - make sure you check the "installed files" of whatever package manager you are using if you need help, to find out if any man pages are installed, or if some other help file was installed - worst case scenario, see if you can locate the package's developer online).

Originally Posted by AtomSoft

I was thinking of learning it for a while then compiling my own kernel, ill need to learn mainly because i intend to get into ARM9 and stuff for embedded linux and need to learn a ton before, hence the entire reason me using linux. Getting a feel for it on a working system first

Yeah - if you're going to do embedded linux development, you have to start somewhere and a PC environment is a good choice...

Originally Posted by AtomSoft

Any more tips? Thanks again for that post !

Well - I would say the best thing to do is to read and collect as much linux documentation, tips, etc that you can find. Troll used book stored and pick up some books; you might even want to read up on some of the older stuff out there, which may be out of date, but it still could be interesting and useful reading. Get used to the command line and using a terminal emulator (I would think it would almost be mandatory for embedded dev work); learn the basic commands for CLI (command line) work:

* ls (analogous to "dir" in DOS - lots more switches to play with, tho)
* cd (change directory)
* pwd (show current directory)
* whoami (show who you are logged in as)
* which (finds the location of system executables)
* /etc/fstab (filesystem table - where you set up pointers to devices for the filesystem)
* /etc/mtab (mounted filesystem table - shows what is currently mounted)
* /etc (generally holds config files and such - has varying structure depending on distro and version)
* rm (remove files/directories - be very, very careful with this, especially as root - it doesn't ask you for verification - especially if you do something like "rm -rf /" or such, you'll blow your system away)
* chown (change permissions of a file)
* chgrp (change group ownership of a file)
* cat (list a file out)
* grep (string search/extraction)
* regular expressions (I hate 'em, but they have a lot of power, so a least learn what they are)
* awk and sed (lots of power in these two commands)
* bash (or other shell scripting - you wouldn't believe what you can do)
* perl (for when bash isn't good enough?)
* ps (process status - shows all running processes)
* kill (kill a process - be careful with this one too)
* learn how to start/stop/restart services ("/etc/init.d/network -restart" for instance, restarts network services)
* ping and traceroute (if you aren't familiar with them)
* vi or vim (sometimes, vi is the only editor you'll have; knowing how to use it may save your bacon!)
* top (tool to allow you to view process usage of memory and such, interactively kill processes, etc - useful at times)
* learn to read your logs for errors (/var/log/*)

That's a lot, I know - and that's just the beginning; there's way, way more out there (and probably tons for the embedded world that I haven't got a clue about!). Remember, that for many of those commands, you can type "man" for (ie, "man ls" will bring up the man page for the ls command). There is a ton of linux command line tutorials and such out there, so play around (be safe, and always use a regular user; only use root for critical stuff, for the most part, you should never need to be root/superuser on your regular system - on an embedded system, it might be a different matter).

Oh - and for embedded development in the GUI, I'm not sure what you plan to use. There are a ton of IDEs out there; I've been playing with a "small" one at my work (where I do PHP web development) called Geany, but it may be too limiting for your work (or it might be perfect?). A lot of people use Eclipse; there's also Code::Blocks. There's enough of them out there; something will work for you. Heck, you might even become a command line maven (or you might be a masochist, and develop a liking for emacs!).

Above all - have fun, and don't get too frustrated when something isn't working out. Sometimes something may just not work (especially weird hardware, but I've been seeing this less and less over the years); many times you may need some special command-line-fu just to get something working. Sometimes you may need to hack the source code and re-compile. Just keep at it, and come back to it later. When you succeed, its a great feeling (especially as you are learning and playing; I'd imagine if you are trying to get some embedded dev work done, it would be very frustrating).

Good luck!

Originally Posted by AtomSoft

OMG WOW im definitely going to print that post. Tons on info and all in one place YAY! I currently find this all fun and getting stuck on something is cool since Google is my best friend lol I used Geany before its cool. Right now i use Netbeans for gcc/g++ stuff. Its the same IDE for MPLAB X so i chose it since im familiar with it Im searching Slackware now so i can see whats its about more. Oh man just want to say thanks so much!

Ok - well, if you're familiar with those tools, then cool; you might want to take a look at Eclipse, too (it may or may not be overkill for what you want to do, though). Like I said, there are tons of IDEs out there. Glad you're having fun; it is pretty exciting!

Originally Posted by AtomSoft

The funny part of linux i found so far is, when you download a new package to install, after extracting(using tar or gui) you have to ensure its set to run as application then to run it i have to ./appname

Something I want to let you know (or, you'll learn the lesson eventually!):

Try to avoid tarball/zipped packages, unless the developer (or whomever) has left you no choice (or you -need- the upgraded features); generally, a tarball/zipped package is designed (if it doesn't just "install" wherever you dumped it) to put its contents (when you "make install") into the "proper" directories - but then again, if the package is old, or designed for another system, it might put its stuff into a "non-standard" directory for the distro you are using. There is this concept out there of a "Linux Standards Base" - which defines directory structures and a whole host of other things, but some distros follow it, others follow their own, etc. It isn't all the "same" like Windows or such, because there isn't one single "form" of "Linux".

Now - this generally doesn't cause too much havoc - but at the same time, it can! You just have to be aware of it, and why/what is happening. Now, you might have run into packages that are ".rpm" or ".deb" packages (there are other styles as well - but these two are the most common today). These are "proper" packages - for Redhat (rpm) and Debian (deb); they are meant to be run thru a "package manager" software (rpm stands for "Redhat Package Manager"); Redhat as you probably are aware is another common Linux distro.

Anyhow, when a package is in these formats, the installer installs it as designed, and at the same time checks for dependencies (are all the libraries in place, proper versions, etc), and won't let you install it until you satisfy those dependencies (well, you can always force an install, but it will likely be broken). As it installs the files, it builds a database of where and what was installed (including any additional files to satisfy dependencies, and whether other files installed use those files as well). This is so when or if you uninstall it (again, thru the package manager software!) - it knows what to remove, and more importantly, what -not- to remove (in the case of libraries that might have been initially installed with package A, but a later package B used them, so if you uninstall package A, it won't uninstall the libraries, until package B is uninstalled). These package managers aren't perfect, but they are much better than manual tarball/zipped file installs.

This is because with a tarball/zipped package - you don't know where/what got installed, or what the dependencies are, when or if you decide to remove something, or upgrade something (unless you look at the makefile or whatever other system was used, build up lists, compare, etc - for -all- of the tarball/zipped packages you installed!). This ultimately can lead you to a mess (and depending on what you are doing, it could be a big mess). Now, for a development/learning system, it might just be something you'll have to live and learn with (you'll most likely run into similar issues on an embedded system anyway - where you'll be the developer and maintainer of the structure). But keep it in mind, and maybe look into how to use and work with the package manager systems (and packaging tools - there are tools out there to convert tarballs and such into proper packages). You'll also want to understand the Linux Standards Base and all the other stuff as well. Lots of stuff to learn and know - but that's the price of entry, I guess!

Normally - this isn't an issue today for regular users - you just pick and choose your packages from the package manager, and install them. It only becomes an issue if you need an upgraded version of the software, and the developer doesn't provide a proper package, instead opting for a tarball/zip file (I am not certain, though - but I seem to recall seeing something somewhere about package manager software being able to handle these files better today - I tend to stay away from them usually, unless they only dump to the local area - but like I said, there are conversion tools, too).

Originally Posted by AtomSoft

what is the "./" for? I know i have to use it otherwise i get a command not found.

Well - first off, theres are paths that are searched by the system when you enter a command at the command line - to find the command. If the command isn't found in these paths, then you get the error you see. By default, the current path you are in isn't searched (this is a good thing, btw - though you can change it!). In both DOS and Linux - there is the environment variable called PATH that controls this. At the command line, if you type in "env", you'll see a list of environment variables for your current session (many of these are set up by default, others are set up by the login for the user, and some are set up by various config files for the user that can be setup in the user's home directory). Notice the one called "PATH" - it says something like "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" (your's may be different); these are the paths searched for by the system for your command/file. Notice that "." isn't among them (or it shouldn't be).

"." is the "current path" - if you "cd ." you won't go anywhere. Now, if you did an "ls -als" in the current directory, you'll see at the top a couple of entries "." (current directory) and ".." (previous directory); to go "back" a directory in the hierarchy, you just say "cd .." (for two levels, "cd ../..", etc).

By typing "./command" - you are saying "execute this command in the current directory". Now - like I said, you can add "." to your path structure if you want; you really shouldn't, though, and just get used to using the "./" convention. There are good reasons why you don't want "." to be a part of your execution path (but if you must, add it to the very end of the PATH statement - I'll leave it to you to figure out how to change it).

Originally Posted by AtomSoft

Ill definitely get some Linux books too now. Thanks again and feel free to post anything else that way come to mind

Well - I can't post anything and everything; some of this you're just going to have to learn the "hard way". BTW - your post about how to dump the output of man to a file, while it can be useful, isn't really something you need to do (unless you really need the file for some reason). The "man" command just reads the "man" files (they are stored elsewhere on the system in a particular "shared" directory); you could just copy those (although they are typically compressed nowadays - on my system, they are gzipped - so you would have to uncompress them first to read them in a text editor or such). If you need to copy/paste the data, most terminal emulators today support copy and paste as well.

Oh - something else about "copy/paste" - while it has gotten better in recent years, it still isn't -completely- unified; there are a couple of "standards" out there - you'll find them fighting against you sometimes. First off, the standard "X window" copy/paste is done by highlighting something, then middle clicking elsewhere to "paste" it (notice there wasn't any explicit copy done). The other standard is to highlight something, then "ctrl-c" and "ctrl-v" (or using the edit menu or whatever to do the analogous thing); sometimes, the "clipboard" that stuff is copied to can be used vice-versa between the two, other times it can't - so you can sometimes do a highlight then "ctrl-c" then position your mouse elsewhere and "middle click" to dump it. Or - you can "highlight" then "ctrl-v" elsewhere to paste the highlight. Other times, you'll find that doesn't work. And in a few cases, you'll find you can't copy/paste something to save your life, and you have to get really creative (typically by using a "third-party" application - like some text editor - that both other apps recognize).

Welcome to the "wild west" of Linux (it's being tamed really slowly - but I wouldn't have it any other way - if I wanted ease of use, compatibility, etc - you know, the boring stuff in life - I'd just use Windows or a Mac)...



Lastly - keep playing and learning the commands; even given what I said above, you still managed to learn a few things. I found that keeping a notebook (one of those black and white composition books, or whatever you think works) was really helpful (and something I still refer to on occasion) - especially for obscure tasks (you can write on a "single line" mini shell programs that can accomplish quite a lot of work - these can be difficult to remember, so when I set one up particularly useful, I write it down for later).