Let's be clear here. There are two points at issue:
1. Actually using the board for practical things.
2. Open source license compliance, blob-freeness, openness+cooperation, mainline support etc
While there surely are some areas of overlap, those use cases are marginal. We will have Pine64 that boots the linux kernel with a traditional gnu/linux userspace (as opposed to android, which is a linux kernel with an android userspace). There will be kernel/userspace combinations that will allow access to various graphics acceleration features through blobs. Given the work being done on an open source alternative to Cedar, perhaps we will even have workable open source userspace libraries for that. While it is perfectly true that this is not all in place right now as it is with a much older platform where the work has already been done, there is nothing that precludes it from being available in the future and I fully expect it to be - despite some highly dubious applications for engineering boards, I've seen some substantive ones as well. Frankly, most of this is not rocket surgery.
What we may not have is the ability to boot the latest mainline linux kernel, or if we do we might not have the blobs for hardware acceleration to go with it. We might be stuck with Allwinner's braindead uboot (not that the mainline uboot is some work of engineering genius, mind), at least for now and their 3.0.x kernel until they release android updates that require them to forward-port their kernel patches to newer kernel versions that are mandated by the respective recent android versions. The userspace open source substitution work on hardware acceleration takes precedence over the kernelspace work, so we might be stuck with the blobs there for even longer. While this is a state of affairs no advocate of open source and open hardware movements can be happy or entirely satisfied with, the practical impact of these things for most use cases is, imo, minimal.
As a practical matter, this is largely about price. Intel makes SBCs with (I expect) comparable performance and fewer issues and you're free to buy them at the prices they charge. However, if you want a $15 board that does all this SoC does, you're going to have to live with the consequences of it being a repurposed mobile SoC from a company that wants to protect certain advantages in the market they care about (mobile devices with 100k+ runs) in some cases and isn't free to release IP which they themselves have licensed in other cases (ARM's IP). Only those types of SoCs with that kind of volume can deliver this sort of package. If we as a community want to use these types of boards, we need to roll up our sleeves and get stuck in. If you remember the early history of hardware support in linux on x86, you'll recall that whining achieved nothing; hard work hacking together reverse-engineered support which allowed linux to flourish and then *demand* cooperation from hardware vendors is what enabled us to get to the point where every cluetard with 2 functional fingers can install *ubuntu on any x86 box and have it 'just work'.
I agree that communication on the level of existing support was inaccurate and that is very unfortunate. I should think I'd be disappointed if I had relied on it without doing any research. However, the gravity of the situation is constantly being overstated, the degree of inherent *practical* impairment to functionality is being misstated and the practical matters relating to linux support are constantly being conflated with ideological matters. By all means, "No queremos paz sino la victoria!" and all that - as a lifelong anarchist far be it from me to discourage quixotic ideological quests, but don't let that stop you having fun with this board - after all, there's a good chance you're running an amd or nvidia binary driver on your desktop/laptop now or at least were for a long time and, I trust, you haven't grown horns or a tail as a result and your soul remains in your sole possession rather than bequeathed to Beelzebub for all eternity.
-p
1. Actually using the board for practical things.
2. Open source license compliance, blob-freeness, openness+cooperation, mainline support etc
While there surely are some areas of overlap, those use cases are marginal. We will have Pine64 that boots the linux kernel with a traditional gnu/linux userspace (as opposed to android, which is a linux kernel with an android userspace). There will be kernel/userspace combinations that will allow access to various graphics acceleration features through blobs. Given the work being done on an open source alternative to Cedar, perhaps we will even have workable open source userspace libraries for that. While it is perfectly true that this is not all in place right now as it is with a much older platform where the work has already been done, there is nothing that precludes it from being available in the future and I fully expect it to be - despite some highly dubious applications for engineering boards, I've seen some substantive ones as well. Frankly, most of this is not rocket surgery.
What we may not have is the ability to boot the latest mainline linux kernel, or if we do we might not have the blobs for hardware acceleration to go with it. We might be stuck with Allwinner's braindead uboot (not that the mainline uboot is some work of engineering genius, mind), at least for now and their 3.0.x kernel until they release android updates that require them to forward-port their kernel patches to newer kernel versions that are mandated by the respective recent android versions. The userspace open source substitution work on hardware acceleration takes precedence over the kernelspace work, so we might be stuck with the blobs there for even longer. While this is a state of affairs no advocate of open source and open hardware movements can be happy or entirely satisfied with, the practical impact of these things for most use cases is, imo, minimal.
As a practical matter, this is largely about price. Intel makes SBCs with (I expect) comparable performance and fewer issues and you're free to buy them at the prices they charge. However, if you want a $15 board that does all this SoC does, you're going to have to live with the consequences of it being a repurposed mobile SoC from a company that wants to protect certain advantages in the market they care about (mobile devices with 100k+ runs) in some cases and isn't free to release IP which they themselves have licensed in other cases (ARM's IP). Only those types of SoCs with that kind of volume can deliver this sort of package. If we as a community want to use these types of boards, we need to roll up our sleeves and get stuck in. If you remember the early history of hardware support in linux on x86, you'll recall that whining achieved nothing; hard work hacking together reverse-engineered support which allowed linux to flourish and then *demand* cooperation from hardware vendors is what enabled us to get to the point where every cluetard with 2 functional fingers can install *ubuntu on any x86 box and have it 'just work'.
I agree that communication on the level of existing support was inaccurate and that is very unfortunate. I should think I'd be disappointed if I had relied on it without doing any research. However, the gravity of the situation is constantly being overstated, the degree of inherent *practical* impairment to functionality is being misstated and the practical matters relating to linux support are constantly being conflated with ideological matters. By all means, "No queremos paz sino la victoria!" and all that - as a lifelong anarchist far be it from me to discourage quixotic ideological quests, but don't let that stop you having fun with this board - after all, there's a good chance you're running an amd or nvidia binary driver on your desktop/laptop now or at least were for a long time and, I trust, you haven't grown horns or a tail as a result and your soul remains in your sole possession rather than bequeathed to Beelzebub for all eternity.
-p