Frustration with development pace

[bcnaz]

@daniel

So by your reasoning the spare tire in the back of my truck is my  "MAIN TIRE"  ?  DUH..

Even before I had a Pine phone, I usually have had a spare phone in the glove compartment of my vehicle,  would that be my main phone ???

The objective 'here' is to help fellow forum members with using their Pine phones, and share what we learn.

We can contribute to the developers in different ways, some help write the software, while some contribute to the developers with cash.

Many of these developers are working for little or no pay,  So I find it very unjust and distasteful that so many just pile out their complaints.

That helps Nobody !


 >  The first Brave Heart phone went up for "Pre-order"  mid-November of 2019,  they have came a long way in a short time
        ...  even as such a small operation.

Hi @bcnaz,



I am very surprised by your tone. I do not think I was complaining. I am supporting developers as much as I can. I am a fan of PP...



And because I like PP and want this project to survive, I allow myself to raise my voice to critique all the weaknesses. 



I apologize if you felt attacked or offended.



However, I wish we could disagree on any point, and still talk about that.



I just wanted to raise a point: People call 'daily driver' to different things. For me, a daily driver is my iPhone. I carry my PP with me? yes. I call from my PP? yes. Would I take it with me without the iPhone? No. However, I take my iPhone without my PP.

You are ( o were) in a similar situation; however, you call the PP your daily driver.

That's all.



I do not like the example of the spare tire. If you get a flat tire you use another tire of the same quality. You can get a flat tire and still there is nothing wrong with the tire. Maybe a nail on the road.



However, you carry another phone because you know PP is not fully working, you know you cannot trust it as a daily driver. That is what I wanted to say. PP is not ready as a daily driver yet, but I celebrate that you and I are using it every time we can

The main reason for me to carry multiple phones, is not because one is a "Pine" phone.
   I was carrying 2 phones before I got my first Pine phone.
One smart phone and one message phone.  Out in rural areas,  I often find only one has a signal, plus the option of differing battery life per phone.
  NOTE :
   My Pine phone(s) have been more reliable than the iphone 5 I bought new a few years back, it would freeze and I could only reset it by running it dead.

[wryun]

if I could get Facebook messages on Firefox for ARM, I could probably use the Pinephone as a daily driver. unfortunately, it tells you to download the app.

On many OS on pinephone firefox useragent is made to look like you are on android device. I think that is a bad design choice because many websites give you version with less features and tell you to install android app if they detect you are using android. But you can change useragent from about:config so thats all you need to fix it. I needed to change it so i can use google drive and not get limited version of reddit that keeps telling to install app all time.

In the past, I've found that a FirefoxOS or KaiOS user agent string will get Facebook to serve a mobile site with access to messages.

[hiimtye]

that's a good tip. since switching, I've noticed a big difference in the amount of demand that desktop vs. mobile sites take. some sites let you specify m.theirsite.com but others do not.

there also seems to be a large difference in mobile sites depending on the browser you're using. the mobile site served by Facebook using the original Android agent string is completely different to the mobile site served using the desktop string and using the m.facebook.com site

[wryun]

So, experimenting just now, if you use a FirefoxOS style UA string:

Code:

Mozilla/5.0 (Mobile; rv:26.0) Gecko/83.0 Firefox/83.0

It will serve you the most recent mobile site with messages accessible in the top right. Unfortunately, with this UA google generally wants to serve you old style HTML everywhere. You may view this as a bonus.

With a KaiOS style UA string:

Code:

Mozilla/5.0 (Mobile; rv:26.0) Gecko/83.0 Firefox/83.0 KaiOS/2.6

It will serve you the _old_ facebook site (messages in the middle of the top bar). Google will serve you a more modern view (in search and gmail).

[hiimtye]

that KaiOS string is the golden ticket for me. i like the more modern but less resource hungry views.

[Zebulon Walton]

Actually I'm amazed at how well the Pinephone works, all things considered. I decided on Mobian mainly because the factory-installed Manjaro was very unstable and I run Debian or Debian derivatives on just about everything else.

I bought a Pinephone because in about a year 3G service will be discontinued here in the U.S. and my old LG flip phone will become a paperweight. Virtually all of the 4G alternatives, including "simple" phones, run Android which I do not want. So I bought the Pinephone with the understanding that it's not a finished product, gambling that maybe if I was lucky in a year's time it might work well enough for me to use when 3G goes off the air.

To my surprise, in a relatively short time with some fiddling around the Pinephone works well enough that I could start using it as my primary phone at any time, with the bonus of having a pocket-sized Linux system. I can take the SIM card out of my flip phone and it works just fine in the Pinephone. (Of course as a longtime simple phone user my needs are very basic and I don't need or want many of the features that others do.)

[kent]

the problem with PinHole (or Gnome-Camera) is that it was a last minute addition meant to address the fact that no other phone type camera apps existed. it is based on mock ups made by the GNOME team, and has a very small code base and basically no configuration. it uses libhandy which is an api that was made last minute to support gnome-camera

megapixels on the other hand is very configurable, and works using ninja. if you actually read the documentation, all of the issues that you have can be addressed by configuration (and better firmware for lower latency). take a look at the git readme:
https://git.sr.ht/~martijnbraam/megapixels

FWIW. At this point, Megapixels seems to be pretty much broken in every recent distro. Looks like it was starting to come together back in late November, but something appears to have broken the app to varying degrees across multiple platforms. So I certainly wouldn't be opposed to also having a down-and-dirty alternative that just works while everyone figures out the whiz-bang better thing.

I think the observation that started this thread is 100% accurate. In many ways the Pinephone community is running around like a chicken with it's head cut off. The obvious duplicated labor alone of different teams and individuals trying to get this one program fully working under each OS flavor is astounding. And now, whenever whatever new issue is currently breaking the program in similar ways across several distros and UIs is solved, every team will need to implement a fix in every flavor just to get each build back to where it was a month ago. If all this energy were focused on getting everything working in a single core reference OS, the project would absolutely move forward by comparative leaps and bounds.

OTOH, supporting a diversity of OS development projects is the entire point of producing this hardware platform .... so I'm not sure weather the dynamic ends up being a bug or a feature. Wanting diversity in OS selection is a double-edge sword. It probably doesn't make sense for Pine to turn around and declare a bespoke OS at this point.

My initial reaction after a couple weeks with the Pinephone ecosystem is that beyond (and adding to) the difficulties of top-level OS implementation, there have been and continue to be consistent issues with the firmware/interfaces necessary for any OS to realize full functionality of core internal hardware components. I feel this is one of the biggest limiting factors of what the larger Pinephone project can achieve. 

It isn't *really* the modem chip maker's job to provide fully baked firmware that suits the needs of every specific hardware implementation. It just isn't. Same is true for every other IC in the device. The chipmaker provides reference code. It is left to each hardware OEM to implement and optimize the provided reference code for individual use cases. The Pine team just seemingly hasn't really worked on any of the core firmware/drivers needed to support the internal device hardware. 

The current Pinephone version hit the market a bit over a year ago. The basic modem firmware is just now really coming together (and requires a manual patch process w/ a bunch of warnings and caveats). The same appears to be true for other core hardware appliances to varying degrees. That isn't to criticize Pine or anyone kicking butt making things work today, it is simply an observation of the inexorable progression of time.

We all know the Pinephone is a development platform, and I think most people purchased it without grand expectations. Personally, I am having a blast with mine. At the same time, I think almost everyone involved shares the objective of ultimately producing an end device that even a non-technical user could maintain and enjoy. Towards that objective, again, the devices are now a year older.

As technology continues to advance, the specs and capabilities of internal appliances are also advancing - along with user baseline functionality expectations. Pine has already previewed their next-gen SoC core. When that core makes it onto a phone MB, will that MB have the same modem/camera/etc. as the current phone? Or will Pine go with components that implement 5G/more capabilities/etc.? I certainly hope it's the latter, but it's a bit disheartening to realize work on the base firmware to make the next edition run won't even *begin* until that device has been mass produced and hits the hands of end developers. 

How does the software side ever possibly catch up before the hardware is obsolete?

A great phone OS is not possible if there isn't top-notch firmware running the hardware's guts. If the base isn't already rock solid, funding OS makers with no mandate to produce or improve the device's base firmware will see results limited by whatever the volunteers doing their best to improve core hardware functionality can achieve with few, if any, resources at all. 

I would love to see Pine take ownership of coordinating/maintaining the suite of Pinephone-standardized firmware needed for the hardware appliances making up the phone's internals. Similar to what others have suggested, it might be better for everyone if the percentage of sales currently being directed to top-level OS projects were instead directed to a small dedicated internal software team who could establish and maintain a relevant firmware repository. 

Pine makes logistic sense as the point to accumulate refinements in the device's internal hardware-specific code. The organization is the point of convergence for every developer working on the Pinephone hardware platform. Currently, this work is scattered in various forum posts and personal repos - with contributors often lacking a clear upstream path to provide improvements to the wider ecosystem. A common end point to consolidate improvements from the range of teams working on advancing Pinephone hardware support could move every project forward immensely. 

Additionally, staff internal to Pine would theoretically have access to the design process and prototypes to commence work on firmware for a next-gen Pinephone well before the device is mass produced and released to the community at large. Pine engineers could start working on firmware with chips on a breadboard. An external community simply can't do that - no matter how large, talented, or dedicated the community is. An investment by Pine in this area would provide a significant head start over waiting until hardware mass distribution for the work begin in earnest. 

Any way it goes, I like the Pinephone being a neutral platform and don't think Pine should try to maintain an OS. That said, in every other instance, maintaining the hardware interface stack is a hardware OEM's responsibility. The Pinephone ecosystem having a black hole in this role is certainly less than helpful.