Linux nooB

[AtomSoft]

Hey everyone i am on a linux box right now. Finally getting into it. It isnt as hard as some people think. I just think the documentation isnt all that good. I am using a debian type called Crunchbang which is cool and minimalistic i guess.

I wrote a simple hello world program i would love it if someone could test it to see if it works on other linux boxes or a windows cygwin pc... (even tho im about to test that out myself also)

But would love a tester... I plan to make cool apps in linux using QT once i get used to it all. For this example i used Netbeans IDE with GCC/G++ and it works on my box so far... but heh you never know.

Please post error or comments here. Thanks a ton!

 

[AtomSoft]

Im on windows pc right now. doesnt work in cygwin but i think i need to create a package or something ... not sure hence the nooB portion.

im looking into some info here: https://www.ibm.com/developerworks/linux/library/l-debpkg/index.html

Hopefully it will help me on the way.

 

[AtomSoft]

Not sure if its different but here is a package built with netbeans

I extracted it and zipped it for here.

 

[cr0sh]

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!).

 

[AtomSoft]

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

But since its basically debian, i heard debian is nice. So i chose it. 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 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

Any more tips? Thanks again for that post !

 

[cr0sh]

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).

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...?).

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).

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...

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!

 

[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!

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
what is the "./" for? I know i have to use it otherwise i get a command not found. I have this great book for C/C++/C#. I paid $70 i think when it first was released. Its like over 1000 pages and huge heh...

My Book: Jamsa's C/C++/C# Programmer's Bible [Paperback] - https://www.amazon.com/Jamsas-Progr...=sr_1_1?s=books&ie=UTF8&qid=1325432753&sr=1-1

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

 

[AtomSoft]

Yay "man" is so cool, i googled how to output to a file and wow its awesome!

Here is a man of ls:

LS(1)				      User Commands				   LS(1)



NAME
       ls - list directory contents

SYNOPSIS
       ls [OPTION]... [FILE]...

DESCRIPTION
       List  information  about  the  FILEs  (the  current  directory by default).  Sort
       entries alphabetically if none of -cftuvSUX nor --sort.

       Mandatory arguments to long options are mandatory for short options too.

       -a, --all
	      do not ignore entries starting with .

       -A, --almost-all
	      do not list implied . and ..

       --author
	      with -l, print the author of each file

       -b, --escape
	      print C-style escapes for nongraphic characters

       --block-size=SIZE
	      use SIZE-byte blocks.  See SIZE format below

       -B, --ignore-backups
	      do not list implied entries ending with ~

       -c     with -lt: sort by, and show, ctime (time of last modification of file sta‐
	      tus  information)  with -l: show ctime and sort by name otherwise: sort by
	      ctime

       -C     list entries by columns

       --color[=WHEN]
	      colorize the output.  WHEN defaults to  `always'	or  can  be  `never'  or
	      `auto'.  More info below

       -d, --directory
	      list  directory  entries	instead of contents, and do not dereference sym‐
	      bolic links

       -D, --dired
	      generate output designed for Emacs' dired mode

       -f     do not sort, enable -aU, disable -ls --color

       -F, --classify
	      append indicator (one of */=>@|) to entries

       --file-type
	      likewise, except do not append `*'

       --format=WORD
	      across -x, commas -m, horizontal -x, long -l,  single-column  -1,  verbose
	      -l, vertical -C

       --full-time
	      like -l --time-style=full-iso

       -g     like -l, but do not list owner

       --group-directories-first
	      group directories before files.

	      augment  with  a	--sort	option, but any use of --sort=none (-U) disables
	      grouping

       -G, --no-group
	      in a long listing, don't print group names

       -h, --human-readable
	      with -l, print sizes in human readable format (e.g., 1K 234M 2G)

       --si   likewise, but use powers of 1000 not 1024

       -H, --dereference-command-line
	      follow symbolic links listed on the command line

       --dereference-command-line-symlink-to-dir
	      follow each command line symbolic link that points to a directory

       --hide=PATTERN
	      do not list implied entries matching shell PATTERN (overridden  by  -a  or
	      -A)

       --indicator-style=WORD
	      append  indicator  with  style  WORD to entry names: none (default), slash
	      (-p), file-type (--file-type), classify (-F)

       -i, --inode
	      print the index number of each file

       -I, --ignore=PATTERN
	      do not list implied entries matching shell PATTERN

       -k     like --block-size=1K

       -l     use a long listing format

       -L, --dereference
	      when showing file information for a symbolic link,  show	information  for
	      the file the link references rather than for the link itself

       -m     fill width with a comma separated list of entries

       -n, --numeric-uid-gid
	      like -l, but list numeric user and group IDs

       -N, --literal
	      print raw entry names (don't treat e.g. control characters specially)

       -o     like -l, but do not list group information

       -p, --indicator-style=slash
	      append / indicator to directories

       -q, --hide-control-chars
	      print ? instead of non graphic characters

       --show-control-chars
	      show non graphic characters as-is (default unless program is `ls' and out‐
	      put is a terminal)

       -Q, --quote-name
	      enclose entry names in double quotes

       --quoting-style=WORD
	      use  quoting  style  WORD  for  entry  names:  literal,	locale,   shell,
	      shell-always, c, escape

       -r, --reverse
	      reverse order while sorting

       -R, --recursive
	      list subdirectories recursively

       -s, --size
	      print the allocated size of each file, in blocks

       -S     sort by file size

       --sort=WORD
	      sort  by	WORD  instead  of name: none -U, extension -X, size -S, time -t,
	      version -v

       --time=WORD
	      with -l, show time as WORD instead of modification time: atime -u,  access
	      -u,  use	-u,  ctime  -c,  or status -c; use specified time as sort key if
	      --sort=time

       --time-style=STYLE
	      with -l, show times using style STYLE: full-iso,	long-iso,  iso,  locale,
	      +FORMAT.	 FORMAT  is  interpreted  like `date'; if FORMAT is FORMAT1<new‐
	      line>FORMAT2, FORMAT1 applies to non-recent files and  FORMAT2  to  recent
	      files; if STYLE is prefixed with `posix-', STYLE takes effect only outside
	      the POSIX locale

       -t     sort by modification time

       -T, --tabsize=COLS
	      assume tab stops at each COLS instead of 8

       -u     with -lt: sort by, and show, access time with -l:  show  access  time  and
	      sort by name otherwise: sort by access time

       -U     do not sort; list entries in directory order

       -v     natural sort of (version) numbers within text

       -w, --width=COLS
	      assume screen width instead of current value

       -x     list entries by lines instead of by columns

       -X     sort alphabetically by entry extension

       -Z, --context
	      print any SELinux security context of each file

       -1     list one file per line

       --help display this help and exit

       --version
	      output version information and exit

       SIZE  may  be  (or may be an integer optionally followed by) one of following: KB
       1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y.

       Using color to distinguish file types  is  disabled  both  by  default  and  with
       --color=never.  With --color=auto, ls emits color codes only when standard output
       is connected to a terminal.  The LS_COLORS environment variable	can  change  the
       settings.  Use the dircolors command to set it.

   Exit status:
       0      if OK,

       1      if minor problems (e.g., cannot access subdirectory),

       2      if serious trouble (e.g., cannot access command-line argument).

AUTHOR
       Written by Richard M. Stallman and David MacKenzie.

REPORTING BUGS
       Report ls bugs to bug-coreutils@gnu.org
       GNU coreutils home page: <http://www.gnu.org/software/coreutils/>
       General help using GNU software: <http://www.gnu.org/gethelp/>
       Report ls translation bugs to <http://translationproject.org/team/>

COPYRIGHT
       Copyright  © 2010 Free Software Foundation, Inc.  License GPLv3+: GNU GPL version
       3 or later <http://gnu.org/licenses/gpl.html>.
       This is free software: you are free to change and redistribute it.  There  is  NO
       WARRANTY, to the extent permitted by law.

SEE ALSO
       The full documentation for ls is maintained as a Texinfo manual.  If the info and
       ls programs are properly installed at your site, the command

	      info coreutils 'ls invocation'

       should give you access to the complete manual.



GNU coreutils 8.5		       April 2010				   LS(1)

The terminal part is:
man <command> | col -b > filename.txt

Found it here with a brief explanation of what it does/how it works.
**broken link removed**

Also i did a "man" output of "gcc" and man so much info! This helps so much heh. I will try to man everything i get before getting lost and google-ing things

 

[AtomSoft]

I forgot how i did it but i installed some ntfs thing which allows me to access the other harddrives i have including the windows 7 one so now i can add stuff from linux to windows with a copy and paste. Its cool. Ok im off to search for some linux books online and see what i can find in local shops. Usually the thrift shops around the (not racist) white neighborhoods, sell books like these. I bought a A+ Certification for 1998 for $2 (BRAND NEW SEALED) lol its 2 hard cover books. im suprised thats the actual price for these things now. It used to cost $100 for this... even amazon has it for $2

https://www.amazon.com/A-Certificat...3805/ref=sr_1_1?ie=UTF8&qid=1325436151&sr=8-1

While it is older its still usefull. It will help me teach my mother more about computers

 

[cr0sh]

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!

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).

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).

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).

 

[AtomSoft]

Dude this is great info. I totally understand the ./ now makes tons of sense heh, Ill use it as i dont intend on editing the path just for that. its only 2 characters and helps my typing skills also
I will try to avoid the tar/zip packages but these days everything is in them heh... You say use a package manager..

Crunchbang includes Synaptic Package Manager which is pretty cool. So if im right... if i find a program on the web that looks interesting i should check to see if its there first and if so install from there if not find the tar/zip from the company site right?

I will get me one of those notebooks. I like them since they limit me unlike a binder where i will tend to stuff crap in it. They are also cheap about $1 each so i can afford it I havent found a book that cought my eye yet but im still looking. Perhaps something i can download on Amazon or something will be a good start..., (Im lazy right now and dont want to leave my house)...

Im also surprised i accomplished anything on linux at all So much i didnt know. At first this was a windows machine, (win 7) which im using now... and i shrunk the volume by 100GB (its a 1TB drive) , then i installed linux on that 100GB portion. (i made sure i had a ton of space), Took me 3 days to figure out how to edit GRUB to boot me back into windows. Mainly because i have 3 hard drives and windows isnt on the first one. Its on the second one. on partition 2... so i had to add something weird to specify the HARDDRIVE and PARTITION windows was on. It was a hassle but i can now dual boot 100% no problem.

It taught me a ton on linux like how the hard drives are named and referenced and stuff

 

[cr0sh]

Dude this is great info. I totally understand the ./ now makes tons of sense heh, Ill use it as i dont intend on editing the path just for that. its only 2 characters and helps my typing skills also
I will try to avoid the tar/zip packages but these days everything is in them heh... You say use a package manager..

Well - a lot of developmental stuff is in them (and there's some cool stuff in that arena), but most "common" tools and applications should be available as standard rpm or deb packages (unless they are so new that they haven't been sucked into the distro - but then, that would mean they aren't "common"). You'll probably find your dev stuff for ARM development and other embedded stuff -not- to be in such packages, because it is a niche area (ie, not everybody is doing it or wants to do it, for obvious reasons). You'll just have to keep track of things (hopefully the developers of such have done things right, and put things in fairly common but separate shared or local areas - it only becomes an issue when things are strewn all over the place in /usr - if it stays fairly local, it shouldn't be much of an issue). Once again, the best thing in these cases would be to get familiar with the various package systems and conversion tools; I've used the conversion tools a couple of times (playing, mainly), and they can be a bit finicky, but they do work mostly.

Crunchbang includes Synaptic Package Manager which is pretty cool. So if im right... if i find a program on the web that looks interesting i should check to see if its there first and if so install from there if not find the tar/zip from the company site right?

Pretty much; you might also look around and see if anyone has converted the tar/zip to a package (sometimes people do this to make it easier for others). The only time you should deal with tar/zip is if a) you have no other choice, or b) you need the upgraded package for some obscure or necessary reason (very possible, again, in the embedded dev world - from my understanding - lots of churn there).

The best thing to do in these cases would be to keep the extracted contents around in a common area after install (or at least keep the tar/zip files handy) - so you can reference them later if you have to uninstall one or more. If you look at what they had installed (via whatever "makefile" system they used), and you see any .so (shared object libs - similar to dll files in the windows world) or .o (regular object libs) that were installed, you can "grep" around the other files to see if they included similar or used similar, so you only blow away/clean up those you don't need (or if you upgrade, you don't overwrite something that was depended on by another package, etc). You basically end up being the "package management software" - doing all the tasks it does (not easy or fun - you'll invariably will screw up, unfortunately - it can drive you mad, sometimes).

I will get me one of those notebooks. I like them since they limit me unlike a binder where i will tend to stuff crap in it. They are also cheap about $1 each so i can afford it I havent found a book that cought my eye yet but im still looking. Perhaps something i can download on Amazon or something will be a good start..., (Im lazy right now and dont want to leave my house)...

You might want to get more than one - use one for "commands", another for "scripts", another for "setup" (ie, things like networking info, hardware notes, etc), etc - they are cheap, but decide on an organizational structure early. Or - if you are disciplined enough - you might just set up a few text files on a drive and use those.

One other thing: If you are planning on doing heavy development work (more than just playing) - look into setting up Subversion or CVS locally; these are both common versioning repository systems (unless you already use something like github or such on the web, of course); you could also put your notes into one of these as well, to keep track of changes over time...

Im also surprised i accomplished anything on linux at all So much i didnt know. At first this was a windows machine, (win 7) which im using now... and i shrunk the volume by 100GB (its a 1TB drive) , then i installed linux on that 100GB portion. (i made sure i had a ton of space), Took me 3 days to figure out how to edit GRUB to boot me back into windows. Mainly because i have 3 hard drives and windows isnt on the first one. Its on the second one. on partition 2... so i had to add something weird to specify the HARDDRIVE and PARTITION windows was on. It was a hassle but i can now dual boot 100% no problem. It taught me a ton on linux like how the hard drives are named and referenced and stuff

Hey, if you're already doing that (and the ntfs thing, too) - you're well on your way to getting a handle on things; I've never actually set up a dual boot system, because I dropped 'doze early on like a hot potato. I have no doubt that I could set it up, but it can be a chore, but it seems like you've managed it. Most people haven't got a clue on it. It's a great way to learn things system-wise.

Another thing to keep in mind (if you haven't noticed already) - everything in *nix land is a file; it's just how Unix originally was designed, and it makes some things really easy to do (and really easy to screw up, I might add). So all devices (see /dev) are described by the filesystem; learning how to set up device drivers/modules etc (look into the "lsmod" and "modprobe" commands) will be another thing you'll want to dive into (although even there, with the udev system and others, depending on the distro, have made this almost painless); you'll need to know this stuff, though, I'm sure for embedded development, so get familiar with it.

It sounds like you are well on your way to becoming an expert! Just keep googling and learning, you'll get there (and if your like me, you'll wonder when that happened - believe me, I've been describing this all to you, knowing there is a ton of other stuff I have left out simply because there is so much, and wondering to myself "where did I pick up all this crap?")...

 

[AtomSoft]

Heh like that say one mans trash (CRAP) is another mans treasure I saw this awesome 3 pack on amazon which seems like it will get me going without having to bother you or someone else all the time... it includes

Understanding the Linux Kernel, Linux Device Drivers and Linux Kernel Development all 3rd editions heh for $97 which is a ton of cash to me but im sure will be very useful so time to save money.

I understand what you mean about the tar situation. Uninstalling can create issues if i have to do it manually... so ill try my best to stick to packages and/or learn how to create a package from a tar so i can uninstall things easy. Ill get me a few books to write in. I rather keep some things on paper mainly because im sure ill screw something up to a point where i cant access the files and poof all is lost heh. Unless i keep it on a flash drive i have here. Not sure yet but i think i might use the flash drive instead since my hand writing can confuse even me

Ok one more thing... when trying to learn all this linux stuff can i refer to it as Unix as well? Or will i run into problems? Linux is based off Unix right? I guess i should do some history research as well.

Thanks yet again for these post man you have no clue how much all of this helps. If you ever need anything just ask dude. I own AtomSoftTech.com/store as well so if you plan on getting something just tell me ill send you a nice coupon for some savings ok.

 

[cr0sh]

Heh like that say one mans trash (CRAP) is another mans treasure I saw this awesome 3 pack on amazon which seems like it will get me going without having to bother you or someone else all the time... it includes

Understanding the Linux Kernel, Linux Device Drivers and Linux Kernel Development all 3rd editions heh for $97 which is a ton of cash to me but im sure will be very useful so time to save money.

Well - those books sound pretty great for hardware development or other low-level stuff; they'll probably come in handy for the embedded work (if you are doing embedded linux on ARM or something similar, that is).

If you want something more general, go with just about anything from O'Reilly (http://oreilly.com/linux/index.html); they also have a ton of good stuff for other platforms (and development, and other things). Also check out their online book portal: **broken link removed**

I understand what you mean about the tar situation. Uninstalling can create issues if i have to do it manually... so ill try my best to stick to packages and/or learn how to create a package from a tar so i can uninstall things easy. Ill get me a few books to write in. I rather keep some things on paper mainly because im sure ill screw something up to a point where i cant access the files and poof all is lost heh. Unless i keep it on a flash drive i have here. Not sure yet but i think i might use the flash drive instead since my hand writing can confuse even me

One thing about paper that is difficult to replicate using an editor or other means is the fact that you can draw (diagrams and other similar notes); depending on your style, this can be a frustrating thing in a purely digital form...

Ok one more thing... when trying to learn all this linux stuff can i refer to it as Unix as well? Or will i run into problems? Linux is based off Unix right? I guess i should do some history research as well.

Linux isn't Unix - Unix is a whole 'nother beast; Linux shares some traits with Unix, and they are both POSIX compliant. BSD (another free and open-source Unix-like OS - it's what Mac OS is based on) is closer to Unix than Linux. Ultimately, the main thing they share is called "POSIX-compliance". Do some research on all of these terms on Wikipedia and such, and you'll get a better understanding.

Ultimately, you shouldn't refer to Linux as "Unix" - it isn't the same thing. You can informally group all of the Unix-like operating systems (which would include today's Mac OS, too remember) under the colloquial term "*nix" - but when you need to be specific to Linux - use "Linux" (and/or the distro you are looking for, if that specificity is needed).

Thanks yet again for these post man you have no clue how much all of this helps. If you ever need anything just ask dude. I own AtomSoftTech.com/store as well so if you plan on getting something just tell me ill send you a nice coupon for some savings ok.

Yeah, I know - that's why it surprised me a bit to see you getting into it (certain people on this list and others; well, I feel I know them a little, just from our interactions and posts); I think its great that you are pursuing it, and even if it doesn't work out (but it sounds like it is!), you'll learn things that can be applied elsewhere, likely. Thank you for the offer; I don't know if I'll ever take you up on it, but I might. Just knowing I've helped you (and maybe some others?) is enough for me, ultimately.

Let me know how things work out on the embedded dev work; that's always been something I've thought about doing, but I've never had a real reason to yet (just about anything I do that could be called "embedded" has lately been using the Arduino and its tools - which do, at the low level, share things with ARM and Atmel embedded development).

 

[AtomSoft]

Im looking at there site now for books. That Linux in a Nutshell looks cool to start with.
Yeah with paper i can draw... hm... ill have to consider which one would be best for me or somehow merge the 2 Like leave a digital note that its in BOOK1 PAGE 10 or something

Ok Linux isnt Unix i wont mix that up again heh..

Ill be sure to let you know how things work out and ill be sure to put tons of things i learn on my blog too. My blog is http://atomsofttech.com (redirects to atomsoft.wordpress.com) I was having too much trouble moving my original wordpress site over so i kept it and redirected main site to it. Its a small hassle but its cool in case i forget to pay the server fee my site is still up

Thanks once again. Ill be posting some new things today. Hopefully i dont screw something up

 

[AtomSoft]

Ok side question. I have a older MAC here um.. more specific "Quicksilver" Power Mac G4... can i install linux on this ? its too slow using mac software cant even goto flash sites lol so slow... so would that be possible?

 

[AtomSoft]

oops google got me... yeah i can install it. Ill try it in 10 min. Have to get the mac out the closet heh

 

[cr0sh]

Im looking at there site now for books. That Linux in a Nutshell looks cool to start with.

The "nutshell" books are pretty nice to have; something between one of the larger books and the "pocket guides" - they don't do a lot of "hand holding", but still give you enough information that if you are trying to do something new, you can understand how to do it (whereas the pocket guides are very small, succinct - like a pocket guide should be, I guess). You might want to try to get one of each...

Yeah with paper i can draw... hm... ill have to consider which one would be best for me or somehow merge the 2 Like leave a digital note that its in BOOK1 PAGE 10 or something

A cheap scanner might help (try your luck with a goodwill purchase)...

Regarding the mac thing: The only macs where it is somewhat arcane to install Linux on are the PowerPC line of Macs. For those, there is (or was - I've lost track) a distro called "Yellow Dog Linux" (ok - it still exists: http://www.yellowdoglinux.com/). Really, Linux can be installed on just about anything (I just did some googling - there's a few threads of discussion about installing it on a 80186, if you can find one - and I found a thread about Minix on an 8088; maybe there's a use for my old laptop after all!).

 

[cr0sh]

Thread on Minix and 8088:

**broken link removed**

Minix homepage:

https://minix1.woodhull.com/

Minix on an XT and other older systems (!):

https://minix1.woodhull.com/hints.html#small

But you know, all of this isn't really too much of a stretch to imagine. Unix was originally written by Ken Thompson (in 1969) on a PDP-7, which was even more constrained than those systems.

I still own (though it is packed away) my original computer - a TRS-80 Color Computer 2 with 64K of RAM; on it you could use an operating system called OS-9 (by Microware - https://en.wikipedia.org/wiki/Microware), which was a multi-tasking, multi-user OS much like Unix (OS-9 is -not- Unix or POSIX, though); it was ported to a number of CPU platforms. It wouldn't surprise me to see a form of Unix on such an 8-bit system...

 

[AtomSoft]

Wow there are so many OS out there i never heard of heh... its overwhelming and yet cool! That is one old computer, at least back then the computer had the keyboard built in... no need to fiddle with USB and wiring heh.. all in one i suppose... Im trying to install debian on the mac as i type this. Hopefully it will work better than the original mac software