Any ideas on where a possible future hacker could start learn about all this?
gutt...@gmail.com
past couple of months, but it's all way over my head. I have no
experience with linux or testing hardware or pretty much anything thats
being talked about here, but I am genuinely interested in learning
about it. My question to you all is, Where is a good place to start?
Does anyone know of any classes or books or materials I should buy and
just start playing with that would help me.
I'm a pretty quick learner, but I don't think I'd learn quick enough to
have any meaningful input on the OSD. Possibly on future projects
though. It may be a good idea in general to get a list of helpful
things together so other in experienced people who enter the neuros
world have some stepping stones to lead them the right way. MIT has
"open sourced" a bunch of their courses, so it would be cool to pick a
few from there.
Dragon Wisard
Ofcourse, a familiarity with Linux is very important so my recommendation would be to install an easy distrobution like Ubuntu or Mandriva on a spare computer and play around with it. When you start to feel comfortable with that try to install Gentoo. Installing Gentoo and reading the Gentoo Handbook will help learn the structure and internals of the Linux OS. Even if you don't like Gentoo or don't plan on using it, installing Gentoo is a very educational experience. If you run into problems some helpful resources include:
- http://www.linuxquestions.org
- #linuxhelp
- and ofcourse #neuros
Joe Born
> I've been paying some sort of attention to the discussions over the
> past couple of months, but it's all way over my head. I have no
> experience with linux or testing hardware or pretty much anything thats
> being talked about here, but I am genuinely interested in learning
> about it. My question to you all is, Where is a good place to start?
> Does anyone know of any classes or books or materials I should buy and
> just start playing with that would help me.
>
> I'm a pretty quick learner, but I don't think I'd learn quick enough to
> have any meaningful input on the OSD. Possibly on future projects
> though.
I'm glad you wrote this. Actually, this is pretty much my situation,
I'm really just a business guy that's interested in learning this stuff.
I've been an MS-DOS/windows user for 20 years or something and poked
around a little on the Unix machines in college, and had a fortran
course in college, but that's pretty much it.
So basically, I'm teaching myself Linux, C and the OSD all at once. In
some respects it feels like I'm the guy with the yellow rubber duck
inner tube who shows up to the river and asks about tubing to have the
locals point to some white water rapids and say "sure there's tubing
right here!" when I say "gosh fellas! I'm not a very experienced rafter
are you sure it's ok?" they say "sure, no problem, you'll be fine"
The good news is that no one drowns hacking the OSD (although I've
certainly felt like jumping out the window on more than one occasion).
I would love to recruit more folks like you into the fold, and I think
it's attractive for a variety of reasons. Of course, there are tons of
things to hack in the world, but the OSD Situation has some unique
advantages.
*Free Software/Open Source is very powerful movement that touches on
more than just hackers, it really is connected to some basic freedoms
like free speech and the freedom to tinker and invent. see the below
crappy 5 minute video for my pitch on this
http://www.youtube.com/watch?v=Jey8-AjXX1E
This is a very important societal movement that is making a big impact
throughout the world, and the open source hackers are passionate about
it for good reason.
*Hacking an embedded device is cool. This is $200 device that connects
TVs and stereos to the network and the internet. It's a chance to bring
the kind of freedom of communication that exists on the computer to the
living room/bedroom etc. As much as the file sharing networks are
disruptive, the phenomenon of open devices that connect living rooms,
etc is even more so. Imagine a world where TV is not controlled by the
current infrastructure of cable companies, local stations and Hollywood,
pretty powerful stuff
*You can start simple. While it's true that there are a lot of high
level tools (visual basic, etc.) for windows that simplify the creation
of software, that stuff is not appropriate for embedded devices.
However, interesting things can be done with C and like chess, it's
"easy to get started but a lifetime to master." I just wrote a
countdown program that's actually does something useful and it's 16
lines or something, it was the third C program I've written in my life,
and it runs on the OSD.
*The community is working on high level tools for the OSD. I keep
hearing folks talk about Lua, which I know nothing about, but it's some
kind of scripting language that will simplify coding on the OSD. See
http://en.wikipedia.org/wiki/Lua_programming_language
*The Community is great. There are a lot of experienced hackers in this
community, and we need to make sure that we don't alienate them by
subjecting them to endless newbie questions, but I believe that if we
coordinate/segregate the discussions, we can manage it, it can work
well. Some hackers enjoy teaching others, and some don't, with a little
planning we should be able to separate the two adequately.
*It's manufacturer supported. Community patches get included in
finished products, decisions about the hardware and roadmap are made
openly and with community input. We support the community with docs,
free product and even some money (which hopefully will increase over
time-more on that later)
Here's what I'm thinking:
1) I'm putting together some beginner documentation, and I would *love*
to get help. see here http://open.neurostechnology.com/node/335
2) If the above docs don't have enough background, let's provide more.
Part of the deal we need to make with the experienced hackers among us
is to document what we learn along the way. That way we provide a
manual that they (and we) can point to so that they don't have to teach
the same stuff over and over to every person that comes along. In
addition, it's also a great recruiting tool. I'm certain that every day
thousands and thousands of folks around the world hit google to begin
their hacking adventure and if we write articles that hit on their
search terms, we'll attract them to our community.
3) let's setup times on the IRC for lessons. we'll need at least one
experienced embedded hacker to be the teacher and at least one or two of
us students will have to volunteer to document that lesson. You don't
have to be Winston Churchill, just summarize what we learned and the
rest of us will have to make the commitment to clean it up.
4) We need to get a volunteer hacker teacher for each lesson. I've
personally completed two of the lessons, but if there are enough
interested folks, maybe we clean up the documentation and then setup a
time for folks to ask questions about it, etc?
5) We need background material links for the lessons. Can any of you
experienced guys help with that. Take a look at my "lessons" and point
out some links for background. ie. what do you want your students to
read before they show up?
6) we need input on the lessons. First of all I've proposed two
projects and only four lessons. These happen to be two projects that
I'm personally interested in, but I'm up for alternate suggestions, if
there are projects that either the community is more interested in or
are a better project for learning or are something that's less in flux
(given the rapid state the OSD firmware is evolving) then please speak
up.
Finally to answer your question, I personally like books when I'm
starting from scratch on something like this. I'm the subject of a
great deal of riducule for this, but I like a comprehensive listing that
has passed the threshold of completeness/coherency of getting published.
It's also better for reading on the bus, etc. The two main references
that I've used are the classic bible of C programming: Kernighan and
Ritchie "The C Programming Language" and Matthew and Stones "Beginning
Linux Programmming" These layout the landscape for me, for the details,
the web is perfect, usually starting with wikipedia.
I noticed that the author above has an online tutorial, it's pretty old
and I haven't taken it, but it's here
http://www.lysator.liu.se/c/bwk-tutor.html
not sure to what extent I'll be the subject of ridicule for this, but I
found the below helpful too http://computer.howstuffworks.com/c.htm
Thoughts? Thoughts? Thoughts?
Joe Born
we're not ready for Enlightenment on the OSD, but here's some other
issues." First and foremost among these seemed to be the build
environment. This seems like it should be *the* top priority because it
appears to be a serious impediment to doing anything else on the device.
Given that our current plan is to start aggressively recruiting
developers to the fold on Sept 19th, this seems vitally important.
If anyone can/is willing to help out with this, it would certainly be
deeply appreciated! It's my understanding that this is a task best
suited for the community (relies on toolchain experience more than
access to proprietary information) but if other's don't agree, please
speak up.
Rather than trying to articulate what's wrong with the current build env
(it's still entirely above my head) I'll just reprint Derobert's message
from #neuros.
Complaint no. 1: the is no top-level build script. You must instead
build several things in a certain order, with setting some environment
variables, with directories named in a certain way.
Complaint no. 2: I've written a top-level shell script. It's 118 lines.
There is no excuse for it to be more than './configure \n make \n make
install'
Complaint no. 3: There is no good way to add in your own software....
e.g., if I want to add in ntp, there is no good way to do that. Instead,
I get to configure NTP separately and then add it to my build script.
Complaint no. 4: 'make' can not be trusted to actually rebuild
everything when source files change. For example, busybox was not
properly redone when enabled NFS in it a while back. make clean is
required to be sure.
Complaint no. 5: 'make clean' doesn't work fully. It leaves cruft
around. Try make clean followed by svn status; look at all the ? files
Complaint no. 6: It is difficult to build standard software. Look at the
trouble rasterman (hi!) had building EFL.
Complaint no. 7: There are GPL'd binaries (gcc) in the svn repository
without corresponding source, much less with build scripts to rebuild
them. I don't think this is even legal.
Complaint no. 8: Documentation? We don't need no stinkin'
documentation!
Complaint no. 9: uses 'sudo' in the build process. (This is #9 not #1
because I've patched around it....)
Pat Gunn
>without corresponding source, much less with build scripts to rebuild
>them. I don't think this is even legal.
I believe that this is not legally questionable -- so long as the GPL
text itself is available, and you will provide the sources to the
binaries on request, you're ok. Distributing the sources in the kit
is an optional thing that some projects like this do for convenience,
not a legal requirement.
IANAL, but this is my understanding.
---
Pat Gunn
mod: csna, bmcm, bmco, cooa, cona, clpd, coom
http://dachte.org
"It is a sign of high arrogance to quote oneself"
-- Pat Gunn
Anthony DeRobertis
>
> I believe that [not distributing sources] is not legally questionable -- so long as the GPL
> text itself is available, and you will provide the sources to the
> binaries on request, you're ok. Distributing the sources in the kit
> is an optional thing that some projects like this do for convenience,
> not a legal requirement.
No, that's not right. Read over GPL Section 3. Section 3 allows you to
distribute "in object code or executable form ... provided that you
also do one of the following". There are three options; of those
three, only (a) and (b) could potentially apply.
(a) is to "[a]ccompany it with the complete corresponding
machine-readable source code...". Clearly, we're not doing this.
(b) is to "Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your cost of
physically performing source distribution, a complete machine-readable
copy of the corresponding source code...". I don't believe this is
being done, either.
(c), if you're wondering, is only valid for non-commercial
distribution and is to include someone else's (b) notice.
HTH
Steven Robertson
typical "Ten Commandments" style of writing email, so I'll just throw
out a couple things:
* What if we created a stable (~3mos. between releases) development
"platform", containing a kernel and base system (including ARM-native
toolchain, headers, etc.), designed to be booted off of a CF card? I
think that requiring developers to get a 256M card is far less of an
impediment to most than requiring them to set up a TFTP and NFS
server. This would resolve 4, 5, 6, 7, and 9.
* On top of that, we could use GAR to easily create an intelligent
build manager, and provide a path to add new applications. Resolves 1,
2, and 3. (GAR is a ports work-alike, but is somewhat lighter to
maintain and is more appropriate than many alternatives.)
* With a stable platform in place ("platform" here meaning developer
image along with an x86-native ARM toolchain for cross-compiling), it
would not be hard to use a tool like Scratchbox, so that whether you
were on PC or ARM, you would have an identical environment for
development stuff.
I want to emphasize the importance of one thing, even if nothing else
here works: we should *not* have developers construct their own
environment. Not only does this run the risk of binary
incompatibility, but it scares developers off.
I will have a more complete explanation... uh... sometime, but I think
those tools are well-documented enough that simply going to their
websites will give you a clear idea of what's going on.
HTH
Steven
Vladimir Pantelic
> I had a big long spiel, but I couldn't adequately condense it into my
> typical "Ten Commandments" style of writing email, so I'll just throw
> out a couple things:
>
> * What if we created a stable (~3mos. between releases) development
> "platform", containing a kernel and base system (including ARM-native
> toolchain, headers, etc.), designed to be booted off of a CF card? I
Well, having to use the compiler ON the target would scare me off,
how would I get the source edited, using vi over RS232?
Dragon Wisard
Anthony DeRobertis
> * What if we created a stable (~3mos. between releases) development
> "platform", containing a kernel and base system (including ARM-native
> toolchain, headers, etc.), designed to be booted off of a CF card? I
> think that requiring developers to get a 256M card is far less of an
> impediment to most than requiring them to set up a TFTP and NFS
> server. This would resolve 4, 5, 6, 7, and 9.
This doesn't resolve 4, 5, 7, or 9. It may make it so fewer users have
to deal with them, but it doesn't solve them.
It does somewhat solve 6.... by compiling on the OSD. Well, not
actually, because you'd need a much more than 256MB flash card to
actually hold all the source and object code as well as the complete
toolchain.
#9 will be mostly solved once I finish up my fakeroot patch and get it accepted.
>
> * On top of that, we could use GAR to easily create an intelligent
> build manager, and provide a path to add new applications. Resolves 1,
> 2, and 3. (GAR is a ports work-alike, but is somewhat lighter to
> maintain and is more appropriate than many alternatives.)
There are several existing systems we could use. And yes, thankfully,
they solve many of the problems I listed.
> I want to emphasize the importance of one thing, even if nothing else
> here works: we should *not* have developers construct their own
> environment. Not only does this run the risk of binary
> incompatibility, but it scares developers off.
While most developers probably won't want to build GCC & binutils from
source, some will. And it should be fairly easy to do. If someone
wants to build from their PowerPC box, they shouldn't have a hard time
creating the cross-compiler. Ideally, not much harder than typing
'make'.
joe...@gmail.com
learning more to attend Thursday's IRC meeting. We have a web client,
so you just need a web browser to participate...
Joe McHugh
start learning any of the things I wanted to learn yet though. Thanks
to everyone who threw out some ideas.