AHCI still not working

[w_schmidt at ...181...]

Hi

>To be honest this kind of mindset is what makes developers keep back
>from helping beginners in public forums. It also leads to the wrong
>conclusion that it's not worth the effort to invest time as *those
>people* are lazy anyway and never read documentation.

Not really, it's a problem in the linux world imho.

If you take a look at question and answer sites like stackoverflow you will 
most likely get an answer to things you would think as a beginner question / 
described in a faq.

For example you have a really good documentation from microsoft for c# 
(msdn).
The documentation does not only show methods etc, but also gives examples.
For a lot of people an example is more clear then an abstract description.

On stackoverflow you will find questions like how dictionaries (hashtables 
for the rest of the world) are  used efficiently to get the resulting 
key/value-pairs in some order.
It would be trivial to say: it's unordered, get every element and order them 
for yourself. Or: read the MSDN.
Most likely you will see code for some solutions. You will also get most 
likely an explaination that .net  has specialized dictionaries which can be 
better used for such a task and if somebody has always used something liek 
this you will get an explaination that you should not used 
OrderedDictionary, but SortedDictionary and an example. That is sufficent 
for the beginner to know. (I personally think nobody knows all classes of 
such a huge framework and sometimes you will get a better result if you have 
other people to talk about a problem. Asking a question means to think about 
the problem.
Explaining to others what you want to do is a way to structure a problem. Do 
you know rubber duck codding/debugging? If you have something you don't now 
and you seem to be stuck take a rubber duck. Try to explain to the duck the 
problem you have. In the moment you are beginning to ask the duck a question 
you are forming the question in a way somebody can understand. In this 
process it is likely that you get an answer from yourself. (instead of a 
rubber duck a working student is a good replacement - it doesn't matter if 
the duck/student can't answer the question. You have thought about it and 
then know better what you need. Think about a possible answer. Sometimes you 
see a problem from another site and get a solution. Sometimes you need to 
search further or find somebody with the knowledge.

If you have something like a sourcecontrol system it is not the thing you 
want to focus on. It is nice to know a lot of things about let's say git or 
svn. But it is not the main job. Wading through tons of documentatino for a 
sidetask is not efficent. If you have a larger organization put the task to 
somebody who then can be the reference /oracle which can be asked if 
something needs to be done which is complicated. But normally for most tasks 
a more simple howto can help. For example i have seen 4-5 pages articles in 
magiazines which describe things you need to do an a sourcecontrol system on 
3-5 pages. And it seems to be sufficent for daily work. Not a ton of things 
you never need and forget, but a simplified form for somebody just need 
using it. It's a more practical approach which can be read and adopted in 20 
minutes if you are slow (not heise, itwas something linux specific - heise 
articles only start to explain a problem and in the moment then it starts to 
get interesting - they stop.)

The thing is: most documentations are written by somebody who does not want 
to write a documentation, but needs to do.
No didactical knowledge, just some facts (like throwing some kitchen junk to 
pigs to eat it)
Documentation is a thing which is outdated quite fast.
That is the sole reason why people are wading through documentation - it is 
most likely not written for somebody to learn something fast or get only the 
things to know first. If you look at programming books you have a lot of 
old-style thigns and some which are explicitly written for beginners (e.g. 
Schrödinger lernt XYZ or XYZ Head To Toe). For some people it is better to 
learn somethign which such a book (i don't like them, but they take a modern 
approach using learning theories - somethign you doin't normally find for 
something liek a source control system).
Something like https://rogerdudler.github.io/git-guide/index.de.html will be 
enough for most starters. http://git-scm.com/book/en/v2 is a bit of 
overkill.
If no questions from starters are asked you will not have a feedback whats 
wrong with your documentation. Or where things you need to know are not 
described or linked to descriptions which are sufficent for tasks.

Respect is a two way thing - not onyl going from an asker to somebody asked. 
Many developers think about as not worth answering.

Best regards
Wolfgang