What would the world and his dog think if P2 used an x86 SOC? (but not mini SD) ;)

[God Ginrai]

Actually, Firefox uses most of its memory up front. 2.5k tabs only takes up ~2GB of memory when combined w/ the Bartab extension. W/o Bartab, I've got FF on another computer using 1.2GB of memory w/ 473 tabs.

You're talking as if this isn't extremely dependent on what's in the tabs >_<

While the content in the tabs can effect it, I would venture to say that Mozilla has found a way to minimize it's effect. For me, Chromium w/ 20 tabs uses more memory than Firefox using 200. Firefox has a baseline that is large, and then the tabs add to it in small amounts. Whereas Chromium starts off smaller and then adds the same amount pretty much every time you create a new tab.

-God Ginrai

 

[dimag0g]

Hi all,

If we go for OMAP chip, does that mean that we will be stuck with NEON fpu which fails to support ANSI floats? I fear that with more demanding games there will be more and more of float-related bugs.

 

[dimag0g]

Why do people like Linux in such a small form factor?, same reason people would also like  Win 8 in a small form factor I'd imagine. After all , windows in a small factor are traditionally what a UMPC has been up until the Pandora.

No, people do not like GNU/Linux for the same reasons as why they like Windows. I don't like Windows at all. Most devs I know don't like Windows at all. Windows is aimed at mindless consumers.

Screw windows! I'd love to see Skype on Pandora, and to run older games with WINE. Without x86, WINE will eat battery like crazy, right?

 

[TrashyMG]

Hi all, If we go for OMAP chip, does that mean that we will be stuck with NEON fpu which fails to support ANSI floats? I fear that with more demanding games there will be more and more of float-related bugs.

The issue you linked was related to lunixbochs very experimental qemu-arm-opengl hack together..

Screw windows! I'd love to see Skype on Pandora, and to run older games with WINE. Without x86, WINE will eat battery like crazy, right?

It wouldn't eat any more battery life than any other demanding programs.


If you're suggesting we should go x86, it's not happening.. EvilDragon and a good majority of the community want to keep on the ARM platform.

 

[WizardStan]

EvilDragon and a good majority of the community want to keep on the ARM platform.

For a lot of good reasons, not the least of which is that x86 is a risk EvilDragon can't really afford to take right now: it would either blow up in his face and he would lose a lot of community/respect; or it would do extremely well and he'd have a support nightmare, forcing him to grow his company faster than logistically feasible. Much better to go with a known entity this time around, pay off his debts, grow his company slowly over a few years, and hit the big market when he can afford to.

 

[dimag0g]

The issue you linked was related to lunixbochs very experimental qemu-arm-opengl hack together..

Well, it did appear after trying to execute float-point operations in hardware instead of integer emulation.

It wouldn't eat any more battery life than any other demanding programs.

Why not? With ARM, you will either emulate the x86 instruction set, or be unable to run x86 code at all. And emulation is several times more computing-hungry than native code. Whatever performance you have in terms of MIPS/Watt (or MFLOPS/Watt) will be divided by a certain factor here.

 

[TrashyMG]

TrashyMG, on 17 Feb 2014 - 09:04 AM, said: The issue you linked was related to lunixbochs very experimental qemu-arm-opengl hack together.. Well, it did appear after trying to execute float-point operations in hardware instead of integer emulation.

He purposly loosened up the precision of the floating point calculations to try to increase speed, this causing graphical glitches an such. The OMAP5 is a much more powerful device, If re-implemented on the pyra I'd say Half-life 1 would be playable without issues.

Why not? With ARM, you will either emulate the x86 instruction set, or be unable to run x86 code at all. And emulation is several times more computing-hungry than native code. Whatever performance you have in terms of MIPS/Watt (or MFLOPS/Watt) will be divided by a certain factor here.

Only thing I meant by that is a pegged CPU is a pegged CPU.. I understand the limitations of emulation.


I don't see emulating closed sourced x86 windows (nor Linux) programs as a huge priority for an open-source orientated handheld project.

 

[destraht]

The one big thing about x86 that is super exciting for me is painless Skype.  I could really really use skype on my Pyra.  So what is the chance of Android being ported to an ARM Pyra for Skype and Google Voice to run on it?  That would be just fine if I rebooted from SD1 into Android when I'm doing businessy stuff.  I think that the Pyra devs should make some sort of Skype usage a priority under any architecture because then a certain amount of dollars goes into scratching the business nitch.

So true story I recently dropped my iPod touch 5 which I use for a backup Skype device since I develop while travelling.  So the screen is spider webbed but it still works.  So right there I have about $200 towards Pyra that I can say is outright business related.  Also the Pyra suddenly becomes this device that I will have sitting next to me at the coffeeshop most days.  Otherwise its something that I'll nerd out at home with but just far less useful.

I'd love to be able to have a Pyra running skype and then also being able to test websocket syncronization stuff without needing to alt-tab to see if the other screen is updated.  Sure I have my Nexus 7 tablet but its a real pain in the ass to use for that stuff and in reality its only good for Ok It Works On Android.  Soon I'll be switching to Qubes Linux and going this hardcore virtualization route and I may not always have the microphone wired up properly through VT-d (device virtualization) technology.  So a Pyra is an instant buy for me and I immediately get on a few long train rides from Ukraine to I go to buy a Pyra and to hopefully take ED out for a coffee.  There is nothing else out there that doesn't suck and every new system is just a fucking flat piece of glass and I can't wait for everyone to just get over that.

 

[WizardStan]

So what is the chance of Android being ported to an ARM Pyra for Skype and Google Voice to run on it?

Nearly 100% I would imagine, since all the drivers are already present. It *just* needs someone to do the work. Which is arguably the thing holding back the Pandora from having a more recent Android as well.And there's always that Dalvik Alien which should have no trouble running Skype, if ED gets a license for it.

 

[SNESFAN]

I hope they use a larger internal (microsd or emmc don't matter) so both/all can fit. A normal debian install runs 5-6gb(im sure will be trimmed down) android 4.2 clean install without google apps runs about 200mb, with is about 300mb. Angstrom + android gingerbread would have been a extremely tight squeeze on pandora 512mb if possible sacrifices would have been made. I would ultimately like to be able to choose between different OS's in a multiboot menu (Debian 6gb, Ubuntu 6gb, slack 1gb, arch 500mb, android 300mb, chromeOS 2gb etc) I'm sure there could be others so something like 16gb minimum or 32gb+ would be ideal. I feel that goal is probably a limited one and one not shared by ED and crew.

 

[Binky]

What would the world and his dog think if P2 used an x86 SOC? (but not mini SD)

Woof!

 

[slaeshjag]

A normal debian install runs 5-6gb

What? I have, without issues, installed a full debian system with a fair amount of dev libraries and program on a 4 GB /, with a few 100 MB's to spare.

 

[SNESFAN]

My estimate was based off the off the last time I installed it, that might have been including swap space. I'm not a primary Debian user so you would probably know better than me, but I would still prefer to have wiggle room and that was my point in having more than the IMO 8gb "minimum target internal size"

 

[TrashyMG]

I still have a minimal setup on my omap5 dev board debian wheezy install, but I have installed a bit of compiling tools, supporting libraries.. Also libreoffice, smplayer with codecs, GIMP and such.. and only filled a little over half of an 8gig SD card on.. so I agree on the 8GB minimum target.

trashy@gta04:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          7.3G  3.6G  3.3G  53% /

 

[kuru]

@Skype talk: is there any way to rip the skype implementation from the n900?

 

[dimag0g]

I haven't tried it yet, but doesn't skype run on pandora when you boon into Android Gingerbread?

Edit: below are some helpful links

http://boards.openpandora.org/index.php/topic/8871-how-to-install-android-on-your-pandora/

http://www.1mobile.com/search.php?keywords=skype

 

[klapse]

Imo it would be preferable to be able to run Android apps without "booting" into android. I think Alien/Dalvik provides that capability. Then android programs run alongside your standard linux ones.

 

[destraht]

Imo it would be preferable to be able to run Android apps without "booting" into android. I think Alien/Dalvik provides that capability. Then android programs run alongside your standard linux ones.

Really that would be ideal and awesome.

I'd really like to have access to the newest audio codecs as they have improved dramatically.  So the N900 Skype seems kind of meh.

 

[dimag0g]

Imo it would be preferable to be able to run Android apps without "booting" into android. I think Alien/Dalvik provides that capability. Then android programs run alongside your standard linux ones.

If I got it right, it is not something we could use right now. Otherwise yeah, it would rock.

 

[Grench]

I don't see emulating closed sourced x86 windows (nor Linux) programs as a huge priority for an open-source orientated handheld project.

This whole burst in this thread is one big necropost.

The same open-source oriented handheld project who's #1 aim is to be able to emulate closed source game consoles to play proprietary closed source games.