Colorful week

[mius]

I fail to see how a rational sane individual can watch that whole video and still claim that they NEED MOOAAARR RAM!!!!.

That's because you confuse quantity for quality. The video is useless to me as it just shows someone opening a lot of to me utterly irrelevant appz for a while. As I said, do some real work for an hour with the setup I described.

The knowledge/note applications should be intelligent enough to load the page you're on +/- 10 or so pages into RAM then dynamically scroll while reading the rest of the data file from, "disk", which at roughly 100+MB/s on the eMMC or 50+MB/s on the SD slots, should feel more or less instantaneous compared to the initial page load (networking) at roughly 3MB/s on WiFi or half that on 4G.

I'd prefer to disable swaps when possible for the reasons stevenc99 mentioned. That is obviously helped along when I'm provided with sufficient... say after me... RAM.

Furthermore, I have to work with available applications and therefore deal with their own idiosyncracies. Filling-up a big enough TiddlyWiki within the already augmented browser for example can get problematic quite quick, especially when figuring in plug-ins, e.g. for data visualization, as well as embedded multimedia content. The only alternative around that is running the application via the node.js runtime environment, which allows you to store all data nodes, including their contents, as files. Or, ideally, just running something more capable. Nothing there on Linux though as far as I know, outside of web-based stuff, Org-mode, and the less popular LEO that is.

And, last but not least, I have to keep the future in mind. After all we're talking about a UMPC from a small outfit, and not a device fueled by ze big biz juice.

So - great! We're getting Pyras with 4GB of RAM.

Thems words worth a gong.

 

[Djoga'Ro]

Actual tests done by actual devs on actual hardware that VERY closely resembles the Pyra have shown that the OMAP 5 becomes the bottleneck before 2GB of RAM usage.

Real world tests. Not based on belief. Right tools performing right job using components sized properly for each other. It does not have to be difficult or based on guessing, wishing, faith or a specs chase.

In the meantime your expert himself stated, that he wasn't covering all use cases and that there may very well be more demanding ones regarding RAM.

You're comparing:
N900, using an OMAP 3430 SoC with 256MB of RAM and it's slow 2009 era eMMC being used as /SWAP.
Pyra, using an OMAP 5430 SoC with 2GB of RAM and it's roughly 4X+ faster 2015 eMMC being unneeded as /SWAP.

Yes, the N900s 256MB of RAM was limiting. They 2GB Pyra has 8 times as much, much faster RAM with an eMMC that should outperform the one in the N900 by a factor of 5-10.

"Four times faster Storage, oh my gosh. RAM, what do you say? Do you fear, they'll get you soon?" - "What? You mean they actually entered the race? I thought those guys were spectators, standing around all day looking stupid."

What then, exactly, is your requirement for 4GB of RAM that cannot be done on a 2GB Pyra but is a suitable task for a mobile device?

If you, 'wouldn't have pre-ordered at all' without a 4GB option, then you clearly don't actually understand the Pyra or the hardware it contains. The OMAP 5 pairs very well to 2GB. Although 4GB or even 8GB are theoretical possibilities, they're not really all that beneficial as the RAM capacity outpaces the SoC's processing capability. Linux, as you are aware, is far more resource optimized than Windows - which removes the perceived necessity for large amounts of RAM on this device.

RAM outpacing the CPU? What are u talking about? They have entirely different jobs. Well, there's L1 cache, but please don't compare DDR4 to the 286's cache - doesn't help here.

So your argument for needing more RAM is that you desire to use RAM very inefficiently for caching web sites - the opening of which will require large amounts of data download - which would be the true bottleneck of your web applications. Most web browsers will gobble up available RAM to essentially cache things (against the network stack) that, in many cases, would be better or effectively the same to cache to storage, which they will use if RAM becomes short.

Firefox: "Oh wait, I guess that other process over there got something far more important to do with the RAM than stupid old me. Let's write to disk."
I don't see that happening.

Caching to disk on a modern flash based device like the Pyra is nothing like caching to spinning disks was in the 90s or even the Pandora's 20MB/s SD slots. Modern storage is freekin' fast.

Against RAM modern storage is freakin' slow.

If you have a bunch of images sitting in more or less static RAM you'll use a bunch of RAM, but you're not really processing against it, so those static images may as well be cached by the browser to the more energy efficient though slower - but still so fast that it feels more or less instantaneous - eMMC instead.

I cannot tell the difference between one image being loaded from SSD or already sitting in RAM, especially when I blink, I give you that. So, if that's all you have your computer do - processing one image at a time with pauses inbetween and doing nothing else in parallel - you're fine. And since we all gotta do, what Grench does, we're all fine.

Optimist, glass half full. Pessimist, glass half empty. Engineer, glass is twice as big as it needs to be.

Pyra user fills up the glass.

 

[dsblackout]

Against modern storage, SD cards are freakin' slow. Even spinny disks, though that only really applies to large single writes. Firefox I'll attest to as being a hideous RAM hog, typically occupying an OBSCENE portion of my memory regardless of how much I have--typically ~2GB with plugins loaded and only a few tabs.

 

[pyrat]

Well, more seriously this morning.

Note to self (and whoever wants it): One reason to preorder the Pyra was the specs. Another one was a sentence saying they'll delay if they need to to ensure quality. I hope they deliver in both.
There're plenty of devices rushed to the shops to keep the frantic market happy at any cost. I didn't choose one of those for a reason. If they have to deliver a Pyra with less RAM than promised
(though RAM is not a good example since it was in a disclaimer) or badly tested to get it on time, I don't want it.
So even for choices I don't agree with, I think the only reasonable thing is to fulfill them once you got some money bound to them. I'm not expert enough to judge some choices or some delays.
But I know that revisiting choices already agreed to by buyers, and then complaining of delays works against me. The Pyra is going to last for a long time, and it has been prepared for a long time,
and taken many hours from many people. A few more months more or less is still little in comparison.

In any job, the customer wants as much as it can get for his money, and the worker as much money as he can get for his work.
So the economic incentive for the seller is not to delay. The only reason for the seller to delay is getting something good enough to keep the promised sales and as many more as possible.
If the buyers start complaining of delays they just create the impression that deadlines are more important than quality or features. For optional features such as RAM this could just delay
some of the options and not others, but overall, the ones less rationally interested in creating pressure to rush are the buyers.

If in this thread everybody agreed that 4 months delay is terrible we're just turning down a present "no, please, experts, don't work for me four more months for the same price". Next time a component can't be sourced or a result proves suboptimal, or a driver isn't finished preventing some minor feature test, we're creating the psycological incentive to deliver an inferior product because we're expressing great aversion to delays. The closer to demanding deadlines we are the further to demand quality. Quality is a motivation for developers. Money can be a (usually antagonic) motivation, and surely is a need. But nobody is an island and if
you sense your motivation is contrary to that of the people paying you, you're likely to adapt. Let's try not to demotivate.

So by all means let's give input to any yet to decide questions (colors or anything), let's ask and try to understand taken decisions, but let's think twice before building consensus on delay aversion.
It's just irrational from a buyer's point of view. Patience is low cost and very effective.


The counter arguments are: interest on downpayments (but interest is low nowadays), obsolescence if it takes too long to market (less relevant for open products minimizing network effects, with long life and less competition), compponents running out of supply (this is maybe the stronger when it applies), and risks of insolvency after paying salaries for longer (which the sellers are in a better position to judge, but for the buyers is ultimately a matter of trust).

 

[Klumpen]

Found the hipster!

For the average guy we are all hipsters or at least proto-hipsters (the ones that try to kickstart what's hip tomorrow).

 

[Agricola]

Okay, now that we are done with this topic and the Grench-bashing which got a little out of hand at the end, we can get back to more important things, like:

- Which colour is the best?
- Are we all okay with the keyboard layout? Are we really?

My god, this thread got burned to the ground... And it started out so promising!

 

[rygD]

Dark red, dark grey, or black for me, most likely. Since we are already getting black or dark grey, I tentatively vote for dark red as the second choice. Since it kinda seems like that is what ED might be leaning toward, I need to see pics of the prototype cases.

Less words, more pics!
[doublepost=1465377356,1465377236][/doublepost]Oh, and as one of the people that helped keep keyboard discussions going for so long, yes, I am pretty pleased with the layout. It isn't prefect but it seems to be a decent compromise. Sucks that we had to leave some languages out, though.

 

[pyrat]

Okay, now that we are done with this topic and the Grench-bashing which got a little out of hand at the end, we can get back to more important things, like:

- Which colour is the best?

I don't care. I usually like black, but I'm waiting for images of the cases to see if some other color surprises me.
There are very few colors I wouldn't like.

- Are we all okay with the keyboard layout? Are we really?

Edit: I meant this tongue-in-cheek, as a joke:

I'm told it's not really useful to reopen, since it takes 10000 EUR for a diferent layout, 1000 units and lots of arguments.
I'd love (but I don't see it as feasible) to keep some customization options open for indivdual users. I just don't think it is worth it or easy.

• You could put epaper tags on top of every key (and cabling) so that when you remap (or press a modifier) you can change the caption in the key. But that would be _very_ expensive if possible at all. Absolutely unjustified.
  
• Or imagine you could laser cut every clear keycap top leaving a horizontal slot at its middle to allow to slide in a piece of transparency paper or some film you have printed with your key captions. This could be both expensive, mecanically risky and maybe introduce optical artifacts at some angles. Maybe if this was designed from the start it'd made some sense.
• Maybe you could paint the mat with some light sensitive paint so that later you can draw on it though the clear key caps with a laser pointer. Sounds like easy to degrade if at all possible.
  
• Ok, two options with lasers, now I should add an option with sharks... Is the Pyra water proof ?

 

[Agricola]

Am I this bad with irony?

I think I'm gonna take a break from these forums for a few days, I have to get some time to process the fact that I may have restarted the keyboard discussion*.

*In case you were involved in that discussion and have contributed to the final layout, I salute you. Fine work. But please understand that many, if not most people on these forums, me included, were not able to read a single thread about this without getting a major headache, are happy it's done and don't want to see it again before the P3 is seriously discussed.

 

[ZXDunny]

Look, guys. I'm gonna be using the Pyra to emulate the Sinclair Spectrum, and possibly a C64 at best. I need 4GB of RAM. Just make it happen, ED.

 

[ible]

^speaking of P3, let's get started on the keyboard layout!

(or wait, did that not qualify as serious discussion?)

 

[Grench]

Okay, now that we are done with this topic and the Grench-bashing which got a little out of hand at the end, we can get back to more important things, like:

- Which colour is the best?
- Are we all okay with the keyboard layout? Are we really?

My god, this thread got burned to the ground... And it started out so promising!

Hmm...

I may have been the first - or at least one of the first - to float the idea of dark red.

I definitely had input on and ideas included in the keyboard layout.

Neither of those topics would necessarily exclude Grench-bashing. Grench bashing may even be a more efficient option to move the conversation along. However, that should probably be in an off-topic thread and definitely violates the forum rules regarding maintaining a modicum of decency somewhere short of name calling.

I'm pretty thick skinned though and found the above 'bashing' amusing. It's simply wildly off-topic and unnecessary attempts to dehumanize an opponent in a technical debate.

As to the technical argument, I think that the @TrashyMG video shows quite clearly how effective 2GB of RAM is in a Pyra-like platform. Attempts to belittle or dismiss that show that the arguments for "Need Moaaarr!" have become more like faith-based declarations than pragmatic fact based evaluation.

How these things usually work is that someone declares they need X spec to do Y work. A demonstration is made of Y being done with X-Z spec. The spec chasers then change the definition of Y and demand that their new-found even more outlandish or misunderstood needs be met. This is how a project starts chasing it's tail until it runs out of funds.

I am glad that @EvilDragon has planned a path forward and look forward to continued progress reports.

 

[fusion_power]

Yes, but it will still look slow on the prototype, as hns didn't have the time to finish debugging the rotator kernel driver. Without it, graphics output will be a lot slower.

The Rotator-chip is still not "finished" to work? I thought all issues were solved months ago... Really, what the hell is goning on with that stupid little thing?

 

[TrashyMG]

The Rotator-chip is still not "finished" to work? I thought all issues were solved months ago... Really, what the hell is goning on with that stupid little thing?

It works from what I gathered from the notes, just needs a proper way of initializing it that isn't a kludgey mess. I'd rather have the proper kernel work being done, than some hacky script thrown in.

 

[fusion_power]

Still alot to mess with for a chip that basicly only has to swap X and Y screen coordinates...
And with "work" I actualy meant: "working 100% as intended, without any issues".

 

[TrashyMG]

Still alot to mess with for a chip that basicly only has to swap X and Y screen coordinates...
And with "work" I actualy meant: "working 100% as intended, without any issues".

The chip is actually can do scaling as well, but yeah It's more of an issue that hns is working pretty much on his own on this until units get to other devs.

 

[dsblackout]

• Or imagine you could laser cut every clear keycap top leaving a horizontal slot at its middle to allow to slide in a piece of transparency paper or some film you have printed with your key captions. This could be both expensive, mecanically risky and maybe introduce optical artifacts at some angles. Maybe if this was designed from the start it'd made some sense.

That might actually end up being halfway doable after a fashion, making a custom sandwich of contact layer>paper>keycap layer, depending on exactly how much space there is between the mainboard and the inner shell. Yeah, you get rid of the backlight's effectiveness doing that.

 

[Swordfish II]

Hmm... my old x86 work machine (C2D, 2 GB RAM) capitulated much, much sooner because of insufficient memory than CPU load due to browsing. And before you ask, the number of open tabs was not that relevant in my use case, but what types of website I browsed.


Here's what I would have in mind: Run the following setup, as an example of ultramobile laptop replacement, on an external monitor:

First, start your capable browser to:
1) work two very image-heavy Twitter feeds,
2) maybe a third tab for working with Google street maps (street view!), and
3) another tab or two for communication (e.g. e-mail, forums, social media).

All the while, 4) having a knowledgebase/note taking application à la Org-mode (stand-alone) or TiddlyWiki (in another browser tab, running on node.js) on stand-by, while you 5) periodically keep a couple of pdf and epub files of typical sizes open for a while as well, e.g. files in the range from 5 MB to 200 MB.

Run the above setup for at least half an hour to an hour and do (simulate) some real work with it. Phase out nos. 1, 2 and 5 if necessary as they can be stress tests on their own.

Or do them one at a time, or two at a time because I doubt you are actually using them each constantly

 

[rygD]

Here we go with the "browse how I say" stuff again. Some of us like having many tabs, as they are more convenient. That is why tabs are present in so many browsers now.

And, yes, sometimes you do need multiple references at once. As for Twitter and email, some people like replying quickly.

 

[Klumpen]

pics plz