-
[T]hey aren't linked yet ... mostly because the wiki articles are for devs and really not meant for users. Clearly the Phase 2 article isn't even finished
Not surprising, and I figured that was the reason. Since this is a dev-heavy and dev-supporting community, I hope you don't mind my posting the links for those with a thirst to know more.
Welcome, BTW. Glad to see you here.
-
@kalle-kruse Thanks for the link. It's an impressive post. And it was an impressive stand that they had at fosdem. Also the camera and the tablet looked really nice. But I forgot to try to play any audio or video on the tablet. Can someone comment? Is it Loud enough? Does it sound good?
-
@trainailleur not at all, its not even a secret. Its just because since regular users cannot (and will not) be able to obtain those kits there isn't really a reason to have them in our wiki. Thanks for having us here
@doniks glad you liked the stall and the post - I wrote it up, so I immodestly take the credit I only played audio on the PineTab once ~6-7 months ago on a super early prototype, so I honestly cannot answer the audio question. I think that it will be serviceable but won't knock your socks off (as you probably expect). As for video; 720p and 1080p playback will be fine with a dedicated player using HW acceleration. Lets see what devs can do with in-browser playback (in-browser 480p sw rendered will work fine but higher will require hw acceleration - newest cedrus has a vaapi wrapper!)
-
@3arn0wl What exactly do you mean by that question
-
Hey, @Flohack - thanks for... well just thanks for being, really.
Ubuntu was always explained as being all one code, in all one language... Which is a fantastic thing... A real strength.
But UT on the N5 seems to be more advanced than Unity 8... Is that an incorrect perception?
What I guess I'm asking therefore is: is it a big effort to get Unity 8 working on PinePhone at the same level as UT on my beloved N5? Is it to do with Mir and Wayland?
And will all the apps in the OpenStore work on Unity8?
-
The challenge to get Ubuntu Touch running is not unity8 I would say, and the click apps will stay. We have to remove the Android container and instead access the hardware directly.
We still dont know the exact amount of work what will be involved, but yes, the goal is to give the same experience at the end.
Also we must say here that the hardware specs might not be final and we dont know yet about GPS, sensors etc. And the main CPU is for sure slower than N5.
But dont judge the phone by its specs. Its a groundbreaking chance to show that we do not need Android hardware and that an open phone is possible. I think thats the huge message we want to get out.
-
@3arn0wl Also watch todayΒ΄s Q&A we might have some answer for you there.
-
@Flohack - It was great to see UT working on the Pine board in yesterday's Q&A. From what Jan has said recently about Google's direction with Fuchsia, the development of a completely Open alternative becomes vital.
-
@3arn0wl Yes I cannot repeat it too often: Android Fuchsia threatens the last part of openess that Android currently has: By removing the Linux kernel they are free to go fully closed source. Even if their microkernel might be open, all high level functions can then nicely be wrapped in closed source modules.
The idea of a microkernel seems neat for phones, true: Lots of features of a fully blown Linux kernel might never be used on phones at all. But its more about the political decision here than a technical one. So yes, UBports is fully aligned with fiinding alternatives, seeing Android porting as a temporary measure as the underlying problem cannot be fixed at all.
BR
-
Even if their microkernel might be open, all high level functions can then nicely be wrapped in closed source modules.
So no different than currently. All the high level stuff in Android is closed. It's why we can't ship the foundation services to be able to hook up push notifications, which are already implemented in most web services for Android, and thus must have our own implementation which almost nobody supports. Beyond that, it will basically not be any different than needing something like libhybris, but for Fuchsia, instead.
-
-
@trainailleur said in PinePhone:
The permissive license has potentially vast implications.
Feel free to elaborate. The drivers aren't going to be any less free, and that's where the real issues are. We've already got overly proprietary drivers with a GPLv2 kernel, so I don't see how having the kernel be Apache 2 is going to make it any worse, considering vendors already don't respect the GPL in most cases. All it does is put Google themselves in the position of not having to worry about the kernel license versus proprietary drivers.
Beyond that, nothing else is really going to change. Most of the middleware that we do need to run in the android container for UT is already Apache 2 anyway, and that's unlikely to change with Fuchsia underneath.
Really, all I see is people being hysterical for no reason.
-
The drivers aren't going to be any less free, and that's where the real issues are.
I guess that's why it's important that the Pine and Librem efforts are successful: to demonstrate to hardware manufacturers that there's a strong desire for open devices, to encourage them to produce more.
There are efforts though to produce Open Source drivers, aren't there?
-
@3arn0wl said in PinePhone:
There are efforts though to produce Open Source drivers, aren't there?
Yes, of course, and for the A64 such drivers are quite far along too [video showing open source hw video acceleration] : https://youtu.be/X18JN1pq2H4?t=1
Then there is lima for the GPU (WIP): http://linux-sunxi.org/MaliNot saying that initial releases will not use blobs - they probably will - but in time devs will surely switch over to FOSS drivers.
-
Well that's very encouraging news, @PINE64
-
@3arn0wl said in PinePhone:
There are efforts though to produce Open Source drivers, aren't there?
For Pine64 systems, yes. But Pine is not based on Fuchsia. The previous comments were about how Fuchsia would be "bad" for things like UT. I don't think it will be any worse for alternatives to Android, than it is now, and was trying to explain that.
There are also efforts to reverse engineer drivers to create open source ones in upstream kernel, for existing Android devices too. But it's extremely tedious to do. Unless the hardware manufacturers themselves are working to provide Open Source drivers, like Pine64 are, it's not going to matter much though.
Point is, let's stop worrying about Fuchsia and other future possible Google Android things, and just work on making UT be the best it can be, on whatever hardware/kernel/drivers we must use.
-
@trainailleur said in PinePhone:
The permissive license has potentially vast implications.
Feel free to elaborate.
First, note I used the word "potentially." Then, if you disagree, perhaps you could elaborate on how the implications of a permissive license cannot possibly be vast.
The drivers aren't going to be any less free
This may be so, or it may not be. We simply don't know yet. More and more embedded hardware is seeing mainlined drivers. If this is only because Linux (deliberately) lacks a stable target for drivers and OEMs are finding it easier to live with the accelerated pace of kernel development if they mainline (which seems to be Jon Corbet's supposition), the situation may be very different with Zircon.
Or perhaps it won't be, but I don't see how anyone has the information now in order to say. Even Google cannot know at this point what wrestling matches they may face with OEMs in the future.
We've already got overly proprietary drivers with a GPLv2 kernel, so I don't see how having the kernel be Apache 2 is going to make it any worse, considering vendors already don't respect the GPL in most cases.
For the moment, Google does appear to be dragging the OEMs kicking and screaming towards modern kernels, so if Google sticks with Android, we have reasons to believe the situation with Android drivers will improve as driver maintenance becomes more critical.
Beyond that, nothing else is really going to change. Most of the middleware that we do need to run in the android container for UT is already Apache 2 anyway, and that's unlikely to change with Fuchsia underneath.
Are you thinking to run the Linux kernel in a hypervisor on top of Zircon, or are you thinking of porting UT to Zircon (or something else that's not occurring to me)?
Really, all I see is people being hysterical for no reason.
Which is why I'm neither hysterical about it nor posted hysteria. But given how it's been eleven years since Android debuted on the market and we have only a handful of Android alternatives which will run on Android hardware, and only on a handful of devices, I won't blame anyone who does feel hysteria over the uncertainty surrounding a potential sea change in the OS and readily available hardware that will be available in the future.
Edit to add (since I didn't refresh the thread while composing and just saw this):
Point is, let's stop worrying about Fuchsia and other future possible Google Android things, and just work on making UT be the best it can be, on whatever hardware/kernel/drivers we must use.
I agree completely
-
@dobey The difference is that by now we got a fair knowledge to fix and bandaid stuff that breaks or is not working because the Linux kernel is something that many developers came in touch with.
Fuchsia will be all-new so we dont find forks, patches and other stuff on the planet. I assume many hundred man-hours will be necessary to bring a Fuchsia port to what we have now with core devices. A huge waste of our time.
I would say, better not do it at all. -
@trainailleur said in PinePhone:
First, note I used the word "potentially." Then, if you disagree, perhaps you could elaborate on how the implications of a permissive license cannot possibly be vast.
I didn't say there cannot possibly be implications. Nor did I speak to any vastness of them. I was merely pointing out that it's irrelevant and not something we should worry about. Nobody is using Fuchsia yet. And we don't support 100% (or even 10%) of existing Android devices. So the argument of we won't be able to support these unknown devices is pointless. And also, I was pointing out that the issues we do have to deal with are 99% of the time, above the kernel level, and Android manufacturers already fail to comply with GPLv2 by not releasing kernel source, and by not developing free drivers, or even free modules that load proprietary blobs (like NVidia and others do).
We can worry about Fuchsia when we have support for UT on as many devices as LineageOS supports, and there are actually shipping devices we would like to have UT support on. Until then, any mention of it is a waste of time.
Are you thinking to run the Linux kernel in a hypervisor on top of Zircon, or are you thinking of porting UT to Zircon (or something else that's not occurring to me)?
The only Zircon I know of is an IRC client in tcl/tk with a shared whiteboard feature. I presume that is not what you're talking about. I'm not sure what you're trying to infer here. I'm not the one who brought up Fuchsia in this thread. I was simply stating it's not something we should be worrying about.
Which is why I'm neither hysterical about it nor posted hysteria
IMO, any post speculating on the woes of Fuchsia relating to UT is hysteria, because it's all speculative and doesn't help make UT better, considering there are millions of existing Android devices which don't have anything to do with Fuchsia, and we only support about 10 of them.
-
I assume many hundred man-hours will be necessary to bring a Fuchsia port to what we have now with core devices. A huge waste of our time.
I would say, better not do it at all.So why does it keep coming up in discussions? We aren't talking about porting UT (or unity8) to Windows, OSX, iOS, Windows Mobile, or any other theoretical new mobile operating systems which do not exist yet, so why do people keep talking about Fuchsia as if it's an important thing we must concern ourselves with right now?