Re: Subsurface as a Snap?

[Miika Turkia]

On Fri, Dec 29, 2017 at 6:58 AM, Dirk Hohndel  wrote:

>
> On Dec 28, 2017, at 8:50 PM, Miika Turkia  wrote:
>
> On Thu, Dec 21, 2017 at 5:15 PM, Dirk Hohndel  wrote:
>
>>
>> I could be wrong (that's one of my defining strength - I am wrong a lot).
>> But here's my analysis:
>>
>> About 2/3 of our users are supported with one single binary, the Windows
>> installer.
>> Another 20% of our users are supported by one single binary, the Mac DMG
>> (we had times had a second DMG for older versions, but given that they
>> tended to get < 100 users, I have not spend much effort on them).
>> The remaining roughly 15% of our users today require us to build about 30
>> different binary packages which take up a significant amount of my time
>> whenever we introduce a new dependency, need a feature from a newer version
>> of a library, or some other way break things. At this point I have managed
>> to bring down the number of build configuration systems to 3 to create the
>> vast majority of those binary packages: the Ubuntu/Launchpad system, the
>> openSUSE/Fedora/OBS system, plus AppImage. Additionally, community members
>> are maintaining always current and very solid binary packages for Arch and
>> Gentoo (I believe). Considering this maybe you can understand my reluctance
>> better.
>>
>
> Here is a quick run-down from Launchpad for the latest release.
>
> 4.7.5-1~zesty (56) - 17.04
> zesty (56)
> amd64 (53)
> i386 (3)
> 4.7.5-1~xenial (505) - 16.04 LTS
> xenial (505)
> amd64 (472)
> i386 (33)
> 4.7.5-1~artful (123) - 17.10
> artful (123)
> amd64 (120)
> i386 (3)
>
>
> Those are number of people who have installed it, not number of people who
> use it, correct?
>

Yep, this is the number of people who have installed Subsurface 4.7.5 from
Launchpad.

> BTW Out of curiosity, how many users you think we have in total?
>
>
> Around 20k users who connected to the update server at least once in the
> last 6 months. This number overstates the number of users as for example I
> am counting for about 20 entries here; every single computer / VM on which
> I have installed Subsurface in the last 6 months shows up... but
> realistically, most NORMAL people have Subsurface on one or two devices, so
> I'm guessing this means we have more than 15k users.
>

On the other hand, I do not connect to the update server at all :D as it
suffices to have our Launchpad repo configured and getting updates
automatically (if not running master).

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface as a Snap?

[Dirk Hohndel]

> On Dec 28, 2017, at 8:50 PM, Miika Turkia  wrote:
> 
> On Thu, Dec 21, 2017 at 5:15 PM, Dirk Hohndel  > wrote:
> 
> I could be wrong (that's one of my defining strength - I am wrong a lot). But 
> here's my analysis: 
> 
> About 2/3 of our users are supported with one single binary, the Windows 
> installer. 
> Another 20% of our users are supported by one single binary, the Mac DMG (we 
> had times had a second DMG for older versions, but given that they tended to 
> get < 100 users, I have not spend much effort on them). 
> The remaining roughly 15% of our users today require us to build about 30 
> different binary packages which take up a significant amount of my time 
> whenever we introduce a new dependency, need a feature from a newer version 
> of a library, or some other way break things. At this point I have managed to 
> bring down the number of build configuration systems to 3 to create the vast 
> majority of those binary packages: the Ubuntu/Launchpad system, the 
> openSUSE/Fedora/OBS system, plus AppImage. Additionally, community members 
> are maintaining always current and very solid binary packages for Arch and 
> Gentoo (I believe). Considering this maybe you can understand my reluctance 
> better.
> 
> Here is a quick run-down from Launchpad for the latest release.
> 
> 4.7.5-1~zesty (56) - 17.04
> zesty (56)
> amd64 (53)
> i386 (3)
> 4.7.5-1~xenial (505) - 16.04 LTS
> xenial (505)
> amd64 (472)
> i386 (33)
> 4.7.5-1~artful (123) - 17.10
> artful (123)
> amd64 (120)
> i386 (3)
> 

Those are number of people who have installed it, not number of people who use 
it, correct?

> BTW Out of curiosity, how many users you think we have in total?

Around 20k users who connected to the update server at least once in the last 6 
months. This number overstates the number of users as for example I am counting 
for about 20 entries here; every single computer / VM on which I have installed 
Subsurface in the last 6 months shows up... but realistically, most NORMAL 
people have Subsurface on one or two devices, so I'm guessing this means we 
have more than 15k users.

Around 3k users who connected to the cloud server in the last 90 days.
Almost exactly 5k verified cloud storage accounts.

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface as a Snap?

[Miika Turkia]

On Thu, Dec 21, 2017 at 5:15 PM, Dirk Hohndel  wrote:

>
> I could be wrong (that's one of my defining strength - I am wrong a lot).
> But here's my analysis:
>
> About 2/3 of our users are supported with one single binary, the Windows
> installer.
> Another 20% of our users are supported by one single binary, the Mac DMG
> (we had times had a second DMG for older versions, but given that they
> tended to get < 100 users, I have not spend much effort on them).
> The remaining roughly 15% of our users today require us to build about 30
> different binary packages which take up a significant amount of my time
> whenever we introduce a new dependency, need a feature from a newer version
> of a library, or some other way break things. At this point I have managed
> to bring down the number of build configuration systems to 3 to create the
> vast majority of those binary packages: the Ubuntu/Launchpad system, the
> openSUSE/Fedora/OBS system, plus AppImage. Additionally, community members
> are maintaining always current and very solid binary packages for Arch and
> Gentoo (I believe). Considering this maybe you can understand my reluctance
> better.
>

Here is a quick run-down from Launchpad for the latest release.

4.7.5-1~zesty (56) - 17.04
zesty (56)
amd64 (53)
i386 (3)
4.7.5-1~xenial (505) - 16.04 LTS
xenial (505)
amd64 (472)
i386 (33)
4.7.5-1~artful (123) - 17.10
artful (123)
amd64 (120)
i386 (3)

BTW Out of curiosity, how many users you think we have in total?

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface as a Snap?

[Dirk Hohndel]

On December 21, 2017 6:19:45 PM PST, Philip Balister  
wrote:
>
>Don't forget the dinosaurs (like me) that build from source :)

Those cause me the least work.

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface as a Snap?

[Thiago Macieira]

On quinta-feira, 21 de dezembro de 2017 13:15:53 -02 Dirk Hohndel wrote:
> Snap is a Canonical effort and as such is receiving at best "lip-service"
> level support from the other distros. FlatPak was very much developed by
> Red Hat as a response to Snap and as a direct competitor. As a result
> (isn't it lovely), neither of them has good support on the other one's
> platform. Even though both of course claim that they do.

Red Hat is contributing new features to Qt in order to support FlatPak, like 
supporting the FlatPak D-Bus portal service to show file dialogs and allow 
selecting of files outside of the sandbox. I have not seen any patch for 
Canonical for Snap.

For that matter, neither for AppImage.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface as a Snap?

[Lubomir I. Ivanov]

On 21 December 2017 at 17:15, Dirk Hohndel  wrote:
>
> On Dec 21, 2017, at 6:54 AM, Henrik B A  wrote:
>
> On Thu, Dec 21, 2017 at 3:39 PM, Dirk Hohndel  wrote:
>>
>> Snap and Flatpak both are different takes on what we already have with
>> AppImage.
>> The goal of AppImage was to have fewer builds to worry about. And it
>> brilliantly does that.
>> So unless there is something that is a) better and b) completely replaces
>> AppImage, I'm
>> not sure why we'd spend time on it.
>
>
> It was just a thought.  With Ubuntu (and others) embracing Snap, and with
> all major distributions supported, and a central package repository
> available, it might reach a larger user base and be easier to support.  I
> obviously base this conclusion on absolutely nothing :D
>
>
> Let's talk Linux Distro Politics here.
> Snap is a Canonical effort and as such is receiving at best "lip-service"
> level support from the other distros.
> FlatPak was very much developed by Red Hat as a response to Snap and as a
> direct competitor.
> As a result (isn't it lovely), neither of them has good support on the other
> one's platform. Even though both of course claim that they do.
> AppImage, conversely, isn't controlled by either of the vendors but instead
> developed and driven by the community.
> Its design goals seem to very closely match our desire for an independent,
> broadly supported packaging format that does NOT require any other software
> to be installed on the target system. But on the flip side, the user
> experience usually isn't quite on par with a natively supported app.
>
> Yes, I agree that the repositories and distro integration for Snap and
> FlatPak on their respective "home" platforms are attractive. It has been my
> perception that the incremental value would be small compared to the effort
> this would take to develop and most importantly maintain.
>
> I could be wrong (that's one of my defining strength - I am wrong a lot).
> But here's my analysis:
>
> About 2/3 of our users are supported with one single binary, the Windows
> installer.
> Another 20% of our users are supported by one single binary, the Mac DMG (we
> had times had a second DMG for older versions, but given that they tended to
> get < 100 users, I have not spend much effort on them).
> The remaining roughly 15% of our users today require us to build about 30
> different binary packages which take up a significant amount of my time
> whenever we introduce a new dependency, need a feature from a newer version
> of a library, or some other way break things. At this point I have managed
> to bring down the number of build configuration systems to 3 to create the
> vast majority of those binary packages: the Ubuntu/Launchpad system, the
> openSUSE/Fedora/OBS system, plus AppImage. Additionally, community members
> are maintaining always current and very solid binary packages for Arch and
> Gentoo (I believe). Considering this maybe you can understand my reluctance
> better.
>
> /D
>
> PS: Oh, and of course there are the additional two build frameworks that we
> support for Android and iOS, because maintaining 5 different ones clearly
> wasn't crazy enough.
>

fragmentation is ultimately the biggest downfall of modern software.
RedHat and Canonical should combine efforts into a single package
tool, but that probably won't happen due to politics and stubbornness.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface as a Snap?

[Dirk Hohndel]

> On Dec 21, 2017, at 6:54 AM, Henrik B A  wrote:
> 
> On Thu, Dec 21, 2017 at 3:39 PM, Dirk Hohndel  > wrote:
> Snap and Flatpak both are different takes on what we already have with 
> AppImage.
> The goal of AppImage was to have fewer builds to worry about. And it 
> brilliantly does that.
> So unless there is something that is a) better and b) completely replaces 
> AppImage, I'm 
> not sure why we'd spend time on it.
> 
> It was just a thought.  With Ubuntu (and others) embracing Snap, and with all 
> major distributions supported, and a central package repository available, it 
> might reach a larger user base and be easier to support.  I obviously base 
> this conclusion on absolutely nothing :D

Let's talk Linux Distro Politics here.
Snap is a Canonical effort and as such is receiving at best "lip-service" level 
support from the other distros.
FlatPak was very much developed by Red Hat as a response to Snap and as a 
direct competitor.
As a result (isn't it lovely), neither of them has good support on the other 
one's platform. Even though both of course claim that they do.
AppImage, conversely, isn't controlled by either of the vendors but instead 
developed and driven by the community.
Its design goals seem to very closely match our desire for an independent, 
broadly supported packaging format that does NOT require any other software to 
be installed on the target system. But on the flip side, the user experience 
usually isn't quite on par with a natively supported app.

Yes, I agree that the repositories and distro integration for Snap and FlatPak 
on their respective "home" platforms are attractive. It has been my perception 
that the incremental value would be small compared to the effort this would 
take to develop and most importantly maintain. 

I could be wrong (that's one of my defining strength - I am wrong a lot). But 
here's my analysis: 

About 2/3 of our users are supported with one single binary, the Windows 
installer. 
Another 20% of our users are supported by one single binary, the Mac DMG (we 
had times had a second DMG for older versions, but given that they tended to 
get < 100 users, I have not spend much effort on them). 
The remaining roughly 15% of our users today require us to build about 30 
different binary packages which take up a significant amount of my time 
whenever we introduce a new dependency, need a feature from a newer version of 
a library, or some other way break things. At this point I have managed to 
bring down the number of build configuration systems to 3 to create the vast 
majority of those binary packages: the Ubuntu/Launchpad system, the 
openSUSE/Fedora/OBS system, plus AppImage. Additionally, community members are 
maintaining always current and very solid binary packages for Arch and Gentoo 
(I believe). Considering this maybe you can understand my reluctance better.

/D

PS: Oh, and of course there are the additional two build frameworks that we 
support for Android and iOS, because maintaining 5 different ones clearly 
wasn't crazy enough.___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface as a Snap?

[Henrik B A]

On Thu, Dec 21, 2017 at 3:39 PM, Dirk Hohndel  wrote:

> Snap and Flatpak both are different takes on what we already have with
> AppImage.
> The goal of AppImage was to have fewer builds to worry about. And it
> brilliantly does that.
> So unless there is something that is a) better and b) completely replaces
> AppImage, I'm
> not sure why we'd spend time on it.
>

It was just a thought.  With Ubuntu (and others) embracing Snap, and with
all major distributions supported, and a central package repository
available, it might reach a larger user base and be easier to support.  I
obviously base this conclusion on absolutely nothing :D

Happy holidays!

Henrik
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface as a Snap?

[Dirk Hohndel]

> On Dec 21, 2017, at 1:30 AM, Henrik B A  wrote:
> 
> Has anyone looked into how feasible it would be to build Subsurface as a 
> Snap?  It would be an alternative to the AppImage.
> 
> Ref. https://docs.snapcraft.io/build-snaps/c 
> 
Snap and Flatpak both are different takes on what we already have with AppImage.
The goal of AppImage was to have fewer builds to worry about. And it 
brilliantly does that.
So unless there is something that is a) better and b) completely replaces 
AppImage, I'm 
not sure why we'd spend time on it.

The share of Linux users in our overall user base has been declining for years. 
Admittedly,
my data there is not necessarily correct as it relies on connections to the 
update server,
but I think it's a reasonable indication of rough orders of magnitude.

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface