Vampir0 Ner0 wrote:
On Debian, you have to look to find out how to get things working, or
know somebody...
Maybe you're looking in the wrong list. Try amd64 and look if there
isn't VERY experienced people!
The aims of Debian, remember, are not performance, but *stability* and
*security*. So that you're saying about Sid and Gentoo is not
applicable. I also chose Debian for its way of managing packages, surely
the best of all.
Well, let me clarify things. For normal unix/linux task, Debian in
wonderful. If you are working/learning about the intricacies of the
2.6 kernel, Gentoo step you right into the middle of learning,
selecting, and compiling, including your compiler options. These are
things that developers and experienced programmers use routinely, but,
are somewhat less visable in a distro like Debian. In gentoo, they
are listed and discussed, on a basic level, right in the installation
literature.
I do very much agree with the focus on stability and security, but, my
work has taken me into writing 2.6 based device drivers, and
customizing the kernel for openmosix, on portables, servers, and
workstations. This is no sweat in gentoo.
Is there a Debian document that takes one thru the latest 2.6.....
kernel patching choices? The compiling, including compiler settings
and such? I have not looked around (for Debian documentation lately)
but it's quite confusing(especially for newbies) on kernel building,
which depends somewhat on which (woody, sarge, or sid) is in your
installation and the 'utils version' and the kernel based. Since
Gentoo is designed from the bottom up to compile and customize what
you are doing, it very logical for kernel building and is directly
related to porting code to various microprocessors (note, I'm not
really that interested in other peoples code_ports to other
processors, except to learn how they did it and why they made the
choices they made. Often you learn that the low level assembly code,
in the kernel and drivers, is suboptimum. Linux and all unix ports
have this problem. It's mostly because folks that are really good at
embedded systems, i.e. those that write their own state machines, and
to not run to VXworks or MontaVista for schedulers, executive,
primitives, low level drivers, etc) rarily have the time to navigate
the convoluted curve, to learing how the vast system, we call linux,
actually works. I think gentoo, goes a long way to removing the
cob_webs, so that I can focus on learning the low_level internals of
the linux kernel, and how different distros are built on this archtecture.
A embedded developer I know, just developed a FAT file system support,
from scratch, for the Pic 18F family and then ported it to the 5000
series TI dsp. TI told here she could not do it, and should use the
'TI DSP bios' which is not available in sourcecode form. She laughed,
very hard in TI's face. It took her about 2 months, off and on, but
now her small little company, has sourcecode to driver code that is
highly portable. Her biggest problem was the undocumented nature of
the standard(what standard), the devices, and the media issues. It
works on both smart media and CF. This person, eats, shits and
breathes any native assembler, on any processor you can imagine.
What's the learing path for her to finally leave MS and get to the
internals of the Linux systems, without the baggage? I think she could
contribute mightly to the open system arena, but, the path is well
documented. Sure I've got a collection of embedded linux books, but,
the do not seem to have that essence. Gentoo is the best I've seen at
capturing that spirit, because it's a 100% source code build.
Debian is wonderful, but, maybe it needs a 100% sourcecode compile
process option, or at least a document where one could go down that
path to see what/how it was done? When you need new things, such as
H.264, you are forced to use sid. All things equal, there is a ready,
documented path to get to the point of being able to work on any or
all aspects of a linux kernel build, device drivers, or application
porting work,on the gentoo path. Debian sid is less documented, in my
opinion.
Let's face it, most of linux's problems are a result on not being
about to recruit a sufficient talent pool of low level embedded
developers. Most of those that do convert (after a convoluted learning
path) end up at a proprietary shop that puts linux on a processor, and
hides the key low level details.....
I hope this clarifies things, as my frustration in not really a
weakness with Debian, but more of a search to find a conduit to get
these sorts of assembler(and ansi C) wiz's quickly and competently
contributing to the low level driver needs of the larger open source
community. I do recognize that the biggest impediment is the silicon
vendors and their close relationship to the embedded tool vendors. It
things remain obscure and the tools run on MS, it's a proprietary
club. As companies roll out embedded linux and low level details of
their hardware, the are clandestine with many of the necessary
details, and source code snippets.....
In selected hardware areas, such as video hardware/drivers, the
picture is actually quite bleak....
james
