Um, was this really worth an "Ask/."? I'm I just a pompus Linux head, or couldn't this have been answered with a few minutes of googling on the part of the poster? It isn't like this is this the 20th century any more.
While many posters have already pointed out that it COSTS MONEY to produce reasonable docs, the other cost is support. Sure as hell if a device company produces docs for a part, some kid is going to call their support lines to ask about some oddness that really doesn't matter, because that kid doesn't work for Dell and therefore doesn't represent tens (if not hundreds) of thousands of units in sales.
When the number of device driver writers for your part numbers in single digits, you don't need super great docs. When you try to write good docs, the next thing people will complain about is the quality of the docs!
Start from where you are - software - and take baby steps. Start with a Basic Stamp microcontroller board, you can get them from Digikey. Now add peripherals that light up LEDs, cause interrupts from push buttons, then on to driving LCD displays or scanning a keyboard matrix. Then go on to D/A controllers for sounc, PWM for motors or servos, and you are on your way to hardware uber geekdom.
No one really gives a, um, care, about what your degree is in when you are already an IT guy, just that you have enough backbone to finish something you start.
If, however, you are interested in the coursework, then by all means do it.
Last time I tried gcj, back around 3.2, is was slow as mollases compared to hot spot, which really surprised me since it's native code. Is the performance any better now?
Regression testing can be very handy as long as the tests reflect what the code is supposed to do.
Looking at the code to see what it is supposed to do is silly. Just because code does something doesn't mean it is supposed to. What if it segfaults for some input? Was it supposed too? I've seen code that was supposed to seg fault!
You are so screwed. Writing tests for untested code is a thankless job. You are going to find so many bugs, and everyone is going to get really pissed off about that new hire that is rocking the boat complaining about "quality problems".
You are in a no win situation. They will tell you your tests are too picky, that no one will use it like that. Unit testing is thankless, you can't argue. Given that there was no test plan, I bet there isn't even a spec! Where there is smoke there is fire.
Thank you for the blessed menuconfig. Gosh. Really.
Menuconfig is just the window to the maze that is the kernel ifdefs. You have no idea of the size or speed impacts of the options you through if the help doesn't tell you. You have no idea of the component interactions.
Menuconfig is just a parking place for problems. The real problem is too many options, and not enough testing of the combinations. That is what CA is complaining about.
How big is YOUR kernel? Is it under a meg? Why should you care? Well how big is your cache?
The more code in the kernel source tree, the harder it is to test. The more code linked into any single kernel, the less reliable. Hooks in the kernel that can't be ifdef'd out for drivers you don't have linked (or loaded) in serve only to provide opportunities for the kernel to crash.
Have all you people who are dismissing this guys comments personally reviewed the kernel to make sure it matches your biased view of what the theory is?
"Premature optimization is the root of all evil" -- C.A.R. Hoare
"This mission is too important to allow you to jeopardize it." -- HAL
Seriously, why would you waste your time obfuscating your code when you don't have too? Unless you know through profiling that detailed statement level code is bad then you are shooting yourself in the foot.
This isn't to say that when making architecture level decisions that you shouldn't optimize. O(N^2) is bad, Um'Kay? O(N) is alright for small N, but O(log N) is better when you know you'll have a significant N. That's the stuff a compiler can't do for you today.
Once you've profiled, and you know something is critical and can be done better and matters, then start obfuscating. There is a lot you can do in C to optimize, especially with DSP codes, so resorting to ASM should only be done for the most extreme cases.
Slashdot Mirror
Um, was this really worth an "Ask /."? I'm I just a pompus Linux head, or couldn't this have been answered with a few minutes of googling on the part of the poster? It isn't like this is this the 20th century any more.
When the number of device driver writers for your part numbers in single digits, you don't need super great docs. When you try to write good docs, the next thing people will complain about is the quality of the docs!
Start from where you are - software - and take baby steps. Start with a Basic Stamp microcontroller board, you can get them from Digikey. Now add peripherals that light up LEDs, cause interrupts from push buttons, then on to driving LCD displays or scanning a keyboard matrix. Then go on to D/A controllers for sounc, PWM for motors or servos, and you are on your way to hardware uber geekdom.
And how often and why do you change resolution? Full screen prOn vids?
I'd never get a debit card! A Visa hose for a clerk at a store to steal? Jeez, you asked for it.
Don't get me wrong. I like getting accumulated too, but I think the author and editor should wait until after they post before they start at it.
If, however, you are interested in the coursework, then by all means do it.
Except when the CD is in the drive and it asks for the number ...
Or when the BSA comes in for an audit ...
Last time I tried gcj, back around 3.2, is was slow as mollases compared to hot spot, which really surprised me since it's native code. Is the performance any better now?
You are so screwed. Writing tests for untested code is a thankless job. You are going to find so many bugs, and everyone is going to get really pissed off about that new hire that is rocking the boat complaining about "quality problems".
You are in a no win situation. They will tell you your tests are too picky, that no one will use it like that. Unit testing is thankless, you can't argue. Given that there was no test plan, I bet there isn't even a spec! Where there is smoke there is fire.
I'd start looking for a new job right away.
If you are facile with Java, or your data is already in a javax.swing.table.TableModel, then I suggest JFreeChart.
Menuconfig is just the window to the maze that is the kernel ifdefs. You have no idea of the size or speed impacts of the options you through if the help doesn't tell you. You have no idea of the component interactions.
Menuconfig is just a parking place for problems. The real problem is too many options, and not enough testing of the combinations. That is what CA is complaining about.
The more code in the kernel source tree, the harder it is to test. The more code linked into any single kernel, the less reliable. Hooks in the kernel that can't be ifdef'd out for drivers you don't have linked (or loaded) in serve only to provide opportunities for the kernel to crash.
Have all you people who are dismissing this guys comments personally reviewed the kernel to make sure it matches your biased view of what the theory is?
This needs an Insightful mod. Where are my moderator points when I need them?
How about hiring PEOPLE to do this?
"This mission is too important to allow you to jeopardize it." -- HAL
Seriously, why would you waste your time obfuscating your code when you don't have too? Unless you know through profiling that detailed statement level code is bad then you are shooting yourself in the foot.
This isn't to say that when making architecture level decisions that you shouldn't optimize. O(N^2) is bad, Um'Kay? O(N) is alright for small N, but O(log N) is better when you know you'll have a significant N. That's the stuff a compiler can't do for you today.
Once you've profiled, and you know something is critical and can be done better and matters, then start obfuscating. There is a lot you can do in C to optimize, especially with DSP codes, so resorting to ASM should only be done for the most extreme cases.
Booooring.
- Hal