3 ms·

I was rolling my eyes reading this and then hit this, which is the real value of the article IMO: > few Linux platforms (if any?) had taken a series whack at b

I was rolling my eyes reading this and then hit this, which is the real value of the article IMO: > few Linux platforms (if any?) had taken a series whack at building a consumer grade app and developer experience. We tried, it was not successful, and instead of digging up the past I would rather ensure we can inform the future. "What not to do, and how not to do it" are at least one valid take away from that whole era.

merlijn_s 9y ago
One of the big issues with their attempt was ~0 support or documentation for porting existing applications. Everything was focused around building an Ubuntu app from scratch using their custom qtquick-based SDK, but that's not what we needed. edit: for more info: This guy made a beautiful summary of the issues with the dev experience around Ubuntu (Touch): http://www.lieberbiber.de/2017/06/20/my-ubuntu-for-mobile-devices-post-mortem/ http://www.lieberbiber.de/2017/06/20/my-ubuntu-for-mobile-de... [starts from 6. "The life of an app developer was too hard."]
- wmf 9y ago
  Since this thread is about the desktop, don't existing GNOME apps just work under Unity Desktop?
  - michaelmrose 9y ago
    Yes generally all apps designed for any desktop environment just work in others so long as supporting libraries are installed. A few points of division are pulseaudio and wayland. Pretty much everybody now uses pulse and while most apps will work in wayland I don't know of any that require it yet.
revelation 9y ago
The biggest takeaway from the era is that no one fucking bothers to write software for 10 different distributions with 15 different ideas on how the most trivial of things are to be accomplished. And here is this guy wanting to build number 16. There is an xkcd on this. This train has left the station.
- drdaeman 9y ago
  Nah, almost all mainstream (and even most non-mainstream) distros are basically equal. Seriously, maybe I'm wrong but I don't think that's an issue. As long as your distro doesn't replace glibc for e.g. musl or bionic, and has all the usual GNU (and X11, and DBus if you need that) userland, i.e. no odd stuff - there is no much difference. Most of the time things just work. Normally, the only time you'll have to "write software for some specific distribution" is when the distribution is unusual in its ways, but you still want to target it. That is, unless you need to target some specific library version that's higher or lower than the usually available, incompatible with the usual version, and you don't want to have a statically-linked release variant. E.g. something that would work only with Qt5.2 but not with Qt5.6. Don't see why not to just throw it all in a tarball and call it a release. Saw this done many times, I just unpacked it, ran it - and it worked. And that is if that's you who package your software. Usually, some user just takes it further and becomes a maintainer (or a co-maintainer, or just a volunteer who submits patches).
  - flukus 9y ago
    > That is, unless you need to target some specific library version that's higher or lower than the usually available, incompatible with the usual version, and you don't want to have a statically-linked release variant. E.g. something that would work only with Qt5.2 but not with Qt5.6. Don't see why not to just throw it all in a tarball and call it a release. Saw this done many times, I just unpacked it, ran it - and it worked. In this hypothetical (I hope) example, you've just subjected your users to unpatched vulnerabilities like this one: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0190 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0190
- jonobacon 9y ago
  Did you actually read the post? I am not suggesting anyone builds anything new, instead that we are realistic in how much work is involved and distributions consolidate around something that already exists.
- bryanlarsen 9y ago
  He advocates flatpak, which is basically desktop Docker. You package all your dependencies so you can choose any of the 15 to put inside your flatpak, and it'll work with any of the 15 outside your flatpak. You get the normal trade-offs for this approach -- large downloads, disk space, slow security updates, UI inconsistencies but XKCD 927 doesn't really apply.

merlijn_s 9y ago

One of the big issues with their attempt was ~0 support or documentation for porting existing applications. Everything was focused around building an Ubuntu app from scratch using their custom qtquick-based SDK, but that's not what we needed. edit: for more info: This guy made a beautiful summary of the issues with the dev experience around Ubuntu (Touch): http://www.lieberbiber.de/2017/06/20/my-ubuntu-for-mobile-devices-post-mortem/ http://www.lieberbiber.de/2017/06/20/my-ubuntu-for-mobile-de... [starts from 6. "The life of an app developer was too hard."]

wmf 9y ago
Since this thread is about the desktop, don't existing GNOME apps just work under Unity Desktop?
- michaelmrose 9y ago
  Yes generally all apps designed for any desktop environment just work in others so long as supporting libraries are installed. A few points of division are pulseaudio and wayland. Pretty much everybody now uses pulse and while most apps will work in wayland I don't know of any that require it yet.

revelation 9y ago

The biggest takeaway from the era is that no one fucking bothers to write software for 10 different distributions with 15 different ideas on how the most trivial of things are to be accomplished. And here is this guy wanting to build number 16. There is an xkcd on this. This train has left the station.

drdaeman 9y ago
Nah, almost all mainstream (and even most non-mainstream) distros are basically equal. Seriously, maybe I'm wrong but I don't think that's an issue. As long as your distro doesn't replace glibc for e.g. musl or bionic, and has all the usual GNU (and X11, and DBus if you need that) userland, i.e. no odd stuff - there is no much difference. Most of the time things just work. Normally, the only time you'll have to "write software for some specific distribution" is when the distribution is unusual in its ways, but you still want to target it. That is, unless you need to target some specific library version that's higher or lower than the usually available, incompatible with the usual version, and you don't want to have a statically-linked release variant. E.g. something that would work only with Qt5.2 but not with Qt5.6. Don't see why not to just throw it all in a tarball and call it a release. Saw this done many times, I just unpacked it, ran it - and it worked. And that is if that's you who package your software. Usually, some user just takes it further and becomes a maintainer (or a co-maintainer, or just a volunteer who submits patches).
- flukus 9y ago
  > That is, unless you need to target some specific library version that's higher or lower than the usually available, incompatible with the usual version, and you don't want to have a statically-linked release variant. E.g. something that would work only with Qt5.2 but not with Qt5.6. Don't see why not to just throw it all in a tarball and call it a release. Saw this done many times, I just unpacked it, ran it - and it worked. In this hypothetical (I hope) example, you've just subjected your users to unpatched vulnerabilities like this one: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0190 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0190
jonobacon 9y ago
Did you actually read the post? I am not suggesting anyone builds anything new, instead that we are realistic in how much work is involved and distributions consolidate around something that already exists.
bryanlarsen 9y ago
He advocates flatpak, which is basically desktop Docker. You package all your dependencies so you can choose any of the 15 to put inside your flatpak, and it'll work with any of the 15 outside your flatpak. You get the normal trade-offs for this approach -- large downloads, disk space, slow security updates, UI inconsistencies but XKCD 927 doesn't really apply.