Size of the user base

[constfun]

That "platform" being of course GNU/Linux itself, which is by far the most widely used "platform" in the world, in pretty much every area except PC / desktop.[1]  Which is a more accurate / useful view, IMO.

I am just curious if you would consider Android also as a part of the "platform". After all it does use the Linux kernel and runs on a billion+ devices. Besides that is easier to build for and deploy on Android rather than Linux which is very fragmented.

Your message makes me wonder if it is easy to distribute and install applications outside of the Play store... because that's a prerequisite to a bright future. I also wonder if Android is a plain kernel or something bespoke or cut down. Can I use all of glibc?

Sadly the Android devices that people actually hold in their hands are riddled with predatory software. It takes a PhD in Infinite Menus to toggle tracking off, you'll miss most of it.

Can I run Android on the Pinephone? If not, why not? Surely if it was truly a good mobile GNU/Linux that would be the case.

[swiley]

It's not quite as as bad as all that. For a person using a home computer for general web browsing, youtube videos, and email, Linux works just fine. I've set up several that way.

That is true, I do the same. Its a pretty low bar though, since "the web" is the platform in this picture.

Flatpak and snap give some flexibility in packaging applications for differing Linux distributions.

Anecdotally, I've tried running an AppImage on Guix SD and the package did not work, failing with a missing shared library. Flatpack and snap seem to require installing something on the user's machine, perhaps some sort of runtime, before use. I'm still hopeful that one of these solutions has the magic sauce to make it all come together though.

AppImage is dynamically linked to the libc runtime which IIRC is in a different place on Guix and so it won't start.

[nas]

Can I run Android on the Pinephone? If not, why not? Surely if it was truly a good mobile GNU/Linux that would be the case.

Yes, you can.

[TRS-80]

What's wrong with yes to all these things? There is no conflict between having strong convictions about free software, working on interesting problems, having an application idea, surveying the market, working hard, and making a living by selling things you've made.

As you've astutely pointed out, I'm very much interested in ways to make money with free (freedom) software, since, first and foremost, I have a family to support. This is why the give-it-away-for-free-then-ask-for-donations model is not interesting to me.

Well, more power to you, if you can pull it off.  But it can be challenging.

Some F/LOSS developers are lucky to have a job in academia or elsewhere where their employer let them work on their pet project.  This is the case with Pandoc for instance (surely among others).  Others work at companies doing F/LOSS like Red Hat (and many others) where the company is selling some commercial product (or more likely, a service).  But you could do that yourself, as well.

As a matter of fact, funding of F/LOSS projects has been a sort of interest of mine for a long time.  I wasn't sure where you were coming from which was why I asked.  Drew DeVault has written about it on his blog a bit, he says what I said above but there will be more context and ideas there for you to ponder.

But it's hard selling the product (software) when the license specifically allows for making copies of it.[0]  Support you can sell, though, and many companies do that.

[0] There is actually nothing in the GPL preventing you from selling the software .  You just have to make sources available.  For a lot of people nowadays, it's probanly easier to pay $3 on some app store than compile it themselves and maybe this is viable (not sure).  I know Conversations for instance is few bucks on Play Store, but free if you get it from F-Droid.

That "platform" being of course GNU/Linux itself, which is by far the most widely used "platform" in the world, in pretty much every area except PC / desktop.[1]  Which is a more accurate / useful view, IMO.

I am just curious if you would consider Android also as a part of the "platform". After all it does use the Linux kernel and runs on a billion+ devices. Besides that is easier to build for and deploy on Android rather than Linux which is very fragmented.

Well to be honest, yes I was including Android in order to get to my "most used" figure (although maybe we get there without? not sure honestly).

Although in practice my experience has been that it's just close enough to real GNU/Linux to get you excited about it, but not close enough to actually do most of the things you might want to do with your device (like you can do on a regular GNU/Linux device).  Lots of little paper cuts, disallowed things, or juuuuust different enough to make them a hassle.  And it has slowly but steadily gotten worse over the years.  LineageOS not supporting VoLTE was the final straw for me[1] and that was one of the main things that made me decide to buy a PinePhone.

[1] Nothing against them, quite the contrary.  They (and CyanogenMod people before them, probably mostly the same people) made the Androd platform bearable for many years.

Your message makes me wonder if it is easy to distribute and install applications outside of the Play store... because that's a prerequisite to a bright future. I also wonder if Android is a plain kernel or something bespoke or cut down. Can I use all of glibc?

Sadly the Android devices that people actually hold in their hands are riddled with predatory software. It takes a PhD in Infinite Menus to toggle tracking off, you'll miss most of it.

Can I run Android on the Pinephone? If not, why not? Surely if it was truly a good mobile GNU/Linux that would be the case.

Now you are getting close to what the problems actually are on Android.  No real GNU userspace like normal, full GNU/Liinux.  Also the way these SoC work are that they are throwaway consumer devices, released frozen to some old kernel and never updated.  All manner of dirty hacks and proprietary crap, neither which will ever get mainlined (and therefore, no long term support in Linux).  Because you are supposed to be a good consumer and just throw it away and purchase a new device every year or two in accordance with your carrier's business model.

To answer your question about release outside Play Store, yes, check out F-Droid.  Although users will need to "allow third party sources" which your average muppet seems to have trouble with.  And how much longer will Google/Alphabet allow it?  They totally control the platform, after all (this is the real problem).

And yes, I consider Android a completely predatory (good word!) and hostile platform at this point.

I guess you probably can (get Android running on PinePhone) but maybe now you understand why it's sort of like: why bother?  We have an opportunity now to make something so much better.

[constfun]

AppImage is dynamically linked to the libc runtime which IIRC is in a different place on Guix and so it won't start.

That is indeed the case, however the AppImage that I was trying (I think it was PrusaSlicer) had other missing dependencies in addition to that. The reality is that even discovering what your dependencies are is a challenge, so I don't blame the packagers. This sort of dependency hell is precisely why I use Guix and Guix System. It is still dependency hell, but only as far as getting things working, at least you have some guarantee of longevity of your solution.

AppImage is certainly worth a deeper look. It doesn't push a store and is an executable that doesn't require installing a runtime.

[swiley]

AppImage is dynamically linked to the libc runtime which IIRC is in a different place on Guix and so it won't start.

That is indeed the case, however the AppImage that I was trying (I think it was PrusaSlicer) had other missing dependencies in addition to that. The reality is that even discovering what your dependencies are is a challenge, so I don't blame the packagers. This sort of dependency hell is precisely why I use Guix and Guix System. It is still dependency hell, but only as far as getting things working, at least you have some guarantee of longevity of your solution.

AppImage is certainly worth a deeper look. It doesn't push a store and is an executable that doesn't require installing a runtime.

You really shouldn't be distributing software you don't fully understand the dependencies for. I would blame the packagers (and the author) for that.

[constfun]

Some F/LOSS developers are lucky to have a job in academia or elsewhere where their employer let them work on their pet project... [o]thers work at companies doing F/LOSS like Red Hat...

As a matter of fact, funding of F/LOSS projects has been a sort of interest of mine for a long time.  I wasn't sure where you were coming from which was why I asked.  Drew DeVault has written about it on his blog a bit, he says what I said above but there will be more context and ideas there for you to ponder.

Many of these funding models sound like doing a lot of tangentially related work, as a full time job no less, just so you can do the actual work and give it away for free. In particular, this model is not appealing to kids that are inheriting this mean blue dot. Perhaps that is the biggest problem of them all.

Thank you for a pointer to Drew DeVault, will read.

Now you are getting close to what the problems actually are on Android.  No real GNU userspace like normal, full GNU/Liinux.  Also the way these SoC work are that they are throwaway consumer devices, released frozen to some old kernel and never updated...

To answer your question about release outside Play Store, yes, check out F-Droid.  Although users will need to "allow third party sources" which your average muppet seems to have trouble with...

Yea... porting is real effort, combined with unique packaging and distribution headaches of each platform and it really is not a non-trivial amount of work. In my head, I reduced all non-Linux platforms to "make it work on the web." Naturally, starting from software written for Linux and targeting the browser, you'll arrive at a showcase and limited version of your product at best. Porting to straight Andriod might be easy enough and hence worthwhile... I'm skeptical based on what you said, however. This is precisely why commercial efforts choose Electron, easy short term gains.

But it's hard selling the product (software) when the license specifically allows for making copies of it.[0]

As a thought experiment, and you'll have to set the ideology aside for this one, consider what would happen if the license didn't explicitly allow this, and instead focused on a potentially more important aspect: portability and privacy of the data that the software generates and interacts with. I imagine "Indie/Handmade/Free" software starting out with such guarantees over all others. It is possible that we are on a trajectory where freedom to modify the source code is less relevant than the freedom to own, move, and delete the data. Surely once we reach singularity (any day now, perhaps this century), code will transition to the realm of machines and personal data will remain personal. Perhaps we already passed the inflection point where data matters more than the computation and have failed to adjust.

---

You really shouldn't be distributing software you don't fully understand the dependencies for. I would blame the packagers (and the author) for that.

You'd be surprised how difficult of a task that is using modern technology. Concretely, your direct dependencies have dependencies of their own, and those indirect dependencies have dependencies, etc. Meanwhile, I still type things into a tty terminal and have to decipher a puke of text when something goes wrong. That is, essentially, still the state of the art for Software Development.

In other words, it's important to have empathy towards the shear amount of will and work that it takes to ship software.

[TRS-80]

Many of these funding models sound like doing a lot of tangentially related work, as a full time job no less, just so you can do the actual work and give it away for free. In particular, this model is not appealing to kids that are inheriting this mean blue dot. Perhaps that is the biggest problem of them all.

Yes, it's a difficult and long standing problem.  I don't know the answers, but I certainly realize the potential importance of this to future development and sustainability of the entire ecosystem.  Hence my interest in the topic.

Maybe your fresh ideas can finally bring sustainability along with freedom and privacy?  Wouldn't that be nice!? 

I'm skeptical based on what you said, however.

I guess I can see that, coming from point of view of trying to appeal / "sell" to the masses.  Personally I have given up on them.  I only care about the (relatively smaller) group of users (/hackers) comprising the F/LOSS community.  For a multitude of reasons.

This is precisely why commercial efforts choose Electron, easy short term gains.

Well that's the idea behind it, and Java for cross platform, and on and on...  However native apps still always out perform, it seems like (even though hardware gets faster all the time).

As a thought experiment, and you'll have to set the ideology aside for this one, consider what would happen if the license didn't explicitly allow this, and instead focused on a potentially more important aspect: portability and privacy of the data that the software generates and interacts with. I imagine "Indie/Handmade/Free" software starting out with such guarantees over all others. It is possible that we are on a trajectory where freedom to modify the source code is less relevant than the freedom to own, move, and delete the data. Surely once we reach singularity (any day now, perhaps this century), code will transition to the realm of machines and personal data will remain personal. Perhaps we already passed the inflection point where data matters more than the computation and have failed to adjust.

Well, you replied to me about making copies, which is one of the 4 freedoms.  Then later you talk about modifying the source code which is a different one of the 4 freedoms.  So let's take each in turn.

In case of source code availability/modification (actually 2 separate freedoms), I guess I would say that how do we really know what's in there if we can't see the source code?  You would have to trust the author.

Even if the end user does not understand the source code, it is assumed that others do and it's intended as a sort of collaborative effort.

I think a lot of these ideas have been hashed out quite a lot already; I am not saying rms is perfect, but he is a smart guy and thought this all through pretty thoroughly.  In fact he has pages and pages of writings about it if you care to read them.  And the more the decades go on and the more things I see, I just think more and more that he was right all along, and foresaw quite a lot of our current societal problems around tech.

Now, if we are talking about not allowing making copies, then we are talking about something that is no longer considered Free Software by most definitions I am aware of.  Now, maybe this is the solution (at least to some of the problems you correctly identify in this thread)?

However from Free Software perspective, it is about freedom and control.  We want to have control of our software (and hardware, to the exent possible).  And it turns out, in order to have that control, you must have all 4 of the essential freedoms that rms identified.

Also, from a practical standpoint, you then could not release any software you have built on top of anything which is licensed as Free Software.  In fact the Free Software licenses are designed explicitly in that way, in order to protect the entire ecosystem (unlike "Open Source").

You'd be surprised how difficult of a task that is using modern technology. Concretely, your direct dependencies have dependencies of their own, and those indirect dependencies have dependencies, etc. Meanwhile, I still type things into a tty terminal and have to decipher a puke of text when something goes wrong. That is, essentially, still the state of the art for Software Development.

In other words, it's important to have empathy towards the shear amount of will and work that it takes to ship software.

I know you were replying to swiley here, but for my part I do have empathy.  I well realize how complex it can be.  Personally I very much aspire to learn more about Debian packaging, but just haven't had the time.

Anyway, it was from a point of empathy that I suggested further up thread that this is the packagers / distributions job, traditionally speaking.  For all the reasons you mentioned and more.

[bcnaz]

I'm considering investing some time into the platform and wonder how many devices have been sold? If this information is not public, a range would be very helpful to know. Thank you!

  I too would be interested in that number,  but just to satisfy my curiosity

But that would not be a very reliable number, even if you got it from the Factory,  Many people have the phone just sitting somewhere
  because it did not act like their Android phone so they discard it

Or how many have 'bricked their modem' then sold the phone on Ebay ? ( Some unlucky person gets a foul taste of 'Linux' ) ?

Then another point,  many of us have multiple Pine phones,  while I am only using one as my main daily driver, I am running multiple other
  Pine phones on cheap NVMO's just for testing purposes.

*****
I would guess lots of the Forum members have two or more Pine phones ?

[wibble]

To answer your question about release outside Play Store, yes, check out F-Droid.  Although users will need to "allow third party sources" which your average muppet seems to have trouble with.  And how much longer will Google/Alphabet allow it?  They totally control the platform, after all (this is the real problem).

Given the current antitrust climate in the US and EU, and its direction of travel, I don't see Google/Alphabet making it any more restrictive than it is already.