Android-x86 partners with Remix OS!

[Chih-Wei Huang]

Hi all,
As you may have read the announcement on both sites,
Android-x86 partners with Remix OS now.

http://www.android-x86.org/changelog/partnership
http://www.jide.com/en/remixos-for-pc/announcement

For those who are curious, let me give more details
why and how we make the partnership.


Jide Technology, the creator of Remix OS, has contacted
me in about Sep 2015 for the cooperation.
In the early Nov 2015, one month after Android-x86 5.1-rc1
released, they sent me a preview iso of Remix OS for PC
based on the 5.1-rc1. I was surprised they made it so quickly.

In the mid Nov 2015, two co-founders of Jide met me
at Taipei to exchange more ideas about the cooperation.
Later in the end of Nov when I visited Beijing,
I was invited to Jide's office to give a talk to the RD team.
I was surprised they have a so big, smart and energetic team.
After that, Jide engineers joined the devel group
to co-work with other developers. They have submitted
some valuable patches to the Android-x86 codebase.

Last week after the CNY holidays, I was invited to Jide office
again. During the meetings in the 4 days, we reached a very
detailed cooperation plan including new designed website,
prioritized working items and marketing promotion.
Moreover, we see the same vision that Android will
enter or even dominate the PC desktop in the future.
We hope to make it happen as quicker as possible.
We agreed to announce the partnership on MWC 2016.

Jide Technology will continue to contribute improvements of
Remix OS under the x86 BSP level, say, the kernel and hals.
Later I'll post the detailed tasks to the devel group
so other developers can follow and co-work together.


Besides, I was also invited to visit Chaozhuo Technology,
the creator of Phoenix OS(x86) in Beijing.
Though they are a smaller group, they also show
sincere intention to work with the community
to improve Android UX on the desktop.
I think they will also make good contributions in the future.


What I hope to say is the Jide and Chaozhuo Technology
shows a very good example how the commercial companies
can co-work and contribute an open source project
like Android-x86.
I believe they will move forward this project to a totally
different level than before in the near future.


Let's make it!

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[okwon]

Congratulations ~~

2016년 2월 24일 수요일 오후 10시 1분 0초 UTC+9, Chih-Wei Huang 님의 말:

[Kittygirl]

Thank-you for partnering with Jide for RemixOS! I am rather excited about it (only been able to mess around with Alpha a little, finally my beta download is done! )! Glad to see that its free and n00b friendly!

 Keep up the great work! :)

[youling 257]

you will update Android x86 aosp 6.0.1 ？ remix os base on 6.0.1，will well.

[Thomas Hoberg]

Dear Chih-Wei,

I've played with Android-x86 over the last years, typically during vacations when I had time enough to go through some builds and trying them on the various kinds of x86 hardware I have in my home lab. Intel stuff with chipset or CPU graphics typically worked rather well, AMD APUs and dGPU typically not so great. Remix Beta is the first to run with my Kaveri APU (A10-7850K) out of the box (haven't tried the Trinity and Richmond based APUs yet).

I really always wanted to run an Android/Ubuntu hybrids on my bigger machines like my Haswell Xeon with 32GB, RAID, SSDs and Nvidia GTX 780 or the Phenom II x6 with an Radeon 290X as well as on my Bay Trail and Braswell Atoms: Android brings a lot more basic functionality to the table than your run-of-the mill Fedora or Ubuntu desktop and I've always felt that it's easier to add Linux desktop to Android than making Linux run on a tablet.

So often I've jus taken Android-x86 and reconfigured the kernels to add support for hardware I have on my PCs, but which you won't find on a 1-2GB HDMI Intel compute stick. I mean there is a 64-Bit variant for a reason, right?

And right now I'd like to build a 64-bit kernel for Remix OS which supports my AMD Phenom II x6, because the Jide developers for some reason chose not to support these older Phenoms in their 64-bit build (instead they recommend using the 32-bit variant).

A 32-bit Android running on a 6 core 3.6GHz box with 16GB of ECC RAM? Excuse me? Do you know why x86-64 is still called AMD64 on many platforms?

Their oversight would be extremely easy to fix, by reconfiguring the kernel they use and recompiling it.
And it might be useful to add Nvidia support to it, because at the moment Remix only sees and uses the integrated Haswell P4900 GPU of my Xeon E3-1276 v3 and ignores the GTX 780.

Now the question is: Where can I find the repository that holds the kernel they maintain?

Ideally I should be able to mix a home grown kernel with their Remix distribution.

I can kinda understand they don't want to release their launcher and all the other modifications they have done as open source (don't know if they can legally avoid doing so), but the ability to play with the kernel features and the hardware support has always been one of the key ingredients of Android-x86 and I'd like that part to live on, while Jide should continue on creating the perfect user land to make Android the best Linux desktop user experience.

I really want the best of both worlds, I'm happy to pay Jide a couple of bucks a year for their UI work, but I also want the flexibility of open source Linux/Android where it counts.

I see your collaboration fitting to that vision almost ideally, but at the moment I cannot see how it is executed, because I can't just select a "Remix" branch for Android-x86.

I'd appreaciate any pointers or hints as to how this would work in the future.

Kind regards, Thomas

[Hypo Turtle]

Think I can answer a few of your questions ...
Jide source is supposedly here - https://github.com/jide-opensource/ but it seems to just be the alpha i.e. 4.0.9 kernel
Why AMD64, well why is 32bit called x86?? To answer both; the first 32bit chip was the Intel 8086, the first 64bit chip (with proper x86 compatibility) was made by AMD.
AMD64's specs became the standard for 64bit chips so thats why some (purists) would prefer to refer to the arch as AMD64 (AMD64, x86, x86_64 and x86-64 are all the same thing though)

Okay back to Remix; you should be able to use the 4.4.0 Ax86 kernel/modules with RemixOS - while waiting for the 4.4.2 source to materialise.

[Thomas Hoberg]

Please see my inserts

On Sunday, March 6, 2016 at 10:37:15 PM UTC+1, Hypo Turtle wrote:

Think I can answer a few of your questions ...
Jide source is supposedly here - https://github.com/jide-opensource/ but it seems to just be the alpha i.e. 4.0.9 kernel

I've just had a cursory look at that and nothing is less than 5 months old. And it doesn't seem to be x86 related.

Why AMD64, well why is 32bit called x86??   To answer both; the first 32bit chip was the Intel 8086, the first 64bit chip (with proper x86 compatibility) was made by AMD.
AMD64's specs became the standard for 64bit chips so thats why some (purists) would prefer to refer to the arch as AMD64 (AMD64, x86, x86_64 and x86-64 are all the same thing though)

I know my x86 history well enough: I started programing for money on an original IBM PC XT in 1984 (the one with the 10MB 5 1/4" full height hard disk drive), my first own PC had an Intel 80286 and I've owned every generation of x86 CPUs produced since, both by Intel and AMD.

I was basically complaining that the Remix guys are dissing the very CPU type on their 64-bit build, which brought 64-Bit to x86.

I don't know which x86 instruction extension they made mandatory in their config, but Linux and Android have very few hard dependencies of their own. And CPUs haven't really evolved that much in the last 10 years, we still run three Core 2 based PC in the family with 3.4 GHz quad cores (modded Xeons, very cheap today) and modern graphics cards which deliver top notch gaming performance with high end Steam titles on less than 50 Watts of power (for the CPU, GPUs are around 200 Watts).

Most likely it's nothing relevant, but I hope it's not AES-NI, because that would also preclude Bay Trail Atoms, which are otherwise a perfect fit for Remix (Braswell works perfectly).

I mean, ok Linus Torvalds dropped 80386 support from the Linux kernel 3.7 in 2012 even if an 80386 was what Linux was "born" on in 1991: But my Phenom II x6 is from 2010 and still quite ok in term of CPU performance. It runs every current x86 OS from VMware ESX, Windows Server 2012R2 to Fedora 23 just fine and it certainly should be good enough to run Android with a proper GPU (Radeon 290X inside, which I wanted to test after the APU worked so well).

In fact a Remix optimized Android would be the perfect system for quite a few older PCs I have under my direct or indirect care, which seem to have become a little sluggish with Windows 10 while they are perfectly capable of running a 64 bit Android and had have RAM to fill. A lot of these are used by kids and those kids know Android better from phones and tablets than they know Windows or Linux.
 

Okay back to Remix; you should be able to use the 4.4.0 Ax86 kernel/modules with RemixOS - while waiting for the 4.4.2 source to materialise.

Whenever I started fiddling with Android-x86 I first tried to build a current release unmodified from Chih-Wei's work, just to validate my build environment.
Then I'd start skrewing around and know who to blame, if things stopped working.

So that's why I'd like to start with the obviously excellent work Chih-Wei and Remix have done, but I kind find that source.

Chih-Wei's latest 5.1 release is based on a 4.0.9 kernel and all his work on the 4.4 kernel seems Marshmallow based.

Remix is a 5.1.1 with a 4.4 kernel, clearly something in between and obviously something that works rather well, including an AMD Kaveri A10-7850K APU, which never worked on the previous Android-86 releases I tried.

So if I wanted to play around, that 64-Bit kernel which Remix Beta is using and which is a product of shared work between Jide and Chih-Wei, should be the perfect starting point, but it seems to use a different repository.

 

[Miker1029]

"I know my x86 history well enough: I started programing for money on an
original IBM PC XT in 1984"

OFF-TOPIC:

Cool So Did I !!!!!!!!!

[pstglia]

Hi Thomas,

Remix is a 5.1.1 with a 4.4 kernel, clearly something in between and obviously something that works rather well, including an AMD Kaveri A10-7850K APU, which never worked on the previous Android-86 releases I tried.

So if I wanted to play around, that 64-Bit kernel which Remix Beta is using and which is a product of shared work between Jide and Chih-Wei, should be the perfect starting point, but it seems to use a different repository.

 

The main reason your A10 7850K is not working on previous releases is because due radeonsi driver. We managed to enable and compile it starting from Lollipop (which has the minimum required llvm version to compile radeonsi on Mesa). However, at first not all CGN cards were well supported.

With help of Mesa maintainers and Mauro Rossi, this was improved. Most of his worked is already synced on sourceforge, but there's no "official" Android-x86 release image containing this code.

However, you can try this build made by Mauro Rossi. Many GCN users are reporting this works ok (AMD kanibi 5150, AMD r7 260X and others)

https://drive.google.com/file/d/0B_OFHiIqgpSFTHBqd2xPLVUzY2c/view?usp=sharing 

Jide probably  merged this code on latest Remix release.

Regards,

Pstglia

[pstglia]

 

With help of Mesa maintainers and Mauro Rossi, this was improved. Most of his worked is already synced on sourceforge, but there's no "official" Android-x86 release image containing this code.

Yet... Of course these changes will be available on the next release. But you can always get the code and compile locally (or use someone's build)

[Chih-Wei Huang]

2016-03-07 9:15 GMT+08:00 'Thomas Hoberg' via Android-x86
<andro...@googlegroups.com>:

> Please see my inserts
>
> On Sunday, March 6, 2016 at 10:37:15 PM UTC+1, Hypo Turtle wrote:
>>
>> Think I can answer a few of your questions ...
>> Jide source is supposedly here - https://github.com/jide-opensource/ but
>> it seems to just be the alpha i.e. 4.0.9 kernel
>
> I've just had a cursory look at that and nothing is less than 5 months old.
> And it doesn't seem to be x86 related.

Indeed the github is not updated for their beta release.
That's a mistake.
I've asked Jide to handle it as soon as possible.

>> Why AMD64, well why is 32bit called x86?? To answer both; the first
>> 32bit chip was the Intel 8086, the first 64bit chip (with proper x86
>> compatibility) was made by AMD.
>> AMD64's specs became the standard for 64bit chips so thats why some
>> (purists) would prefer to refer to the arch as AMD64 (AMD64, x86, x86_64 and
>> x86-64 are all the same thing though)
>
> I know my x86 history well enough: I started programing for money on an
> original IBM PC XT in 1984 (the one with the 10MB 5 1/4" full height hard
> disk drive), my first own PC had an Intel 80286 and I've owned every
> generation of x86 CPUs produced since, both by Intel and AMD.
>
> I was basically complaining that the Remix guys are dissing the very CPU
> type on their 64-bit build, which brought 64-Bit to x86.

About this problem, you need to do some homework
before complaining.

It's Google which brought the 64-bit support to Android
since the 5.0 (lollipop) release, not by Remix guys.
The x86-64 ABI was defined by Google and Intel,
nothing to do with Android-x86 or Remix OS:

http://developer.android.com/ndk/guides/abis.html

The 64-bit images released by Android-x86 or Remix OS
are just compliant to the ABI requirement.

In short, your CPU is too old to meet
the ABI requirement defined by AOSP.
(I guess it missed SSE 4.x)

In doubt, try cat /proc/cpuinfo for your CPU
in any Linux distrubition.

> I don't know which x86 instruction extension they made mandatory in their
> config, but Linux and Android have very few hard dependencies of their own.
> And CPUs haven't really evolved that much in the last 10 years, we still run
> three Core 2 based PC in the family with 3.4 GHz quad cores (modded Xeons,
> very cheap today) and modern graphics cards which deliver top notch gaming
> performance with high end Steam titles on less than 50 Watts of power (for
> the CPU, GPUs are around 200 Watts).
>
> Most likely it's nothing relevant, but I hope it's not AES-NI, because that
> would also preclude Bay Trail Atoms, which are otherwise a perfect fit for
> Remix (Braswell works perfectly).
>
> I mean, ok Linus Torvalds dropped 80386 support from the Linux kernel 3.7 in
> 2012 even if an 80386 was what Linux was "born" on in 1991: But my Phenom II
> x6 is from 2010 and still quite ok in term of CPU performance. It runs every
> current x86 OS from VMware ESX, Windows Server 2012R2 to Fedora 23 just fine
> and it certainly should be good enough to run Android with a proper GPU
> (Radeon 290X inside, which I wanted to test after the APU worked so well).
>
> In fact a Remix optimized Android would be the perfect system for quite a
> few older PCs I have under my direct or indirect care, which seem to have
> become a little sluggish with Windows 10 while they are perfectly capable of
> running a 64 bit Android and had have RAM to fill. A lot of these are used
> by kids and those kids know Android better from phones and tablets than they
> know Windows or Linux.

I agree it's nice to bring new life to older PCs
by Android-x86 or Remix OS.
However, Google or Intel doesn't think in that way.

There are some ideas which been discussed to address that issue.
e.g, SSE4 emulation code in kernel.
But it's just an idea. Nobody is going to implement it yet.

>> Okay back to Remix; you should be able to use the 4.4.0 Ax86
>> kernel/modules with RemixOS - while waiting for the 4.4.2 source to
>> materialise.
>
>
> Whenever I started fiddling with Android-x86 I first tried to build a
> current release unmodified from Chih-Wei's work, just to validate my build
> environment.
> Then I'd start skrewing around and know who to blame, if things stopped
> working.
>
> So that's why I'd like to start with the obviously excellent work Chih-Wei
> and Remix have done, but I kind find that source.
>
> Chih-Wei's latest 5.1 release is based on a 4.0.9 kernel and all his work on
> the 4.4 kernel seems Marshmallow based.
>
> Remix is a 5.1.1 with a 4.4 kernel, clearly something in between and
> obviously something that works rather well, including an AMD Kaveri
> A10-7850K APU, which never worked on the previous Android-86 releases I
> tried.
>
> So if I wanted to play around, that 64-Bit kernel which Remix Beta is using
> and which is a product of shared work between Jide and Chih-Wei, should be
> the perfect starting point, but it seems to use a different repository.

The Remix OS beta uses the kernel 4.4 in our SF git repository.
But I can't tell whether it's an unmodified version or not.
In any case, I've asked them to push their git repository
to their github.

[SJ]

I realize this is kinda off topic but Mr. Huang or anyone else have any ideas why the 32bit beta version of remixos only works in guest mode on the Asus T100? Resident mode just hangs on remixos screen. Someone mentioned that they got the 64bit to work on a T100taf though.
Yes I realize that this is android x86 not remixos(no DEVS have commented our T100 THREAD on remixos Google groups) ! Wondering if anyone has an ideas!
Thx

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Thomas Hoberg]

Hi Chih-Wei!

On Monday, March 7, 2016 at 4:35:51 AM UTC+1, Chih-Wei Huang wrote:

2016-03-07 9:15 GMT+08:00 'Thomas Hoberg' via Android-x86
<andro...@googlegroups.com>:
> Please see my inserts
>
> On Sunday, March 6, 2016 at 10:37:15 PM UTC+1, Hypo Turtle wrote:
>>

[...]

> I was basically complaining that the Remix guys are dissing the very CPU
> type on their 64-bit build, which brought 64-Bit to x86.

About this problem, you need to do some homework
before complaining.

It's Google which brought the 64-bit support to Android
since the 5.0 (lollipop) release, not by Remix guys.
The x86-64 ABI was defined by Google and Intel,
nothing to do with Android-x86 or Remix OS:

http://developer.android.com/ndk/guides/abis.html

The 64-bit images released by Android-x86 or Remix OS
are just compliant to the ABI requirement.

In short, your CPU is too old to meet
the ABI requirement defined by AOSP.
(I guess it missed SSE 4.x)

With Intel defining the ABI, I guess I shouldn't be surprised: They won't be very interested in protecting AMD's installed base. And they fought very hard and dirty to keep AMD from getting SSE4.

What's somewhat funny is that SSE4.2 and POPCNT don't actually seem to be required, at least Remix 64-bit works just fine on a Penryn based Core2 mobile I just tested and that doesn't support SSE4.2 or POPCNT according to Wikipedia (https://en.wikipedia.org/wiki/SSE4).

But I can appreciate that SSE4.1 could be useful on Android even if the Phenom in all likelyhood would be able to compensate somewhat by shere CPU power.

After thinking a little more about it I wonder if the Intel provided ARM emulator isn't the problem: Translating NEON to SSE4 could be somewhat more straight forward than a full emulation.

I guess I'll survive if that system won't run Android, it just happens to be the one which had the beefy Radeon 290X and after Remix worked so well on the Kaveri APU (which is after all GCN) I just wanted to see Android OpenGL benchmarks going to silly heights with the 290X monster GPU.

My Haswell Xeon 1276 v3 has an Nvidia GTX 780 but that isn't recognized at all by Remix which only uses the CPU internal HD P4600 GPU and while that one still beats any ARM GPU I've seen so far, the Nvidia would just do soo much better.

My thinking there is that Android x86 almost has a better chance of becoming what Steam fails to accomplish on "normal" Linux, especially once Vulcan is there.

I agree it's nice to bring new life to older PCs
by Android-x86 or Remix OS.
However, Google or Intel doesn't think in that way.

There are some ideas which been discussed to address that issue.
e.g, SSE4 emulation code in kernel.
But it's just an idea. Nobody is going to implement it yet.

SSE4 emulation sounds terrible indeed: Better avoiding the generation of SSE4 instructions in the first place.
I guess that takes all these Acer notebooks off the Remix list I have running with Merom 65nm Core 2 mobiles (T7500 and T7700).

Thanks for your explanation and all the good work!

[Hypo Turtle]

On Monday, 7 March 2016 03:35:51 UTC, Chih-Wei Huang wrote:
> The Remix OS beta uses the kernel 4.4 in our SF git repository.
> But I can't tell whether it's an unmodified version or not.
> In any case, I've asked them to push their git repository
> to their github.
>
>
> --
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org

Just comparing the 4.4.2 stock ROS-B kernel with the custom 4.4.0 Ax86 kernel (missing wifi firmware), there is at the very least fs differences (4.4.2 mounts my exfat sdcard automatically - 4.4.0 doesn't).

Anyway their 4.4.y kernel repo seems to be live now, so props for that.

[ma...@xemi.net]

Great work CW.

Any idea how much work they did to get the Mesa LLVM stack to work on android-x86?

[Thomas Hoberg]

Hi Pstglia,

I did give it a try, but it would just reset and reboot on the Phenom II which has the 290X inside.

Dunno if this is a 64bit build, which (now ;-) would explain it or if there is another issue.

I'd try moving it to another CPU if the 290X wasn't such a power monster and the Phenom II x6 is the only one with a properly sized PSU in it (actually there is also the Haswell Xeon, but that's filled to the hilt with RAID, FusionIO and other stuff so I'd rather not touch it).

[Thomas Hoberg]

Just tried it on a Penryn based Xeon Harpertown, modded from socket 771 to 775 which has SSE4.1 (but 4.2 etc.) and a GCN Radon 7870.
Booted the kernel all right but surfaceflinger dies on an "illegal opcode" in gallium_dri.so.

Various other daemons die with the same invalid opcode.

I'll try a 32-bit ReMIX next on that hardware to see if it makes a difference, but 64-Bit RemixOS worked just fine on a Penryn mobile Quadcode which also lacks SSE 4.2 (but has SSE 4.1).

[pstglia]

Hi Thomas,

Em domingo, 13 de março de 2016 13:03:25 UTC-3, Thomas Hoberg escreveu:

Just tried it on a Penryn based Xeon Harpertown, modded from socket 771 to 775 which has SSE4.1 (but 4.2 etc.) and a GCN Radon 7870.
Booted the kernel all right but surfaceflinger dies on an "illegal opcode" in gallium_dri.so.

Various other daemons die with the same invalid opcode.

I'll try a 32-bit ReMIX next on that hardware to see if it makes a difference, but 64-Bit RemixOS worked just fine on a Penryn mobile Quadcode which also lacks SSE 4.2 (but has SSE 4.1).

Yes, by defaut 64 bits builds uses some SSE4.1 instructions and POPCNT, which are not available on every CPU

Used an objdump script [1] + vim-gas [2]  and got some samples:

FILE:instruction - Instruction set - Matched string

system/lib64/libRSSupport.so:blendps - syn keyword gasOpcode_SSE41 blendps blendpsb blendpsw blendpsl blendpsq

system/lib64/libRSSupport.so:pextrb - syn keyword gasOpcode_X64_SSE41 pextrb pextrbb pextrbw pextrbl pextrbq

system/lib64/libRSSupport.so:pextrd - syn keyword gasOpcode_SSE41 pextrd pextrdb pextrdw pextrdl pextrdq

system/lib64/libRSSupport.so:pextrq - syn keyword gasOpcode_X64_SSE41 pextrq pextrqb pextrqw pextrql pextrqq

system/lib64/libRSSupport.so:pextrw - syn keyword gasOpcode_X64_SSE41 pextrw pextrwb pextrww pextrwl pextrwq

system/lib64/libRSSupport.so:pinsrd - syn keyword gasOpcode_SSE41 pinsrd pinsrdb pinsrdw pinsrdl pinsrdq

system/lib64/libRSSupport.so:pmaxsd - syn keyword gasOpcode_SSE41 pmaxsd pmaxsdb pmaxsdw pmaxsdl pmaxsdq

system/lib64/libRSSupport.so:pminud - syn keyword gasOpcode_SSE41 pminud pminudb pminudw pminudl pminudq

system/lib64/libRSSupport.so:pmulld - syn keyword gasOpcode_SSE41 pmulld pmulldb pmulldw pmulldl pmulldq

system/lib64/libRSSupport.so:roundss - syn keyword gasOpcode_SSE41 roundss roundssb roundssw roundssl roundssq

system/lib64/libc.so:pextrb - syn keyword gasOpcode_X64_SSE41 pextrb pextrbb pextrbw pextrbl pextrbq

system/lib64/libc.so:pmuldq - syn keyword gasOpcode_SSE41 pmuldq pmuldqb pmuldqw pmuldql pmuldqq

system/lib64/libc.so:popcnt - syn keyword gasOpcode_NEHALEM_Base popcnt

[1] - check_instruction_set_binary.sh

[2] - https://github.com/Shirk/vim-gas (gas.vim file)

[Thomas Hoberg]

On Monday, March 7, 2016 at 2:33:33 AM UTC+1, pstglia wrote:

Hi Pstglia,

tried this version on both the Kaveri and the Richland system. Kaveri looked excellent, Richland failed to load the dri driver.

You wouldn't happen to have a link to a 32-bit variant of this excellent build? So I can try to run that on the Penryn Xeons with GCN GPUs?

Where can I find Mauro Rossi's builds?

I believe he used to run a web site 'tabletsx86.org' but that seems gone these days.

[Thomas B. Prost]

Where can I find their 32-bit ISO ?

[Somebody]

I'm not particularly fond of the Remix angle, but if you can squeeze ANY kind of source code out of them, I suppose it would at least be worth looking at. It is fortunate that the "real meat" of Remix, which is the floating windows UI, is completely redundant now, since it actually a real feature of Android N. Its a fairly easy job to enable it on a Nexus running the preview build.

I do NOT like the idea of them trying to capture people with their CLOSED SOURCE code, it is counterproductive in the grand scheme of things, and ALWAYS leads to "dark ages". The catholic church controlled all knowledge during the original dark ages, then it was microsoft later on. Now these guys -- no thanks.

On Wednesday, February 24, 2016 at 8:01:00 AM UTC-5, Chih-Wei Huang wrote:

[Miker1029]

LOL!

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.

[Chih-Wei Huang]

2016-03-23 3:40 GMT+08:00 Somebody <defines...@gmail.com>:
> I'm not particularly fond of the Remix angle, but if you can squeeze ANY
> kind of source code out of them, I suppose it would at least be worth
> looking at. It is fortunate that the "real meat" of Remix, which is the
> floating windows UI, is completely redundant now, since it actually a real
> feature of Android N. Its a fairly easy job to enable it on a Nexus running
> the preview build.
>
> I do NOT like the idea of them trying to capture people with their CLOSED
> SOURCE code, it is counterproductive in the grand scheme of things, and
> ALWAYS leads to "dark ages". The catholic church controlled all knowledge
> during the original dark ages, then it was microsoft later on. Now these
> guys -- no thanks.

Are you a free and open source software fanaticism
who insists all software must be open source?
If yes, don't use any Android device.
Android ecosystem is never open sourced.
Most Android apps include GMS (Google Play, Gmail, Youtube, ...)
are not open source. Do you use them?

Remix OS is just a customized Android system
like all android vendors do (Samsung, HTC, Huiwei, ...).
Do you use any of these Android phone or tablet?
You use them if you like or don't use them if you dislike.
How can they "capture" you?
None of the vendors release their source code
(except the GPL components) so far.
Does it lead to the "dark ages"?
You exaggerate it too much!

Android-x86 is and will continue to be an open source project.
Jide commits to improve Android-x86 and its ecosystem.
They will contribute all improvements in the BSP level to
Android-x86. Some of them have already been pushed to
Android-x86 codebase and more will come in the future.
Please note that will benefit all their competitors as well.
They understand the point very well and still decide to do so
because they want to promote Android desktop and make
the market bigger. They even welcome more competitors
to join to make the market bigger since they think it's big
enough to hold more competitors.

I appreciate their contributions because that's a good will.
The are not obliged to do so.
You may say that's just a business decision. I agree.
But that doesn't erase the benefits we get.

Even if you don't appreciate their contributions,
please don't attack them by misleading information.
There is no point to attack Jide to close source some of
their improvements because that's also another
business decision like all vendors do
including Google, Samsung, etc.

[Thisara Kasun]

If someone didn't notice,Jide's open source code can be found at https://github.com/JideTechnology. You can check the 4.4 kernel there in https://github.com/JideTechnology/remixos-kernel/tree/jide_x86_lollipop_kernel-4.4.

[mike...@android-x86.net]

Cp will love you for that lol just sayn.

Sent with AquaMail for Android
http://www.aqua-mail.com

[dgdn]

he wouldn't know what to do with it if it hit him over the head.......scammers don't lie and liars don't scam!!!

[Hypo Turtle]

Jide seems to have pulled their source; that they weren't keeping updated with OTAs anyway.

There's just a cloned repo available on github (JideTechnology)

[Kostika Pllaha]

> --
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org

i am trying it in my Fujitsu stylistic Q550 but i seems it doesnt work very well. keyboard doesnt work also is very slow. can you recommend me something?

[TheKit]

Hi,

Is it possible to request kernel source code of http://www.jide.com/remixos/devices/teclastx98plus from them?

[Chih-Wei Huang]

It's unrelated to android-x86 or the partnership.
But I'll talk to them.
Theoretically all the kernel source should be released.

[Somebody]

Call it whatever you like, but if you can't *READ* the code, you can't *TRUST* the code.

[Chih-Wei Huang]

2016-05-20 23:35 GMT+08:00 Somebody <defines...@gmail.com>:
> Call it whatever you like, but if you can't *READ* the code, you can't
> *TRUST* the code.

This argument is also applied to any closed source
Android ROM like Google Nexus (Play Service)
Samsung, HTC, Huiwei, etc.

Let me explain it more clearly.
The partnership just means Jide commits to help
the android-x86 development including
code contributions and other donations which
will be announced in the near future.
From the point of view of android-x86 community,
it is good enough for us. Nothing else.

I only care the code they contributed to the community.
I don't mind or care their closed source code.
I don't even ask you to trust or use the image
they released -- it's nothing to do with the partnership.

[TheKit]

Got any response or reasoning from them? I understand that it's not directly related to android-x86 and they will probably point fingers at hardware manufacturers, but if they have access to kernel source code, even few drivers would greatly help in getting alternative OSes running on those tablets (such as Sailfish OS).

понедельник, 16 мая 2016 г., 19:24:33 UTC+8 пользователь Chih-Wei Huang написал: