<div dir="ltr">| What is needed is a common base upon which to build all that diversity.<div><br></div><div>Read:</div><div><div><a href="https://en.wikipedia.org/wiki/Linux_kernel">https://en.wikipedia.org/wiki/Linux_kernel</a><br></div><div><br></div><div>Linus wrote a kernel to help his students and long story short gave it to the world.  The FOSS community adopted it and now we have diversity.  The arguments to reduce this diversification is in error I believe.  There are a wide variety of restaurants that serve the simple purpose of feeding us.  If you had the choice of only 2 or 3 dining out would get old and the joy of dining with friends would soon diminish.  Having used a number of distros and FOSS you can build with the core data segregated and allowing a switch from this to that until you find what you like and/or go to another.  As for the loss of support, your favorite restaurant doesn't stay open forever, doesn't mean you stop going out or don't go looking for a new place.  The joy of discovery is, IMO, part of the charm of Linux. </div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 13, 2017 at 5:54 AM, David Walland <span dir="ltr"><<a href="mailto:davidwalland@googlemail.com" target="_blank">davidwalland@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>I'd love to get stuck in to writing/proof-reading good docs for the Linux community.  I've done this professionally for University Radiation Protection.  This the point; the writer/proof-reader needs to have an encyclopaedic knowledge of the subject and/or experts to correct misapprehensions and rookies to feed back on ease of use.  When I wrote my employer's Radiation Safety "Code of Practice" I had nearly 30 years of experience, starting as a technician and ending as Radiation Protection Adviser.  It still took 2 years to get it checked and double checked.  Even then *one* important issue was overlooked.<br><br></div>This sort of thing is just not trivial, I'm afraid.<br></div></div></div></div></div></blockquote><div> </div><div>Agreed.  Having been an author of sorts myself the monumental effort that goes into writing, esp. a technical manual for end users on a subject which is in constant flux is no easy task.  By the time the first couple of drafts were done it would be in danger of being obsolete. Try to understand the necessity of word choice and document structure as similar to the number of tweaks used in programming to make the software more efficient and the use of resources (memory, processes, etc.) economical.  The devil is in the details.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><br></div>Now I'm, like Joao, a newbie.  I manage to work my way through setting my (old) computers up, often simply following a list of commands, because the discussion as to why you should what is simply above my head!  And of course, right now, following the death of my wife I'm snowed under with work and stressed out of my mind, so trying to read it all up isn't easy even if I can make myself sit down and try to do it.<br></div></div></div></div></blockquote><div> </div><div>My condolences for your loss.</div><div><br></div><div>I am at best anymore a power user.  My introduction to Linux was back in 2005 when I removed all Windows OSs from my consulting business and switched.  Burning the boats as it has been referred forced me to learn as I directed that ALL solutions to our needs would be found or created within Linux/FOSS.  We managed a high 90's percentile in finding solutions for everything within the Linux/FOSS world.  The biggest is just finding the information resources that get you going towards a solution.  I am bad about pulling dated documentation by normal standards to solve issues but they act as good springboards to finding a solution.  </div><div><br></div><div>I have my favs for finding howtos and solutions  i.e. <a href="http://linuxcommand.org">linuxcommand.org</a> for a primer/refresher on cli basics, <a href="http://howtoforge.com">howtoforge.com</a> for a number of solution across a number of distros, <a href="http://www.tldp.org">www.tldp.org</a> for The Linux Documentation Project, <a href="http://stackoverflow.com">stackoverflow.com</a> for the more advance solution just to name a few resources.  The issue then is not so much a lack of effort in this segment of help guides as it is a lack of cohesiveness.  But then again, has anyone tried to navigate the Windows site for solutions?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><br></div>I know a lot of the guys who write the OS and apps feel that we should work to make our own way.  The problem is that many of us just don't have enough knowledge to even ask sensible questions.  We ask what we think are the right questions and then find that there isn't an answer or that it's answering the wrong question.<br></div></div></div></blockquote><div> </div><div>I agree.  Patience is not always apparent in the forums.  The diversification of hardware and issues makes each issue it's own unique problem.  This can take time to solve when you have to go through the battery of know fixes based on assumptions just to help the OP develop their questions to something specifically answerable.  Still, compared to the help call centers and delay of response from propriety make our effort more reactive and solutions tend to be faster as a whole in my experience.  I have spent the 2-3 hours on the phone, mostly on hold, waiting to be told to restart my system.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div>How do we write material that helps newbies to learn enough to take off on their own?  Writing that sort of material should be very good for *my* understanding.<br></div></div></blockquote><div> </div><div>In helping people on the ground with learning this new Linux stuff my process is to get them to functional state with the basic things the PC is used for: Turn it on, log in, get internet, start a browser.  From here I can help them develop their systems and teach them as I go, but I am here, a phone call away, to answer questions.  My users have been Windows marketing trained and that becomes my first hurdle.  How to forge had a wonderful guide on what to do when you finish installing the system.  Since the installation process is pretty much covered by the distros, these howto's seems the best model, that is "Now that you have a system here are things you can do.  Bare in mind the legal tap dance that prevents a distro from publishing so simple a document.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div>David<br></div><div class="gmail_extra"><div><div class="gmail-h5"><div class="gmail_quote"><br></div></div></div></div></blockquote><div><br></div><div>While a number of solution in the Linux/FOSS community tend to emulate the proprietor OSs/Software, Linux/FOSS is it's own.  The diversification as mentioned is the strength of Linux/FOSS.  If a fork stops developing then you look for new solution or if the popularity of the fork is sufficient it will be picked up by another.  OpenOffice/Libre Office, Ubuntu/Xubuntu by example.  Change, while inconvenient, is a necessary part of life. </div><div><br></div><div>My 2 bits,</div><div>Fred</div></div></div></div></div>