Re: Background developer knowledge
On Mar 24, 2005, at 12:28 PM, T. wrote: Hello What kind of understanding/years of experience/education is really needed to be able to do anything useful with OpenBSD (or any OS in general) source-code? I wouldn't say I'm at the useful stage yet, but... the responses so far seem quite good. Learn C, but stay away from fluffy variants. Coursework is good. Book learning and experience are interchangeable for approximately the first 1-2 years. Beyond that, IMO, extra book learning doesn't buy you much until about the 5th year (when you might hit advanced concepts, mathematical analysis, or designing new things). Crap experience doesn't count for much, either. :-) Good experience is, on the other hand, invaluable. Luckily, there's a lot of good experience buried in the OBSD source. Read it. Take a break when you get a headache, then read it some more until it starts to make sense. A while ago, I read The Design and Implementation of the 4.4 BSD Operating System (McKusick, et. al.) cover-to-cover. I thought it was a fascinating read, and it might give you some good context. For my part, I find that the more you program applications in userland, the more you need to learn about the underlying OS. e.g. the only way to truly learn things like shared memory, threads, locks, etc. is to understand how the underlying OS handles them. The OS exists for one reason and one reason only: to be useful. Understanding its uses is a good way to get a handle on *why* it does what it does. To this end, write applications that take advantage of the underlying OS code WHILE you are learning it. (In this sense, I would view things like routing and PF to be applications, even though they are integrated, in the sense that they are functions beyond simple hardware management.) On the other hand, a background in working with simple systems (embedded RTOS, for example) doesn't hurt either. It might give you some idea of how and why an OS does what it does. Understand the simple, then add complexity until your head explodes. Though ultimately, I think the best way to learn might be: download the source compile (prove to yourself that it works) modify the source fail to compile fix what you've broken Knowing enough to be dangerous is the optimal position to be in for learning, as long as you force yourself to dig your own way out. JMF
Re: Background developer knowledge
On 3/25/2005, Jim Fron [EMAIL PROTECTED] wrote: On Mar 24, 2005, at 12:28 PM, T. wrote: Hello What kind of understanding/years of experience/education is really needed to be able to do anything useful with OpenBSD (or any OS in general) source-code? I wouldn't say I'm at the useful stage yet, but... the responses so far seem quite good. Learn C, but stay away from fluffy variants. Coursework is good. Book learning and experience are interchangeable for approximately the first 1-2 years. Beyond that, IMO, extra book learning doesn't buy you much until about the 5th year (when you might hit advanced concepts, mathematical analysis, or designing new things). Crap experience doesn't count for much, either. :-) Good experience is, on the other hand, invaluable. Luckily, there's a lot of good experience buried in the OBSD source. Read it. Take a break when you get a headache, then read it some more until it starts to make sense. A while ago, I read The Design and Implementation of the 4.4 BSD Operating System (McKusick, et. al.) cover-to-cover. I thought it was a fascinating read, and it might give you some good context. For my part, I find that the more you program applications in userland, the more you need to learn about the underlying OS. e.g. the only way to truly learn things like shared memory, threads, locks, etc. is to understand how the underlying OS handles them. The OS exists for one reason and one reason only: to be useful. Understanding its uses is a good way to get a handle on *why* it does what it does. To this end, write applications that take advantage of the underlying OS code WHILE you are learning it. (In this sense, I would view things like routing and PF to be applications, even though they are integrated, in the sense that they are functions beyond simple hardware management.) On the other hand, a background in working with simple systems (embedded RTOS, for example) doesn't hurt either. It might give you some idea of how and why an OS does what it does. Understand the simple, then add complexity until your head explodes. Though ultimately, I think the best way to learn might be: download the source compile (prove to yourself that it works) modify the source fail to compile fix what you've broken Knowing enough to be dangerous is the optimal position to be in for learning, as long as you force yourself to dig your own way out. JMF -- This email has been verified as Virus free Virus Protection and more available at http://www.plus.net Hi, One of my friends has always said that you can not read the source without context. He is right. If you don't know what your looking for, it will not make any sense. This proves a problem if you have nothing to fix and just wish to learn. Would you not agree? Edd
Re: Background developer knowledge
On Wed, 6 Jul 2005, Edd Barrett wrote: Hi, One of my friends has always said that you can not read the source without context. He is right. If you don't know what your looking for, it will not make any sense. This proves a problem if you have nothing to fix and just wish to learn. Would you not agree? Of course the context of a source file is the program it is part of and the function it is supposed to perform. Now there are a bunch of simple, straightforward commands in any Unix system, which can be used to start learning. Take a simple command. Even yes(1) can be used as an example. Read the man page and try to map the functionality described in the man page to the source you are seeing. While you're at it, check the man page of the functions it uses to accomplish its task. Move on to more complex programs that use more and more library functions and system calls. Study the implementation of the library functions and system calls, now that you know what they are supposed to do and you have seen them used in actual programs. If you have no context, start building it. Of course, reading a few good books might help as well. -Otto
