Daeraxa

joined 2 years ago
[–] Daeraxa@lemmy.ml 2 points 5 months ago

And I wasn't aware of the Elementary thing with Flatpak! Admittedly I hadn't really thought of it in that way, I was thinking something more akin to F-droid where there are a couple of extra repos you can add which have applications not on the main one due to slightly looser requirements. But making it specifically for apps for that ecosystem in particular makes a lot of sense.

[–] Daeraxa@lemmy.ml 2 points 5 months ago* (last edited 5 months ago) (3 children)

Not officially but people have managed to reverse engineer it before in order to host their own - https://forum.snapcraft.io/t/lol-an-open-source-snap-server-implementation/27109

Whilst I do get the sentiment (and in no way do I support Canonical in keeping it proprietary), how likely is it that alternative Snap repos are going to show up if they did make it possible? Even with Flatpak where it is encouraged and documented I don't think I've heard of anyone setting up a Flathub alternative of any significance.

[–] Daeraxa@lemmy.ml 3 points 5 months ago (7 children)

(except snap, but they seem too Ubuntu specific).

For what it is worth you can install Snap on most distros. https://snapcraft.io/docs/installing-snapd

[–] Daeraxa@lemmy.ml 44 points 5 months ago* (last edited 5 months ago) (2 children)

From the conversation it seems to be a similar situation to the project I'm with is in. The flatpak is essentially community maintained rather than being directly supported by the team. To become verified it needs to be done so by a representative of the maintainers of the software. To be verified it doesn't have to have a team member involved in it but this is a requirement Inkscape seem to have imposed.

For us we just aren't in a position to want to support it officially just yet, we have some major upgrades coming to our underlying tech stack that will introduce a whole bunch of stuff that will allow various XDG portals etc. to work properly with the Flatpak sandboxing model. To support it now would involve tons of workarounds which would need to be removed later.

[–] Daeraxa@lemmy.ml 1 points 5 months ago* (last edited 5 months ago)

Yeah this has been our (well, my) statement on requests to put out ARM binaries for Pulsar. Typically we only put binaries out for systems we actually have within the team so we can test on real hardware and replicate issues. I would be hesitant to put out Windows ARM builds when, as far as I know, we don't have such a device. If there was a sudden clamouring for it then we could maybe purchase a device out of the funds pot.

The reason I was asking more about if it was to do with developer licences is that we have already dealt with differences between x86 and ARM macOS builds because the former seems to happily run unsigned apps after a few clicks, where the latter makes you run commands in the terminal - not a great user experience.

That is why I was wondering if the ARM builds for Windows required signing else they would just refuse to install on consumer ARM systems at all. The reason we don't sign at the moment is just because of the exorbitant cost of the certificates - something we would have to re-evaluate if signing became a requirement.

[–] Daeraxa@lemmy.ml 2 points 5 months ago

I can't say I'm one who shares that sentiment seeing as the only two projects I'm involved with happen to be Electron based (by chance rather than intention). Hell, one of them is Pulsar which is a continuation of Atom which literally invented Electron.

[–] Daeraxa@lemmy.ml 1 points 5 months ago (2 children)

Is that a developer licence thing? I know GitHub recently announced Windows Arm runners that would be available to non-teams/enterprise tiers later this year.

[–] Daeraxa@lemmy.ml 5 points 5 months ago (2 children)

Electron apps using older versions that don't support the 16k page size are probably the biggest offenders

[–] Daeraxa@lemmy.ml 4 points 5 months ago* (last edited 5 months ago)

I wonder if it probably wouldn't (or at least wouldn't have) done any harm to do so seeing as if you look at Flatpak, its most obvious comparison, although it can have multiple remotes, Flathub is the only one that is realistically used and is the de-facto standard.

[–] Daeraxa@lemmy.ml 40 points 5 months ago* (last edited 5 months ago) (4 children)

I think a lot of the flak directed towards snap would be mitigated if they made the backend open source. I know there are some efforts to produce alternative backends (although the one I knew about lol / lol-server seems to have gone dark).

Another issue is Canonical's rather strong armed and forceful approach to making people use snaps rather than the OSs native packaging system, again, not something that should be an issue in theory but when people already have a negative view of the format to start with...

Personally I don't really have an issue with Snaps. I've had more luck with them and fewer issues than Flatpaks (which I also tend to avoid like the plague) but that is probably just because I prefer to use appimages or native packages rather than having to fight the sandbox permissions and weird things it can do to apps that don't take Snaps and Flatpaks properly into account.

[–] Daeraxa@lemmy.ml 1 points 5 months ago (1 children)
[–] Daeraxa@lemmy.ml 2 points 6 months ago

I'm using Fedora on a second hand x380 Yoga and it works rather nicely.

view more: ‹ prev next ›