William, just some feedback here. Since my original post, where I clearly explained that I was a noobie to BBB, I haven't found your responses to be helpful.
> This just tells me that either a) the person asking the question isn't willing to look, or doesn't know where to look. > As for the rest, yeah, IDK maybe it's just me( I doubt it ) but very seldom do I have issues following an older guide, and converting to a modern file system arrangement. I'd say, that perhaps more time needs to be invested in order to "get it" ? Maybe you don't realize that statements like that are abrasive? I'm a noob to the BB, but not a noob to embedded systems or development. I've been doing it over 20 years, have built systems designed to support tens of millions of users, and feel comfortable coding directly in AVR asm, or x86 asm, C, or umteen other languages, platforms and backends. So when I point out frustration with the BB documentation and change process, it's not from the perspective of a sparkle pony, it's from the perspective of someone who has been doing this stuff for a really long time, and sees issues. My criticism, which I think is entirely on point, is that the BB ecosystem has a problem with cohesiveness in documentation and approachability for makers and hobbyists. >From what I've seen, this is a reputation that the BB has earned throughout the maker community. I'm a member of the Dallas makerspace, the largest makerspace in the country - and the general consensus from the folks I've talked to there is "yeah, the BB hardware is great, but the documentation is terrible, if you want to be productive, use a Pi." I volunteered to help out with this, especially as it relates to SPI, which is a pretty common use case for an embedded platform. Far from being constructive and helpful like Robert, after reading your responses, my general feeling is "why bother? I'll just go use the Pi". I'm sorry if it seems like I'm attacking you here, it's not my intent. I honestly want to give you feedback that from my perspective, and I think those like me, the tone and content of your posts serves to frustrate and alienate rather than community build and improve. If we want to build the BB community and platform, our responses to newcomers, (especially those willing to volunteer to help!) should be welcoming and encouraging. Not a paraphrase of "RTFM" or "Well I figured it out, kid, so should you". On Saturday, December 9, 2017 at 4:02:08 PM UTC-6, William Hermans wrote: > > > > On Sat, Dec 9, 2017 at 1:01 PM, Dennis Lee Bieber <wlf...@ix.netcom.com > <javascript:>> wrote: > >> >> The following is just my viewpoint, and is not meant to be an >> attack on >> any person. I've not done enough with the BBB (other than running a nasty >> benchmark on it and an RPi3 -- and I think the benchmark wore out the >> original RPi3 SD card, before I obtained a small USB hard drive for swap) >> >> On Sat, 9 Dec 2017 12:10:23 -0700, William Hermans >> <yyr...@gmail.com <javascript:>> declaimed the following: >> >> > >> >You need to slow down, and learn things. Seriously, when I first had a >> BBB >> >in hand, I knew nothing about embedded Linux, and had to learn everything >> >from the ground up. Since this was also when the beaglebone black first >> >came out, there were no articles on the web. However, what I did not >> >understand at the time, was the BBW was pretty much the same hardware >> from >> >an embedded linux users standpoint. There were a lot of article out >> there . >> >> The biggest hindrance currently is that practically everything >> that IS >> "out there' for the BBB is based upon cape-manager and run-time device >> tree >> overlays. There doesn't seem to be anything that firmly lays out how to >> convert a cape-manager/overlay example into the u-Boot overlay scheme >> (would be nice if such example actually used some major documentation -- >> say a side-by-side of Molloy's lessons). >> >> Consider how many questions over the last few months have had >> answers >> on the order of "... no longer create a separate FAT partition" or "... >> now >> use u-Boot overlays". Neither of which actually explain how to go from >> some >> now-outdated guide to equivalent functionality. Heck, I've even seen >> images >> vary from auto-mounting an SD card (when booting from eMMC) to requiring >> one to figure out how to perform a mount, and to some intermediate >> condition. >> > > This just tells me that either a) the person asking the question isn't > willing to look, or doesn't know where to look. Both of the examples youve > given above are explained on the elinux documentation pages. Of whcih I'm > assuming wrote those guides. Robert at least links to them all the time, > for question asked here. Not to mention in the case of uboot overlays, it's > clearly mentioned, and linked to in the uEnv.txt file for every image I've > seen to date. > > As for the rest, yeah, IDK maybe it's just me( I doubt it ) but very > seldom do I have issues following an older guide, and converting to a > modern file system arrangement. I'd say, that perhaps more time needs to be > invested in order to "get it" ? > > Adapting overlays, source, etc is a matter of experience, and perhaps > those who do not understand them should study, and experiment more ? Worked > for me. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/925da000-8e66-46b6-8b61-6fc86efc77d8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
