On marketing and buzzwords

[SNESFAN]

Mcobit quoted basically what i was reading.


My friend is a huge virtual guy, its what he does for his server farm. We got in a conversation about running arm based servers due to power efficiency and he was bringing up the virtualization thing in the a15s and he seemed pretty excited about it.


I hadnt thought about how it would impact gpu, and if you had to share that out or run that back through the most i could see that adding layers of fat and if you wanted the most out of your hardware you would want exclusive access im sure. With servers most of the time they run idle visually thats why its benificial there.


Do gpus even offer virtualization support like the cpu i wonder?


With both os's "sharing" the same kernel in ram that would remove one layer as the kernel stays pretty static once loaded into memory right? But that wouldnt effect gpu access would it? Sharing the same drivers and all


Sent from my MB612 using Tapatalk 2

 

[Batou456]

Omap5 will have 2 additional M4 cores and two other dedicated chips for stuff to be offloaded to them by the System.

What are you talking about?

The DSP is basically the exact same thing in the OMAP3 with the throttle probably opened a little more. The Cortex M4s are microcontrollers that ARMH notes are good for signal processing, but noted ISA support revolves around Thumb ISAs instead of the ARMv7 ISA, aka not exactly suited to idling the OS on. Given there are dedicated audio, 2D GPU, and 3D GPU processors, and a Pandora Mk. 2 isn't likely to have an integrated cellular modem exactly what are you expecting the M4s and unspecified elements to assist with that will make a major difference? The physical controls and touch screen aren't exactly taxing current processing resources.


You're not exactly basing your argument on the basis of the spectre of not getting access to the kernel modules to utilize the NEONs or GPUs in a timely manner.

Of course this will make sense, if you use something like android, which was tuned to use them.

Okay I'll bite. How do you "tune" a Java OS stack? Linaro supports GNU/Linux so they're a neutral factor in this comparison.

A normal linux distribution might be much slower on such a soc, as it can't use all the features out of the box and there will be no software using them, just like the dsp in the current Pandora.

This seems to be based on a premise you didn't really do the homework on. Please point at what you're talking about from the diagram and tell me I'm wrong, but I see no legitimate basis for this claim.

GNU/Linux is designed to run servers and supercomputers for maximum performance and takes advantage of C++. Android/Linux is designed to run limited devices on a Java stack with a lot of Java applications. One of these is innately more efficient then the other, and it's not the one you're arguing for.


[-]


Also what's this about OMAP5 not being low power, and thus suited? TI is specifically lists they're using a 28nm LP process and the 5430 model is for smartphone and tablet applications. Is there some "ha, ha we fooled you" bit of the Texas Instruments product page I'm missing? Otherwise based on what ARMH says and TI says we can pretty much assume the A15 cores should normally clock up to 1.5GHz, with the option of 2GHz+ for those wanting a hand warmer that depletes the battery rapidly.


[-]


TI already said their demo involved them running off the same kernel. And there's this other group, that other group, and the KVM/ARM people indicated they effectively did the same thing. The question would seem to be whether you have an entirely seperate hypervisor running both, or one playing hypervisor and the other playing guest OS.

 

[mcobit]

Ok, i'm not much into soc hardware stuff, it was just what I thought I understand from reading TIs specifictions for the omap5

 

[Tom`]

Back-burnering the Android discussion for a moment: to return to the original thread topic ( )... how important is marketability?


Personally my first inclination is always against this sort of thing. We have here a community of people who already know about the Pandora, and even those who didn't buy one for whatever reason (or canceled their orders after the long wait) will not need dedicated marketing efforts, which will cost more money and add development time for little tangible benefit.


But I have been absent from these boards for some time, and I did not see that Craig had decided to increase the price to $700 until last night.


Now, if that's what has to be done to ensure a quality product, and fix the problems with manufacturing the P1, then so be it. I don't know that I'll be able to afford it, but if I can, I'll buy it.


It's less certain, though, that the majority of people willing to pay $330 or $500 on a gaming console will pay $700, however. What proportion of the customers who buy $200 smartphones on contract would buy the same phone for $600 unlocked? Some do, certainly, but while I don't have any data on this, speaking relatively, I don't think the number is very high.


Given that, perhaps it might be worth marketing this to the people who have proven themselves willing to buy the latest and shiniest gadget. And to do this, we might need Android.


I have been opposed to OP spending significant effort on an Android port in the past. Everything that Exophase says about Android in this thread is correct. It's not a GNU/Linux system (I have argued in favor of the "GNU nomenclature" in the past, either here or at GP32X, and while it might not have been as important in a time when most Linux systems were GNU systems, in the presence of incompatible systems using the Linux kernel, it becomes necessary to make the demarcation clear). I would not use it as my main OS.


Nevertheless, having a standard OS with which the general public is already familiar could be a necessary part of such a marketing effort, provided a standard GNU/Linux environment is also available.


The question becomes, then, will there be enough OS developers (who are willing to put up with working for Craig for free) to make this happen?

 

[Grench]

What proportion of the customers who buy $200 smartphones on contract would buy the same phone for $600 unlocked? Some do, certainly, but while I don't have any data on this, speaking relatively, I don't think the number is very high.

I would if that were truly a legitimate option in the US. Unfortunately, even if you walk in the door with your own phone, most US carriers will still charge you the same monthly fees as they charge customers who buy their subsidized phone. They don't have, "bring your own phone," pricing.

 

[_wb_]

Nevertheless, having a standard OS with which the general public is already familiar could be a necessary part of such a marketing effort, provided a standard GNU/Linux environment is also available.


The question becomes, then, will there be enough OS developers (who are willing to put up with working for Craig for free) to make this happen?

Ideally, the P2 hardware would be sufficiently backwards compatible to the P1 hardware to allow both of them to run the same OS (or at least the same basic OS, with perhaps some extras for the P2 since it will most likely have more internal storage). This would give the P2 immediately a polished OS, and it would give P1 users long term support since they would still get upgrades and new software. The P2 should be able to run PNDs made for the P1, but I can imagine that there could be a PND 2.0 format that only works on the P2, not the P1, maybe because the software inside it has some library dependencies that are too huge to include, or simply because the software requires the superior hardware of the P2. New games etc. could be designed to run on both the P1 and the P2, but maybe at a higher resolution on the P2.


"Working for Craig for free" is not how I would put it, since the P2 should be a community project, and the community > only Craig.

 

[diligentcircle]

A new PND format for the P2 would be unnecessary. An internal MicroSD card should have sufficient storage to properly install programs, no need to put them on external media. Support for PND should be for backwards-compatibility only.

 

[_wb_]

I still like the PND system to be able to easily exchange and organize software. The internal storage will be big enough to store whatever applications you want to use regularly (e.g. things like movie players or web browsers will probably no longer be in PNDs). However, for games, it is likely that the internal storage will not be sufficient if you want to have lots of different games. For the Pandora 1, Wesnoth is probably one of the largest games (GCompris is also pretty large). For the P2, it is likely that the games will be significantly larger since they will need higher resolution artwork, etc. You will still want to use external SD cards for those large games.

 

[mcobit]

Also for pandora optimized stuff, that needs special libs and stuff, the pndsystem makes sense as it doesn't touch the main system.


With a pandora ipk repository everybody installs from, there could be some mix up of additional files or even programs, that will be pulled as dependencies into the internal storage.


Of course this can get worked around but it might be more work as doing it wih pnds.

 

[diligentcircle]

Size is not going to be an issue. Installing properly in a Unix fashion can take less space than PNDs as well, because programs don't have to bundle dependencies (which results in the same program being copied to multiple places). 16 GB is more than enough for a regular user, I don't see how 32 GB doesn't cut it; note that Battle for Wesnoth is gigantic at a size of 320 MiB; most programs don't come even close to that. Yet you can fit almost 100 of these on a 32 GB card.


Also, there's no reason to believe games will be larger on the P2 than on a regular PC running GNU/Linux. I've never needed more than 8 GB for that, and I usually partition my hard drive to assign 16 GB to root (with home on a separate partition). I may not be a heavy user, but I don't see how 32 GB won't be enough for most people to put programs on.


The easy exchange of software argument is silly; that's what packages (e.g. .deb, rpm) are for.


The organization argument makes sense sort of, and it can also allow you to try software without installing it, so I can see a couple reasons for keeping a PND-like format as an option.

 

[ghostpatch]

Correct me if I'm wrong, but a repository needs maintenance and you can't just submit programs. Of course you can just get a program from a different source or use the shell. But that is rather complicated for everyone without linux knowledge. PNDs make it possible to easily use or kick a program without affecting the OS. I think thats cool! And you can't damage anything. Also everybody can create PNDs and upload them to the Repo. That makes it easier to use.

 

[_wb_]

onpon4: I agree that 32GB is "enough for everybody" _at the moment_. Things could change in a few years though. Always be careful with statements that say <size> is enough for everybody. The Pandora actually needs more than 640KB of RAM

 

[ekianjo]

onpon4: I agree that 32GB is "enough for everybody" _at the moment_. Things could change in a few years though. Always be careful with statements that say <size> is enough for everybody. The Pandora actually needs more than 640KB of RAM

Its not a good approach to consider whats enough now to plan for the future needs


You should never be satisfied with space, because space is cheap. At least on full size SD cards.

 

[diligentcircle]

onpon4: I agree that 32GB is "enough for everybody" _at the moment_. Things could change in a few years though. Always be careful with statements that say <size> is enough for everybody. The Pandora actually needs more than 640KB of RAM

I thought that's what a micro SD card for internal storage was for? I doubt our needs for space for programs will grow faster than the capacity of the cards.

 

[_wb_]

Yes, but even with huge internal storage, some people will still manage to need more than that, and having easily swappable full SD cards helps a lot. And it makes no sense that e.g. your PlayStation roms are easy to swap, but the native games aren't because you're supposed to install them to the internal storage.


So I agree that you will probably want to install most stuff in the filesystem on the internal storage. But it's still convenient to have something like the PND system too. Ideally there would be automatic translation between PND and opkg package, so you can choose for everything whether you want it installed in your filesystem, or as a PND.

 

[Batou456]

A new PND format for the P2 would be unnecessary. An internal MicroSD card should have sufficient storage to properly install programs, no need to put them on external media. Support for PND should be for backwards-compatibility only.

Dependencies of this statement:


1) Pandora Mk. 2 is designed around an internal MicroSD card.


2) This microSD has sufficient capacity it can be utilized in the fashion of a primary hard drive without the need for expandability beyond the storage of files.


3) All users are happy with such an arrangement, instead of the flexibility the existing one provides.


The last I saw from EvilDragon was they were favoring having an internal NAND again, due to the speed advantage breaking dependency 1 and the entire stack. I don't agree with 2 or 3 being valid. Let me give you an example why:


One of the most significant emphasi of this device is handling game applications designed for other platforms. The current version already supports games which have gigabytes worth of files that have to be dropped in, and a Pandora Mk. 2 should allow for things like Return to Castle Wolfenstein, Doom 3 and Quake 4 to be handled natively on the ported IdTech4 engine that's had it's source code released and projects are addressing.


Unless you think you can setup some very interesting standardized structures referencing the normal card slots for this data, which would also need to be easier to use then PNDs in order to justify the move, this in turn creates a need for PND packages or an evolution of them in order to be able to actually fill its primary functions because 32GB, etc. is _not_ enough. It's better to keep things open and flexible then play to the folly associated with the false quote of Bill Gates. Incidentally not only has he repeatedly denied saying that, but the 640k ceiling was actually the result of a hardware limitation of the 8088's ability to address memory.

Ideally, the P2 hardware would be sufficiently backwards compatible to the P1 hardware to allow both of them to run the same OS (or at least the same basic OS, with perhaps some extras for the P2 since it will most likely have more internal storage). This would give the P2 immediately a polished OS, and it would give P1 users long term support since they would still get upgrades and new software.

Why would this be an issue?

The only time GNU/Linux was architecture dependent was way, way back when it was built around the 386/486. Angstrom, which the Pandora distro is forked from, supports all these ARM Devices. The ARM stuff has been integrated into the main kernel at this point, so I don't see why you'd think this could even be an issue with the actual OS. If you were talking about making sure to get the driver modules/blobs to plug into the kernel from the SoC vendor, that is an issue but one on an entirely different tangent.


Even if you meant applications or Desktop Environments, as far as I've seen it's the rare application that's using low level programming. let alone low level programming that's unique to OMAP3. In general terms, it's not exactly like it's the DOS era anymore. Multiplatform languages, libraries, and APIs have been a standard of OS design since the mid-90s and GNU/Linux in particular has builds for virtually every architecture that's ever existed and ARM related isn't _that_ lacking in commits.


No disrespect meant to EvilDragon and associated, but there is an upstream and larger ecosystem involved in all this.

 

[_wb_]

Ideally, the P2 hardware would be sufficiently backwards compatible to the P1 hardware to allow both of them to run the same OS (or at least the same basic OS, with perhaps some extras for the P2 since it will most likely have more internal storage). This would give the P2 immediately a polished OS, and it would give P1 users long term support since they would still get upgrades and new software.

Why would this be an issue?

The only time GNU/Linux was architecture dependent was way, way back when it was built around the 386/486. Angstrom, which the Pandora distro is forked from, supports all these ARM Devices. The ARM stuff has been integrated into the main kernel at this point, so I don't see why you'd think this could even be an issue with the actual OS. If you were talking about making sure to get the driver modules/blobs to plug into the kernel from the SoC vendor, that is an issue but one on an entirely different tangent.


Even if you meant applications or Desktop Environments, as far as I've seen it's the rare application that's using low level programming. let alone low level programming that's unique to OMAP3. In general terms, it's not exactly like it's the DOS era anymore. Multiplatform languages, libraries, and APIs have been a standard of OS design since the mid-90s and GNU/Linux in particular has builds for virtually every architecture that's ever existed and ARM related isn't _that_ lacking in commits.


No disrespect meant to EvilDragon and associated, but there is an upstream and larger ecosystem involved in all this.

Yes of course, all what you said is true and in that respect there is no issue at all. I was mostly talking about the Pandora-specific stuff, in particular the PND system.


It would be nice if the P2 can natively run PNDs made for the P1, which would require backwards compatibility in terms of binaries. It should not be a big problem, since the P2 will most likely use an ARM processor which will most likely be backwards compatible with the previous generation. And even if recompiles are required, it would not be a huge problem for me, but it would be a bit inconvenient.

 

[Tom`]

Yes, Pandora software should easily run on the P2, whether unmodified or requiring a recompile, if the software environment is the same.


That's not to say, however, that the OS would be able to run on the P2 without significant modification. A tremendous amount of work has been done to support Pandora-specific hardware - the wi-fi chip, the sound system, everything involved in suspend-to-RAM, the SD card interface and I don't know how many kernel bugs, as well as non-kernel work like hardware acceleration for SDL... I'm sure there's much more that I'm missing, since I haven't followed development much. The point is that this would have to be duplicated for a new system. It's not like you can boot a mainline kernel and have everything just work (although the situation is probably better than it was in 2008).


Briefly, the assumption that current Pandora software will immediately be available on the P2 is not valid without a lot of work on the part of the OS developers to make it happen. My concern is that Craig has alienated at least some of the original developers, and that he (as well as other people here) underestimate the importance of software - in particular the underlying system software, not just applications - and the amount of work that goes into polishing the software.

 

[Binky]

1) How would this differentiate itself from OUYA, if we're just talking about the gaming component alone (really, OUYA does have a catchy strategy - and this is now a competitor to P1/2 in this regard)? 2) If P2 runs Android, why do we need a P2... instead just pair an iCP2 with our Android device?

OUYA isn't a handheld/pocket device - is purely for entertainment


The P2 MUST run real linux of some flavour. Out of the box. Fully supported by Ed and Craig. Else the best half of the customer base goes out the window. Android is great too, but inadequate on its own.

Has OPT ever considered working with or merging ideas with other small startups (ie: ouya developers) to bring another product to the table?

Humm... A collaboration with ouya, openmoko (or successors), or the nanonote people might yield some very high-concentration essence of awesome.

 

[overgauss]

.