Announcement

Collapse
No announcement yet.

Spotify Tops Ubuntu's Snap Store Downloads While GIMP Tops Flatpak's Flathub

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DrYak
    replied
    Originally posted by Creak View Post
    DrYak well rolling distros aren't as stable as regular distros. They need a bit more legwork to keep it stable.
    I've been a former Gentoo user at work (lab's standard distro-to-go in one of the Uni I've been at) and I see what you mean.

    But since openSuse Tumbleweed, I've been pleasantly surprised at the amount of efforts that suse devs have put into making it a painless experience and at the quality of the result.
    It has become an as light experience as using the release based openSuse Leap.

    Originally posted by Creak View Post
    And 3rd party repos are not very user friendly.
    Again the Suse effort upon Yast "1 click install" have made it wonderfully simple in my experience.
    They have a nice search engine, which clearly separate small scale personnal repos and larger scale projects, and if you're to lazy to manually add the repos to yast, there's a "single click" solution that can automatically add all the necessary repos and install all the corresponding dependencies.

    The whole distro experience is designed with strong 3rd party repo support in mind (seems to me that it stems back from when it got bough by Novell and had to switch to US legislation, which is much harshed regarding multimedia codec patents - rendering 3rd party repos a necessity for keeping multimedia functionnality to european-levels : packman was practically born from that).

    I don't have personnal experience with, but I've also heard/read positive feed-back about Ubuntu (Reportedly it's a breeze to add 3rd party blob drivers to support NVidia hardware).

    Originally posted by the_scx View Post
    Typically, users expect a stable base and a few newer applications. This is not the case for rolling release distributions.
    Nope, indeed. Rolling distros are for people wanting *the latest version ever of everything*, as I've said above.
    (Though as I've said in this comment, openSuse Tumbleweed is in my experience a surprisingly good quality rolling distro with very little brokage. On the other hand everything seems simpler than babysitting a Gentoo rolling install :-P ).

    If you want a stable base and only a few newer applications, that's what the whole purpose of 3rd party repos is.


    Originally posted by the_scx View Post
    What if such repositories/packages for a given distribution don't exist? Will you build packages on your own? It is not always as easy as it may seem.
    I would never be advocating self-compilation for people who aren't into it.
    If you're not into compiling newer versions, maybe switching to a distro with a more vibrant community of 3rd party repo could do the trick ?

    Originally posted by the_scx View Post
    Let's say that you have RHEL7 and you are interested in an app based on PyQt5 (e.g. ReText, Anki, etc.). Although EL7 contains both Python3 (EPEL: Python 3.4 & 3.6; RHSCL: Python 3.4 & 3.5 & 3.6) and Qt5 (currently Qt5 5.9), it has too old SIP to build python3-qt5.
    In my opinion, RHEL/CentOS is one of the hardest to get better/newer software. They have this concept of software collection (basically, their take on what Conda's environment or HPC's environment modules are doing), but it looks to me not as good as the later.

    (Been having a couple of tiny problems to get exactly that : python programs requiring slightly more recent versions of modules).

    Originally posted by the_scx View Post
    2.
    Sometimes the application requires just a single library in a higher version, which is already a non-trivial problem.
    Note that, though I'm not advocating to self-compile, the comment I've written about packaging also apply there :
    soname changes with ABI.

    So, in your example if libtiff 4.0.4 and 4.0.3 are compatible, you can safely overwrite one with the other. (and lock the package in your package management system to avoid a security upgrade accidentally over-writing and downgrading it).

    If 4.0.4 introduce a new incompatible ABI, the soname will change and the file will have a different name (like libtiff.so.4) and can safely be deployed alongside your distro's library (libtiff.so.3). Your distro's software will still pick the correct version when running.
    ( ^--- which is also exactly what a 3rd party repo would be doing behind the scene)




    Originally posted by the_scx View Post
    3.
    Many distributions are quite restrictive when it comes to audio-video codecs. Fedora leads the way here, unfortunately in the negative sense of the word. The same applies to EL.
    This is in my opinion the main push behind opensuse strongly developping it 3rd party distro integration (Packman is *the* answer for any audio/video answers).


    Originally posted by the_scx View Post
    Of course, we have 3rd party repositories (e.g. RPM Fusion, Negativo17) that provide ffmpeg, x264, x265, etc. The problem starts when you need to update one of these components. Then you have to rebuild all the packages that use it.
    Actually nope. Not at all. Codecs (libav, libx264, etc.) are typically the kind of libraries that change ABI extremely frequently (mostly adding new functionnality).
    Thus "updates" end-up being differently named packages each droping a different library with a different so-name.

    The problem is only correctly cleaning up, and avoind (or locking) the older that you compiled against, even if they show up in the "orphaned" or "unneeded" section of your package manager.

    Originally posted by the_scx View Post
    This is unfortunately a problem for unofficial repositories, developed in free time.
    In a small project like "home:dryak" on OBS, yes definitely.

    On a large scale project whit lots of ressource like packman : nope, they have a decent amount of community workforce to handle this.

    And again, regarding 3rd party repo, in that situation, you'll end up simply with having RPMs "libavfilter5", "libavfilter6" and "libavfilter7" all installed simultaneously because each one is a dependencies to a different software package.


    Originally posted by the_scx View Post
    Seriously, try to build the latest PiTiVi on EL7, then you'll know what I'm talking about.
    I'm on opensuse Tumbleweed, I already get PiTiVi version 0.999 for free in my base :-D

    Leave a comment:


  • Brisse
    replied
    Creak
    IIRC, GNOME already has plans for such GUI settings in gnome-control-center.

    Leave a comment:


  • Creak
    replied
    Originally posted by the_scx View Post
    As for flatpak, you have flatpak override.
    Well I thought flatpak override was a command line that needed to add each time you would run Steam, or to add to the .desktop file, but no, it's merely one command line to enter once and it's all fine afterwards!

    This makes Flatpak incredibly interesting because you would have the default permissions and then you could add your own -- like allowing, for you only, that Steam has access to another drive: https://github.com/flathub/com.valve...team-libraries

    I guess, later, flatpak will provide some kind of mobile-like interface so that it would request specific privileges only if you use them (like requesting bluetooth access only if you plug a bluetooth controller).

    I'm impressed

    Leave a comment:


  • Weasel
    replied
    Of course it wouldn't be Linux if it didn't have something insane in package distributions, like the sandboxing shit by default, which probably comes from mobile baby land.

    Leave a comment:


  • the_scx
    replied
    Originally posted by Creak View Post
    jo-erlend I searched for "flatpak devmod" but couldn't find any result about it. Could you be more specific, please?
    Devmode is a snap thing.

    Developer mode, or devmode in short, enables developers and users to install snaps without enforcing security policies.
    As for flatpak, you have flatpak override.

    Leave a comment:


  • Creak
    replied
    jo-erlend I searched for "flatpak devmod" but couldn't find any result about it. Could you be more specific, please?

    Leave a comment:


  • oyvind
    replied
    Originally posted by jo-erlend View Post

    Maybe use devmode for the time being? It's no more dangerous than using a PPA, that's for sure.
    Thanks for the tip, I'll try this.

    Leave a comment:


  • Creak
    replied
    Well, oyvind , I completely agree. I have the exact same problem with Steam. That's why I stick with the rpmfusion's package.

    I think an appropriate solution would be to allow specific access rights, per application. I like the sandboxing thing, but I think it needs to be a bit more customizable, on the user land.

    Leave a comment:


  • jo-erlend
    replied
    Originally posted by oyvind View Post

    like allowing a snap application full access to everything my own user can read or write on the system. I like the snaps I've tried so far, they appeal to me because of easy updates to recent versions and much less dependency hassles.
    Maybe use devmode for the time being? It's no more dangerous than using a PPA, that's for sure.

    Leave a comment:


  • oyvind
    replied
    Originally posted by jo-erlend View Post

    That's annoying indeed, but you can just bind mount the wanted folders, so it's not a total disaster, just a tad unfriendly to the average user
    Sure, I could do that, and have done that. But pulling other mounts into the /home namespace comes with its own set of problems. Apps reading from the bind mounted dirs will generate playlists using non-canonical /home/.. paths, backup system will suck up an extra TB of data if I forget to exclude, locate will give duplicates unless configured specifically to exclude, I have to mentally remember that the files are located under multiple prefixes, and use the /home prefix for some apps, app A invokes snap app B with path to a media file using the proper mount point fails, because app B is only able to read that file under the /home prefix, more complexity and config to maintain.

    Not worth it, I'll stick to PPAs or just the regular old apt versions, until this issue is somehow resolvable in a simple fashion, like allowing a snap application full access to everything my own user can read or write on the system. I like the snaps I've tried so far, they appeal to me because of easy updates to recent versions and much less dependency hassles. But this problem needs to get fixed for apps working with local files.

    Leave a comment:

Working...
X