there is some of the subject of programming (I'm actually going to cheat a bit here and assume that its actually progamming and computer architecture and systems analysis that is at issue here, because you don't just want to write the assembler instructions that fullfil the requirements for a tightly-specified spec for a subroutine) that is language independant and some that are language dependant.

The bigger part is normally language-independant, and you are not directly asking about that/those. If you regard the language-dependant part as a 'plug-in', then, for someone who already has a robust toolbox for approaching computer programming issues, it shouldn't be a massive leap to be able to cope with a new 'plug-in'.

That said, there is no guarantee that you will like any new programming language that you can come across. Some you will probably hate, while still being able to write programs in them.

I can't even see how it could. Well, unless you were staggeringly small-minded.

I am not sure why you are concentrating on assembler.

This is very far from necessarily true. One of the best (my qualitative judgement) programmers that I ever knew, and I have known a few, wasn't the smartest guy, but he was the best organised. He had a method that worked for him and applied it relentlessly to any problem that he came across. He turned out good quality code and he turned it out on time and well commented (well, unless management really made strong efforts to stop him, which happened at times).

Of course, you could also say that this 'having a method' thing was smartness, but it wouldn't get you many points in an IQ test.

That said, I can't see you getting very far if you don't understand logic.

There is no resource which is going to be 'just add water, and become an expert'.

These people who write the kernel mostly don't write assembler (in fact, assembler is regarded as a last resort, only to be used when other, more easily portable, solutions are for some reason, impossible, or not advantageous) and they are really the expert's experts.

Everyone starts with 'hello world' programs and builds up, adding new techniques and tricks in small amounts and gradually get there. Malcolm Gladwell, in one of his books, came up with the number of 10,000 hours being what a head-of-the-field in any field needs to put in. Of course, to really get to the pinnacle, and not just a moderate level of competence you need to be putting in that 10,000 hours on top of talent and not all of us would even aspire to being the Beethoven of code (whatever that means), but just reading a 'How to do Assembler in a Week' book isn't going to get you all the way there, all on its own.

Yes and no. there is a mass of useful information on the 'net, but there is also an even bigger mass of rubbish. But for tutorials and the like, if you are finding that the tutorial is taking an approach that seems helpful to you, then that's probably good. Just be aware of the risk that it is making things seem easy because it is oversimplifying...

These are more architecture issues and a book on that would be good to read. look for example at http://www.amazon.co.uk/s/ref=nb_ss_...ecture&x=0&y=0 (I like the patterson ones, but YMMV...by the way that was the Amazon.co.uk page, you probably want the .com).

If you are thinking in terms of a career (or, maybe, a job), for most entry-level posts, you wouldn't need a massive amount of math to do the job - maybe some knowledge of a specialist field, but the person interviewing may feel that a candidate with greater intelligence will learn faster. This is a questionable assumption, but I don't know of any job interviews that test ability to learn, but rather they tend to check out something else and assume that this implies ability to learn.

Well, I was reading IBM's page on the Linux boot process, and looking at some of the assembly in the linux source ... some said copyright Linus Torvalds, rewritten by someone else, etc. ... I've read things saying that a lot of good programmers aren't the best programmers, because the best programmers know assembly. I've read other things, too, but you get the idea.
Mainly why I focus on assembly so much is because I'm trying to think of the fundamentals.
Right now, in my mind, the fundamentals would be hardware/architecture, and machine code or assembly.

I have quite a few books here that I haven't read, yet.

Moved: This thread is more suitable in <General> and has been moved accordingly to help your thread/question get the exposure it deserves.

Not really a Linux issue

I believe learning assembly is as you've said, it shows you the guts. It's how it's really working.

joeBuffer,

As others have said, learn things that may be profitable, see the value in community and sharing knowledge, and find your niche. I'm no senior member or moderator here, but I subscribe to a few of the forum updates and skim through them for stuff that matches my experience, expertise, or interests, and read those - sometimes I learn about something interesting; other times I get to share my knowledge. I am just finishing my undergraduate degree in computer science, straight out of high school, and enjoying the studies, but my Linux experience has been almost exclusively outside of the classroom, with the exception of one operating systems class that actually exposed me to the more inner workings of resource allocation, processor scheduling, and multi-threading; a few programming classes were done in a Linux environment also, but they could have been done in Windows, too.

I would say first to explore, as you seem to have been doing, to find some area that you are interested in; then find some software projects that fit that area and subscribe to their mailing lists and forums and stuff to stay informed, and use them regularly - you will find that in the process of exploring certain solutions on Linux, they will begin to expose you to other essential topics, or require that you learn about other topics. For example, building a project from source will require that you have a good and recent set of build tools (compiler, linker, etc), learn source code management tools to obtain the code and possibly contribute to it down the line, upgrade your kernel by hand, turn your box into a router for your home network, etc.

The value of problem-solving skills cannot be stressed more - it is essential, whether programming, debugging, testing software, or working in IT support positions where rather than modify tools you simply configure and deploy them to perform a regular task, or working in QA and documentation, there are plenty of ways to get involved in Linux and become knowledgeable in an area that interests you. In all of this, however, it will remain necessary to be able to think critically about a discrete logic system, often times with common sense, but with a structured familiarity with the subject at hand.

Welcome to the party!

What makes IT an interesting career (and/or hobby) is that it's an ongoing process, you never stop learning.
If you just want to coast along, it is the wrong industry for you.
So, don't worry about trying to know it all, it's a futile exercise.
Starting with HW and assembler is fine, if that's what works for you.
Read up on Logic (especially Boolean).
There's plenty of free info on the net, just check and compare to make sure you get the good stuff.
In this sort of area (ie technical) Wikipedia is pretty reliable, but do follow some of the references as well.

Last but not least, have fun!

I occasionally still have to use assembly when working on embedded systems, particularly with digital signal processors. Other than that, I haven't programmed in assembly in 20 years.

What programming language(s) do you use, jiml8?

It's very hard for me to decide what is fundamental since I've learned about computers gradually since the first 8080 chips were introduced.

The most frequent problems that people seem to have are these.

• What to do when the OS does not boot
• How to install an additional OS
• Understanding the need to back up files and how to do it
• Knowing what is needed to recover from problems

Computer manufacturers are a big part of the problem because of what they don't provide in the way of information and software. A lot of the time even the standard repair tools on a "retail" OS CD are not included. I've only seen one company (HP) even clearly warn me in the computer materials that I should create the restore discs. Many people never create them and don't know that they need them until they have a problem many years later.

The most fundamental concepts for a computer owner are these.

• Disk partitions
• The boot process in general
• Backing up data
• How to troubleshoot problems
• Where to find information about hardware and software

Computer professionals or software engineers need to know much more information. I'm not sure where to begin with that.

I'm using a Hewlett Packard computer. When I bought it, it came with Windows XP. It also came with a recovery partition. When the computer boots up, when you can press F1 to configure BIOS and Esc to choose what to boot from (CD-ROM, hard disk, etc.), there's an F10 option for system recovery. It reinstalls Windows XP and recovers everything to factory-shipped condition, and even with this being true it bugs you when you start up to make backup CD's with the software it provides, and when it does pop up you can choose to be reminded later or choose to not be reminded again. When you use the recovery partition, it happens again.

I'm reading the book "Programming from the Ground Up" right now, and downloaded "The Art of Assembly" thinking it might be good to read. I don't want to learn HLA, though. I glanced through the book, and it seems complete. I read some of it years ago, but never finished it or got very far into, even.
I still have C in a Nutshell to go through, too. I'm wondering if reading C in a Nutshell is as good an idea as reading other C material and using it as just a reference - but I want to read every bit of it anyways, because it's very full of information and a lot of detail.
Assembly is interesting to me, aside from the fact that it's low level. I know the basics of assembly, already. I really want a very good book that ranges from beginner to intermediate assembly (possibly some advanced topics, too) that uses the GNU assembler and Linux for all examples and details.

I don't think it matters much where you start, as long as you keep going. I learned assembly language long before C because I started out doing 8080 programming. My next project was writing some software in PDP-11 assembly language. Then I wrote Motorola 68000 assembly language and finally learned C. The Kernighan and Ritchie book is a good introduction and tutorial for C and I recommend it even if you want to learn C++ afterward.

You don't need to learn assembly language but it does force you to learn some important concepts that apply to high level languages but are more hidden. One can write good or bad programs in any language.

If you're considering Windows programming then I recommend reading "Programming Windows Fifth Edition" by Charles Petzold. It's one of the few books that covers the Windows API from the ground up. Many others just focus on the latest (and soon to be gone) Microsoft "technology" being pushed onto developers. Everything Microsoft does is built on top of the foundation described by Petzold's book. That book has often allowed me to do things that would have been difficult without its insights.

I can't recommend any good C++ books. I sort of learned C++ by the seat of my pants. I'm by no means an expert C++ programming but I'm slowly improving. I've also discovered that many people using C++ don't understand it well or the advantages and pitfalls of object-oriented program design. Doing anything with Microsoft COM (Component Object Model) will quickly remove the starts from one's eyes about solving every problem using objects. From what little I've seen of Cocoa it appears to be closer to "object heaven" but has its own set of problems.

Read as much code as you can written by other people and try to understand it, what is good about it and what is bad about it. Take ideas that work and refine them and be willing to use different ideas when you write something new. I learned much more from other programmers and their programs than I ever learned from books. And don't accept everything a book says as fact. Some of them have incorrect information, programs that don't work, or are poorly designed. McGraw Hill always had the worst books that way. Read a few books about a language and question what you read if it's inconsistent between authors.

I always laugh when people argue about what is "programming". I don't care if you're writing batch files, FORTH, C++ or assembly language for a micro-controller "stamp". If you are telling the computer what to do or how to do something, make decisions, or perform calculations then you are programming. It seems more productive to focus on helping each other become better programmers than worrying about who belongs in the club. If you identify yourself as a programmer then you're a programmer and there is always more to learn and something you can teach.

Practise maketh perfect my friend ...


linux

gangettan
I've looked around and found no extremely complete reference books or anything of that sort for GNU assembler and Linux. If someone is a master, what reference material would they be using?