[Arm-dev] Enterprise distros and the two faces of 'reliability'

[Skorpeo Skorpeo]

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....

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.

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.

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.

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.

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).










On Fri, Oct 26, 2018 at 3:48 PM Gordan Bobic <gordan at redsleeve.org> wrote:

>
>
> On Fri, 26 Oct 2018, 23:10 Fred Gleason, <fredg at paravelsystems.com> wrote:
>
>>  none of the current crop of embedded boards seem to support any of those
>> standards.
>>
>
> There may be a half way solution you can leverage, at least on some
> devices - the ones supported by mainline u-boot.
>
> These days u-boot can present EFI compliant environment, or at least
> enough to satisfy grub-efi. I have this running in DreamPlugs.
>
> 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.
>
> 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).
>
> And once you have the kernel sorted out correctly, the user space will
> "just work".
>
> 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.
>>
>
> 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.
>
> 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.
>
> _______________________________________________
> Arm-dev mailing list
> Arm-dev at centos.org
> https://lists.centos.org/mailman/listinfo/arm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20181027/a67b4a58/attachment.html>