What is a good site to learn linux codes and such?

[Kintaro]

Im going to write a book when i finish school. But it most likly will have nothing to do with Computers. (Pholosphy)

[Bazoukas]

quote:Originally posted by void main:


I've actually thought about writing a book, but that thought usually only lasts about 5 seconds and I get side tracked on something else. And I'm lazy. I am pretty sure I could write a better Linux book than most of them out there. As you can tell from this thread, I used to put a lot more effort into my posts. Now I have resorted to just short posts that say nothing more than "FUCK YOU ZOMBIE!!". It's much easier on the brain.

But I really should contribute. There is one area that I think needs a lot of HOWTO work and that is Samba. There is an O'Reilly book on the subject but books get outdated very quickly. I should probably start my own Samba HOWTO and contribute it. The ones that are out there now suck rotten eggs. I think if I were to do it I would write a separate HOWTO for each distribution (or at least have a separate section for each distro). Something for the ultra n00bs that would cover most scenerios. Something that they could just pick a section that would pertain to their precise need and have a step by step process for their precise OS. It would be a large book in itself, not the little puny O'Reilly version. What were we talking about again?

The O'Reilly book is also on line in HTML and PDF format for anyone who is interested:
http://www.oreilly.com/catalog/samba/chapter/book/index.html

[ November 15, 2002: Message edited by: void main ]

  What ticks me off with some books, is their extreme detailed analysis of everything. Dont get me wrong, I understand that the devil is in the details, but a newcomer wants to build his ego. He needs as you said, precise how tos. Then when he sees that its not rocketscience he will get more into it and chase the details.

  Thats why, i hate, i really fucking hate, NO, I MEAN I REALLY HATE, Deitel and Deitel's book on C++. They are yabling yabling their ass off and the material is all over the place, with 20 different colors and not a nice flow to the material taught.

[voidmain]

Yep, that's the way the Samba documentation is. The absolute best resource for up to date Samba configuration information is the SWAT help next to each option (or "man smb.conf"). But none of it does you any good if you don't understand Windows networking, which most people don't, including most MCSEs.

The O'Reilly Samba book is probably the best reading for n00b type of people. But Samba is a moving target (like many open source apps). Features are constantly being added and functionality improved causing the book to be "out of sync" and "out of date". For instance, it doesn't mention Win2k or XP at all. And there are many new important features in the new Samba that are not covered.

[ November 16, 2002: Message edited by: void main ]

[Kintaro]

Anybody should work out smb.conf, its commented out perfectly...

If you have set samba up and it still wont work properly (other computers cant find it) then check the firewall rules and make sure the port is open. At the Installfest this was the problem 99% of the time (about 12 people who had this problem was solved by opening the port.)

[Kintaro]

quote:Originally posted by VoidMain:


This is probably going to be a MUCH longer answer to your question than you were expecting, sorry if that is the case.  Maybe it will help someone...

I'll try and help although I am not sure what you mean by "linux codes".  If you mean programming and you aren't currently familiar with any type of programming it might be best to start with some basic system programming and some comparisons between Win* and *NIX/Linux (assuming you are already familiar with Win*).  Linux comes with many languages ranging from basic shell scripts to C++ and graphical Development environments for KDE ("kdevelop" is similar in many ways to Visual* in MS).

Now on the basic level you have to compare the "shells" between Win* and Linux. A "shell" provides the basic command interpereter and has a number of built in commands. In DOS and all versions of Windows the "shell" is COMMAND.COM.  In NT/2000/XP a more enhanced shell is included called "CMD.EXE".  In *NIX/Linux you are not limited to a single shell like in Win*.  There are several different shells with different built in commands and you pick which shell you want as your default "login shell" (what sort of built in commands and syntax you want available at a shell/command prompt) and all of them provide a heap more functionality than COMMAND.COM and CMD.EXE.  Most Linux distros use "bash" as the default shell although you have many more shells to choose from like "ksh", "csh", "sh", "ash", and on and on.

COMMAND.COM in DOS/Windows has built in commands like "DIR", "ECHO", "FOR", "SET", "GOTO", "PATH" and a few more (but not a large number of internal commands).  Then of course there are all of the external commands included with the OS usually found in C:\DOS, or C:\WINDOWS\COMMAND, etc.

In *NIX/Linux there are similar commands built into each of the shells plus boatloads more, and exponentially more external commands, commands to do just about everything under the sun, commands you don't find in Windows and when you go back to Windows you wish you had them because you might scratch your head for hours trying to figure out how to do something that is a simple one liner in *NIX/Linux and might require a point and click in some graphical utility in Windows (I'll explain why this is significant later in this message).

CMD.EXE in NT and above has more built in commands and is a significant improvement over COMMAND.COM but still far inferior to any of the *NIX/Linux shells.

Now here is where the most basic and easiest programming (or scripting if you will) starts on both Win and *NIX.  In Win you can automate the built in and external commands though a Win* scripting language called "Batch" (or batch files or *.bat files).  This script must run under the interpereter (i.e. shell) COMMAND.COM, or *.cmd files under the CMD.EXE shell.  You can do very rudimentary programming/automating with batch, in fact you can get somewhat creative but are very limited without the addition of other external commands not included with DOS/Windows.

In *NIX/Linux the equivelant to batch is "shell scripts".  Like batch files the shell script must run under one of the shells (bash, ksh, csh, etc).  The script will run under your default login shell if you do not specify in the first line of your script a specific shell that you want to program under.  At least you have a choice.  I prefer the "ksh" (Korn Shell), or "bash" (Bourn Again Shell) for shell scripting.  Some people prefer the "csh" (C Shell) for scripting.  They all have different syntax and it's more or less a preference thing.

Piping, redirection, and job management are far superior in *NIX/Linux over Win and if you learn batch and also learn shell scripts you will very soon see there is no match.

Who needs shell scripts?  Why the heck would I want to automate something?  I don't know about you but I hate repetetive tasks (especially with a mouse), it gives you carpotunnel syndrome, and I DO have a computer that should be capable of doing as much of the work FOR me as possible. That way I have plenty of time to do other things like play golf, fly planes, etc... Microsoft has made it darn near impossible to administer a system or use a system without having to use the mouse in some way or another.  Sure Linux has graphical tools to that allow you to admin/use the system in similar ways to a Win machine but I RARELY use the graphical tools for anything for a few reasons.  

1) It's nearly impossible to automate graphical tools on either platform.  
2) I learned the manual ways before the graphical tools were available (on both Win and *NIX).
3) I can do things faster on the command line than I can with a mouse (at least in *NIX/Linux) believe it or not.
4) The command line way is nearly identical on all *NIX/Linux systems, graphical tools are not, so you have a head start in other *NIX systems if you know the command line way of doing things.

In *NIX/Linux anything you can do with a graphical tool you can do on the command line (and a whole heck of a lot more).  In Win there are many things you can not do on the command line that must be done with a graphical tool which means they can not be automated, at least in batch.  You might have to write a C program to do this which is a lot more work than writing a simple batch file.  It has to be written, compiled, debugged, fixed, debugged, fixed, debugged etc etc. (unless you are really good, then you only have to recompile a few times).

Now it certainly is good to learn C but take baby steps,  start with Batch and Shell scripts, then maybe go to "Perl" scripting on both *NIX and Win*.  Then go to C/C++.  STAY AWAY FROM Visual Basic (or Visual anything if you ask me). Visual Basic is certainly not portable, Visual C is difficult to port, use the freebee GNU C/C++ compiler on both Win* and *NIX/Linux.  I hate proprietary systems, languages, and practices.  Something Microsoft loves and why they have lawsuits against them.

When you get good at batch and shell you will begin to see the light.  You will be very pleased but don't think you are some sort of wizard at this point.  You'll find the more you learn, there will be exponentially more to learn, at least in *NIX.  In Win* you only have a limited amount to learn before you realize it's not really an OS at all, just a wanna be and Microsoft is nothing more than a master at marketing. Ever see that commercial where that guy is surfing the Internet and finishes it?  That's Win*. Where win doesn't end is where they keep putting out the same old crap with a different name so they never find the end of your pocket book.  You never reach the end of the story in *NIX, even if you never upgrade. Of course *NIX had a significant head start and has evolved from the inputs of more than one small company, based on standards and with interoperability being very significant.

Now I've only given you what might be a section of an "intro" chapter to batch and shell scripting.  From here you might want to buy a book ,but I can tell you that usually books are a waste of money. Sometimes you get a good one but I find that is rare. I have shelves full of books that may have only been opened twice and only a few that the covers are worn off.  You might as well save your money and just do some google searches.  Search for something like "shell scripting tutorial" and "batch file tutorial" etc...  You should run accross a wealth of info.  Look around until you find something that is well written and understandable to you.  If it's not, you didn't waste any money, just go to the next one. You'll be on your way in no time!

---
cat /var/run/windows.pid | xargs kill -9

[ December 07, 2001: Message edited by: VoidMain ]

This should all be on the FAQ

[Calum]

it should.

void main, can i have your permission to reproduce this work of art of yours in the FAQ, and on other forums please?

also, re writing a book, you should, however as you say, books aren't often the best way to get tutorials, so maybe you'd be funnelling your energy in the wrong direction.

Anyway, this thread is excellent! i am interested in everything that has been said in here, thanks very very much for reviving it!

also, how can i bring back the dead unix threads? please PM me.

[voidmain]

quote:Originally posted by Calum:
void main, can i have your permission to reproduce this work of art of yours in the FAQ, and on other forums please?

Only if you run it through a spelling and grammar check. I see a few typos and other things in there having read it again.    

Regarding old UNIX threads. I don't know if you can revive any that have been deleted but you can go through them one at a time and see what's there by going to the URL above in your location box and changing the "t=000106". You can see that this thread is thread number 000106 in the *NIX forum. It starts at 000000 and goes all the way up to something like 001300.

[edit]
I forgot, this *used* to be in the *NIX forum as something like thread #3. It was moved to the Programming forum so before changing the numbers in your URL as described above you must start by viewing a thread in the *NIX forum.
[/edit]

[ November 25, 2002: Message edited by: void main ]

[Calum]

good call! okay, no bother. while i expect shell scripting and <shudder> programming to be magical mysticism to me for a good while yet, i am pretty sure of myself when it comes to spelling and grammar checking (on he other hand i hear you have a different kind of spelling and grammar over the water there!    )  

[voidmain]

You wouldn't believe how easy shell scripting is. I remember when you asked about writing HTML for the first time and you picked that right up. I would say shell scripting is just as easy, and more fun.

[Calum]

okleydoke! thanks for the words of encouragement!  

as for resurrecting old threads, does anybody have a list of which ones have been done already?

[beltorak0]

this one is the best I have run across for bash scripting.  it's a ".tar.bz2" html file;
Advanced Bash Scripting Guide.

-t.

[Kintaro]

I run big posts thru AbiWord and correct them, id use Open Office, but its a memory hog. I use abiword if im in a hurry.