<div dir="ltr"><div>Well I wasn't going to pontificate but since it appears I may have triggered this discussion I'll give myself an illusory license. With the backdrop of someone who is probably the least qualified on this list and someone who did their first x86 centos install just a few years ago. I started playing around with arm maybe a little over a year ago as a result I had to seriously bang my head and also have the persistence to work through the pain. Eventually I got everything I wanted to work and am grateful because my knowledge and understanding has tremendously improved. But....<br></div><div><br></div><div>Last week for the first time I installed centos on a arm machine, specifically machiatobin, using a vanilla iso file. The installation was just like on a x86 system and went without a hitch. All of the headache, custom hand crafted human supervised work, gone, poof, no longer required. To me its a game changer. <br></div><div><br></div><div>So without stepping on anyone's toes and after reading Mr. Masters blurb on APCI etc. linked in the beginning of this thread. I find that at first blush it may be worded in a way where it seems to be a ultimatum or antagonistic towards users of centos on arm hardware (i.e. this list). However, I see it more as a message to the hardware folks - that they need to make sure their hardware works with centos and not the other way around. So that we can (emphasis added) seamlessly install centos onto arm hardware and so that we can (emphasis added) run yum install foobar. Not to mention the security and stability/bug implications on the eco system.</div><div><br></div><div>I will humbly disagree with the big vs small/embedded argument as what is big or powerful vs what is not is relative, and as we all know these things progress quickly. Nonetheless, you can install centos on a x86 Asus Vivostick, which isn't exactly a power house so why not the same for arm. If it works it works. Furthermore, consistency across platforms will also ideally allow for a single workflow across those platforms.<br></div><div><br></div><div>Absolutely if I have a choice I will go with hardware that makes my workflow easy, consistent and reliable. If I don't have a choice then it just raises the cost of development, to some that doesn't matter to others it shuts them out.<br></div><div><br></div><div>I think I echo what others have already said but then again does original thought really exist or is it collective? I think in the future processors will be liquid and made out of engineered solutions (the liquidy kind).</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 3:48 PM Gordan Bobic <<a href="mailto:gordan@redsleeve.org">gordan@redsleeve.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 26 Oct 2018, 23:10 Fred Gleason, <<a href="mailto:fredg@paravelsystems.com" target="_blank">fredg@paravelsystems.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div> none of the current crop of embedded boards seem to support any of those standards.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There may be a half way solution you can leverage, at least on some devices - the ones supported by mainline u-boot.</div><div dir="auto"><br></div><div dir="auto">These days u-boot can present EFI compliant environment, or at least enough to satisfy grub-efi. I have this running in DreamPlugs.</div><div dir="auto"><br></div><div dir="auto">Secondary benefit is that you can build a reasonably vanilla multi-SoC kernel and have that booting from grub without having to prepare it for u-boot.</div><div dir="auto"><br></div><div dir="auto">It makes it a lot easier to support multiple devices with a single kernel (just avoid a distro Frankenstein kernel and stick with vanilla mainline).</div><div dir="auto"><br></div><div dir="auto">And once you have the kernel sorted out correctly, the user space will "just work".</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Whether this is because of laziness, ignorance or the need to hit a particular (often very low) price point I am not in a position to determine.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It's lazyness, ignorance, and inertia of historical utterly inconsiderate contempt and unaccountability of SoC manufacturers producing un-mainlineable kernel and boot loader/firmware bodges to get their SoC working without any intent to ever maintain them.</div><div dir="auto"><br></div><div dir="auto">The only sane thing to do is to only ever consider hardware that is well supported by mainline kernels and bootloaders for any project. Custom bodged kernels and bootloaders just aren't worth the effort. If a hardware manufacturer doesn't think it's worth their time to support open standards, it most certainly shouldn't be worth yours. It took me a few years to finally accept that.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
_______________________________________________<br>
Arm-dev mailing list<br>
<a href="mailto:Arm-dev@centos.org" target="_blank">Arm-dev@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/arm-dev" rel="noreferrer" target="_blank">https://lists.centos.org/mailman/listinfo/arm-dev</a><br>
</blockquote></div>