• 3 Posts
  • 98 Comments
Joined 1 year ago
cake
Cake day: March 2nd, 2023

help-circle
  • 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.




  • 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.


  • 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.





  • Are there any stats to suggest that? I don’t mean in a “prove it or gtfo” kind of way but I maintain a community for the Pulsar text editor on lemmy.ml (back before it was cool /hipster) when there weren’t really any other (popular) instances. We have no political ideology (as a group, not speaking for individuals within it) and it is meant to be a Fediverse alternative to our Subreddit for discussion and support. The last thing I want is for people to not have access to it because instances are blocking it or people are shying away from lemmy.ml in general.


  • As I understand it, just a portion. So where we tend to have breakers for something like, downstairs sockets, upstairs sockets, downstairs lights, upstairs lights, cooker etc. they would have it broken down far more granularly so maybe a single room or even multiple breakers for a single room and limited to much lower currents. Like our breakers are for 32 amps generally, theirs might be 16 or lower.




  • Daeraxa@lemmy.mltoLinux@lemmy.mlanti-snap stance is anti-consumer
    link
    fedilink
    arrow-up
    39
    arrow-down
    1
    ·
    edit-2
    20 days ago

    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.