(12-27-2015, 04:42 AM)tkaiser Wrote: (12-27-2015, 03:55 AM)paulieg Wrote: That said, my end goal is getting Arch onto the pine64
Where's the point? As usual with a new Allwinner SoC we have an outdated kernel 3.x.something (good news: It's not 3.3/3.4 but 3.10.65 instead). Someone will manage to get the kernel booting in linux and that's all that's needed to combine a rootfs with bootloader/kernel. It will be ugly and slow but since it's that easy 'distro developers' will flood the net with crappy Linux distros for the Pine64.
People who care are concerned:
-- snip figure --
"End of 2015". If no one applies all kernel fixes up to 3.10.94 to Allwinner's 3.10.65 kernel within the next 4 days, the Pine64 will not be able to run with a kernel that is useable from a security point of view within the next 6/9/12 months. Support for kernel 3.10 stops right now and there's simply nothing else. None of the linux-sunxi kernel developers seems to be interested and at the moment mainline kernel support is not even in an alpha state:
https://groups.google.com/forum/#!topic/...e_UhiO00t8
https://groups.google.com/forum/#!topic/...3S4Dlmu2hc
I don't expect the situation to improve soon. Allwinner's bootloader still makes use of the sys_config.fex stuff (good news for Allwinner's real customers who sell millions of Android devices and get an development environment they're familiar with) and it seems you can define mismatching settings in sys_config.fex and .dts (the latter being used by the kernel).
As usual mainlining efforts will start from scratch and this will take some time. At the moment the Pine64 people rely solely on community's efforts (the C.H.I.P. people for example hired free-electrons to speed up development) so I would suspect we get many crappy OS images first (using Allwinner's u-boot and kernel implementation) and something useable at the end of 2016 maybe.
I agree with a lot of the sentiments you express. I do, however, disagree with the universality of application of the conclusion you draw.
Yes, the suckage of Allwinner and the way they handle relations with the open source community that makes their business possible is difficult to overstate. They're far from alone in this and their competitors in the same price bands are often worse, but that's not an excuse. No one should be giving companies that take and don't give back a free pass. My guess is that their part was chosen for the performance it can deliver at an impressively low pricepoint and the fact it is shipping now. There aren't too many alternatives that improve on openness with comparable performance and price.
I agree that treating linux support as an afterthought and assuming it will just materialise out of thin air was a massive mistake on the part of Pine64. The almost inevitable resulting mismatch between the capabilities the part has in theory which were communicated in the KS campaign and the capabilities it will have in practice when delivered is a cock-up of monumental proportions and is a direct consequence of the former. A lot of this could have been avoided with some forethought; at the very least, the need for as yet unavailable but necessary software support for hardware features should've been clearly communicated. The 'fully open source' characterization is unlikely to ever be entirely consistent with reality. Given all of these things, presenting this part as a lego-style building block for vaguely technical users to build beefy xbmc/kodi rigs with was inappropriate, imo.
I agree that the CHIP people did the linux bit the right way. I do wish Pine64 had done it that way too. I doubt, however, that it would've been possible. My back of the napkin calculations suggest there's simpy not enough meat on the bone at these prices to have fully funded rapid, professional linux support development. The Allwinner part is very inexpensive for what it is, but it's a big chunk of change when you're trying to pay for everything out of $15 - there's a reason that pricepoint hasn't been done before with anything comparable.
What's done is done. Where are we, how do we move forward and is it worth doing so (you say no, 'Where's the point?')? We know what we're going to get in terms of hardware and, roughly speaking, linux support (at least t start with). From the beginning, I viewed this as a means of getting an eval board for a very capable part for very little money with enough bsp support to make it usable for the type of projects I'm interested in. For me and people like me, that's enough.
A newer kernel would be nice. I'm not that familiar with the trajectory of linux kernel development on anything except big x86(-64) boxes since my interest in embedded stuff is both recent and a hobby, but I sincerely doubt that 3.0.x kernels are 'slow' in an absolute sense and images based on them must therefore inevitably be 'crappy'. Not as good as they could be? Definitely, but not universally unusable. Certainly good enough for hacking on a great many types of projects. The proof is in the pudding we've already eaten - there were plenty of cool projects in general and on ARM specifically in the 3.0 days and very few if any cries of 'I can't do anything on this darn platform because the kernel sucks!'.
I understand your security concerns. There was a time when I was really into security stuff, spent my free time playing wargames, talked of nothing but strong crypto at parties and thought that security was the most important feature of a system that trumps everything, always and everywhere. I grew up. OpenBSD's marketshare and mindshare demonstrates that security is not the primary consideration for most people, most of the time on most every project to the exclusion of everything else.
Speaking in practical terms, the vast majority of projects people would have in mind for this board do not involve multi-user access. As such, a compromise would require a remote vulnerability in the linux kernel with no backported patch, a viable exploitation vector on ARM and someone bothering to implement that vector. This is exceedingly unlikely - an issue of such severity would undoubtedly result in backported patches being made available for EOLed kernel versions still in widespread use. The only such vulnerabilities I can recall were issues with the bluetooth stack, igmp, nfs-acl and cifs-vfs - all of them in 2.6 or earlier. None had a workable PoC resulting in compromise, bt obviously required at least physical proximity, igmp is inapplicable to our use case and so on. When you apply bayesian statistics to the probabilities of the various factors that would need to combine to create a genuine threat of compromise, you'll end up with a value that makes it more likely that you'd be eaten by a bear first. If we posit a usermode vulnerability that is then combined with an unpatched local vulnerability in the kernel, a fix for the usermode vulnerability would render that attack vector harmless so we're ok as long as everything we run in usermode is still under maintenance.
All of this is before we consider how much of a problem having your blinkenlights hobby project compromised really is, whether it's likely to sit somewhere publicly accessible rather than behind NAT and how easy it is to backport a security patch most of the time. I'd argue having your girlfriend's ostensibly under maintenance Windows laptop on your LAN is an immeasurably bigger security risk. Yes, this EOL is a security concern, but only for the paranoid or those who intend to run internet-accessible production projects on it which are non-commercial in nature and can therefore not pay for support. I suspect that the intersection of those sets contains a number of elements that asymptotically approach zero. As such, I would argue that 3.0.x is good enough for most people from this perspective.
As for Arch, I happen to like it and it's an excellent fit as far as general purpose distros go for low resource devices. You might well disagree and think it's 'ugly', 'crappy' etc just as you disagree on whether Pine64 is going to be usable unless it has mainline support. This comes down to preference, opinion, expectation, skill level and suitability for the type of projects you had in mind for it.
So, in your words, 'Where's the point?' The point is that this board, if it ships, will be the most appropriate platform for the project I have in mind for very little money. I, or someone else, will get it to boot and I anticipate being able to get my distro of choice on it with a bit of elbow grease. Subsequently, I expect to have fun hacking on my project on Pine64 and that, surely, is the ultimate point.
It's not going to be perfect, certainly not to start with and possibly not ever. I am, however, willing to put in a bit of effort to get it on its way. I'm sure there'll be others who do as well. It certainly won't be the first time the community has hacked on an imperfectly supported piece of hardware to make it do what we want.
-p
![[Image: 205331icqgq73u10i1x43r.jpeg]](http://forum.lemaker.org/data/attachment/forum/201512/24/205331icqgq73u10i1x43r.jpeg)