• 4 Posts
  • 13 Comments
Joined 3 years ago
cake
Cake day: November 3rd, 2021

help-circle
  • I’ve tried in the past flatpak packages, they are terrible in many senses the proponent (vast majority AFAIK) don’t say, among them:

    • They create huge static binaries
    • One gets many libraries embedded in the static libraries or local static libs to the package which are often repeated among many static binaries, even the same version of them. This is totally avoided when building against dynamic native libraries.
    • When installing a pletora of static dependencies for a package, lets say liri, a bunch of the stuff it requires might already bi installed natively in your system, but they need the static deps locally part of the package.
    • Care must be applied, there are statistics available about abuse on vulnerabilities infection on pypi, npm and so on, this no different on these packagers repos/hubs.

    Good that they provide an alternative way to install packages not available in your distro repos, but for that user repositories building against native libraries are a much better option, like AUR in the case of Arch, and even their binary packages coming from other distros or from upstream might be even better than those universal static binaries providers.

    There are political aspects involved in the past claim from the proponents, and it’s that in their view gnu+linux echo-system should become like the windows one, where everyone company or org (to them doesn’t matter) should be able to provide their binary packages, and then there’s no reason to think of anyone being able to build their staff.

    There’s a tendency actually on providers on those hubs, to ignore problems on people who tries to build their stuff on their own, claiming they only support those universal packages. Which to me it’s dangerous, since it goes in detriment to the ability to build and distribute the software, which might not be due to licenses, but rather practical reasons. This might actually be against the licenses they use, but now a day who cares, right, it’s available on that packager repo…

    Lastly one argument provided in favor of the apps coming from those universal packages is sandboxing. But there’s firejail which can be install on most gnu+linux distributions, and comes with profiles for a pletora of apps, and if sandboxing is not enough, it can easily be combined with apparmor, or if you prefer selinux might be used… No need for those universal packages to have a sandboxed experience.

    One final note, so far gnu+linux has been characterized by having a diversity, which is good, that diversity offers people options to choose from, and a lot of different solutions for different purposes. Not so long ago the claim was that it was not good, that meant fragmentation, and fragmentation is bad for adoption and maintenance. I see it the other way around, this diversity allows for choosing for what aligns better with the user intends, like easy to use, or rolling release, or as vanila as possible, or as up to date as possible, or as hardened as possible, etc, etc. Systemd is another example of this universalization intended. Perhaps some distros prefer to be a shell for systemd and get packages just from universal packages, that’s bad news to me.

    Of course having universal packagers present an oportunity for corps and orgs to also provide stuff on the gnu+linux platform, but in my mind the best would be for them to offer free/libre and open source software, that would build on any system and be provided by any packager that wants to offer it. Though I believe that to be too idealistic perhaps. Jeje.


  • Read about it some other community, perhaps the guix one, and I was keeping it to help me in the future. It relies on nonguix repo which has its own recipes, but this one is nice. I wish I wouldn’t need any binary blobs, but sadly that’s not how things work. Counting on risc-v not just getting competitive hardware, but also motivating the surrounding hardware to follow.

    I’ll definitely need it in order to use relatively modern hardware.

    Many thanks !



  • What do you mean by unstable? I don’t get what this means. Install? Perhaps choosing a graphical install if available for your distribution of choice. I’ve heard nice things about Mint (can’t tell, I’m using Artix, and Guix is in my plans).

    That said, US or EU are not that different. Actually the EU is little by little deteriorating the data privacy it used to say it protected, but moreover, even if the data is kept in EU, what does it prevent US gov or corps to get access to the data? Did people forget about the 5 eyes, the extended ones (not sure how many, there were several extensions)? Did people forget that no matter the current differences, the EU and the US are allies (not just politically) any ways?

    Linux (kernel) itself has already identified itself as a US org, since it complies with the US requirements and law, to the point of banning developers from countries the US doesn’t like to be cooperating with US orgs (whether gov or not).

    So, focusing on country based software developers shouldn’t be the main motivation. Looking for free/libre software if possible, so that you get some freedoms of yours sort of intended to be protected through licenses, or if not available then open source, is what we should be looking for. On top of that, communication software should be e2ee, and if possible distributed or peer to peer, or at least decentralized, and so on. Also we tend to forget that the data kept in the cloud is no longer yours anymore, no matter the cloud, neither the country, and if in need to keep personal data on some cloud we should make sure it’s encrypted, but still the data keeps being the cloud owner hands, so having personal backups is important, and clouds usually don’t advertise what metadata they leak.

    Having said that Fedora sounds OK to me while Ubuntu sounds too commercial to me and actually now a days looking for users to get packages from its own “app store”. Instead of the “country of origin” for a distro, perhaps more importantly it is to see what your needs are, for example do you prefer rolling release vs. stable releases? Do you prefer vanila kind of packages (as close to upstream as possible) or your fine with the distro making changes to the upstream software as that serves better your purposes? How user friendly the distro is? Though perhaps you’re out of options if the framework laptop requires firmware or patches not found upstream, then you might better stay with the “officially supported” distros, unless what you miss by not having such firmware or patches is something you can live with, but usually x86 laptops are “easily” used with gnu+linux on top, except for some drivers not fully working with your hardware or missing firmware, but people usually still uses those laptops with gnu+linux on top. For arm laptops (I believe framework has laptos with arm CPUs, and actually is offering some initial ones with risc-v cpus) that tends to be a little more involved and I personally have no experience with that, and actually I’m waiting for a cheap enough and not so low level risc-v laptop or mini-pc to start experimenting with it (not all distributions support arm and even less risc-v).

    Again, I’ve heard nice things of Mint, particularly for people new to gnu+linux, and it’s not a rolling release distribution. Though I’m one of those thinking that rolling relase distributions are easy to live with, at least not on the server spectrum (there are actually servers running on top of rolling release distributions such as Arch, but that’s not the majority of them) given they can’t afford reboots (very few updates actually require reboot on gnu+linux, linux/kernel itself being one of those which better get a reboot ASAP but not necessarily immediately) or changes requiring a service to drop even for a little while. But with rolling releases one doesn’t have to deal with big differences between distribution major versions upgrades, and the changes requiring using intervention when upgrading packages are distributed on time, so no need to focus on a lot of them at once.

    Just my two cents, :)




  • FLOSS used to include the ability to build software. Perhaps that’s not important anymore but now a days some developers don’t attend problems with their build recipes because they only consider what they release through binaries, whether on flatpak or whatever other binary repository they like. At least I dislike that, it’s ok to me some or most users would prefer to grab a bloated binary rather than building anything, but that doesn’t mean forgetting about those actually wanting to build from source, or wanting to use shared libraries and software from their distros, actually that’s a requirement for free/libre software repositories. Not sure if the tendency is to move the gnu+linux users into app stores like the ones on windows, now ubuntu snaps, android play store and the like. Sure there’s more security with sandboxing, but nothing one can’t get with firejail, and if wanting MAC as well then firejail + apparmor for example.

    At any rate, just my little rant. And if you’re wondering, I use AUR on Artix, and I really hope I won’t have a need for a flatpak stuff.


  • Have you tried enabling webgl, which by default is disable on Librewolf? You can do that by overwriting the corresponding setting, as it can be done for any Librewolf setting, in particular the webgl override needed is:

    defaultPref("webgl.disabled", false);
    

    If you do, Librewolf recommend using the extension “CanvasBlocker” given the fingerprinting allowed by webgl. There’s a settings doc BTW…




  • If you have installed wlroots, that’s why. Wlroots has a hard dependency on libseatd, which is provided by seatd. Labwc also directly depends on it. Sway as well can use seatd as both documented by sway itself, and its arch wiki, but for some reason it doesn’t directly depend on it, though it depends on wlroots, :). This is not a problem on arch since the seatd service can co-exist with logind/systemd, and on arch you can use the seatd service combined with libseatd for software build on top of libseatd, and users on arch can then choose between seatd or policy kit on that software. On other non systemd distros like artix, the seatd daemon is in conflict with logind (on artix it’s extracted from systemd), precisely because you can get away without logind as long as you use acpid to provide some of the functionality logind also provides besides session administration. Not sure if besides wlroots on archthere’s additional software depending on seatd. Several wayland compositors are based on wlroots, which attempts to somehow offer a standard for compositor and applications developers.

    So it might be xdg-desktop-portal behaves differently for sandboxed apps such as flatpak ones than regular apps, hmm. So I’d still like to know how required d-bus is…

    Thanks a lot !


  • kixik@lemmy.mltoLinux@lemmy.mlReassessing Wayland
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    2 months ago

    Have you explore hyprland, niri (scrollable, not dynamic, but it’s sort of dynamic then) or sway (static tiling though, but offering tabbed layout and dynamic stacking/floating, plus hugely customizable)? Did you discard them because not close enough to bspwm? Just curious, not to judge your decision or anything like that.

    Being an artix user, are you using logind (the official default), or just seatd, or the new logind alternative turnstile (not supported by all init systems, looks like only dinit which I use and openrc, tough void has it working with runit I believe)? I’m wondering what’s really required on wayland. I like the approach of just seatd, but I don’t know what one would lose and what are the wins, but if not seat alone then turnstile which actually require seatd. Also I would like to drop calling d-bus, but I’m not sure if that would prevent the compositor to work, but further if screen sharing with webrtc, electron apps like slack or teams-for-linux would stop working. I guess not using d-bus would not affect mako. But any ways, I’m curious of what would be you choice for your wayland experience if/when you get into it. The official and default way is just logind plus d-bus plus polkit. For such sharing xdg-desktop-portal is required, which fundamentally seems to be plumbing of d-bus, but I’m not sure…

    BTW, from the blog post referenced, dudemanguy is also the mpv developer, so that requires quite a lot of effort (mpv specially on the support side of things, besides the developing effort, particularly to support wayland, and mpv does for some time now) together with artix effort. I’m glad he’s back writing, :)


  • Hey, sorry to take adantage of your answer, perhaps you can help me out though.

    Is dbus actually necessary for xdg-desktop-portal? I understand from this flatpak post that xdg-desktop-portal is actually a bunch of d-bus interconnections, which of course make d-bus fundamental for xdg-desktop-portal, but wanted to confirm. xdg-desktop-portal is a must on wayland if one wants to share screen through webrtc, or electron apps like slack or teams-for-linux (probably zoom which is Qt as well). But I’ve read some people (this for example) start sway from console without d-bus, without logind/systemd, just seatd on the background (wlroots and sway support seatd). So perhaps those people are not interested on sharing screen, I don’t know. Or perhaps such d-bus plumbing is only required for flatpaks apps, which are sandboxed, thus requiring all that interconnection to access resources and such, and then I’m not sure about a thing…

    Thanks !