Hi, I'm kinda new to Solus, been loving it but I want to use some XFCE apps instead of the Gnome ones, however they don't appear on Solus Software Center. I assume this works like Ubuntu where you have to manually add an external repository. How do I do it?

    Zenurik I assume this works like Ubuntu where you have to manually add an external repository. How do I do it?

    Your assumption isn't entirely correct. It'd still require someone to actually package XFCE under Solus using our build system and maintain it in their own separate repo (either by working out using ferryd, our repo manager, or having solbuild handle the eopkg index generation solely), with a continuously rebuilt set of packages against the official repository, as we (Solus) have no intentions on supporting XFCE and will make ABI changes under the assumption that it will be used against our offerings. We're perfectly happy with our current desktop offerings, and that includes applications (XFCE applications would be rejected per our Package Inclusion Policy under the "Stack Complexity" and "Value Add" regardless).

      JoshStrobl Aw :\ I'm not completely happy with Gnome software and wanted to change. I understand where you come from, though.

      How well would KDE apps perform in comparison? Would they take longer to load or be more resource intensive for using Qt?

      • just replied to this.

        Zenurik How well would KDE apps perform in comparison? Would they take longer to load or be more resource intensive for using Qt?

        Kde is very fast and responsive in Solus. Without details, it performs as well as Gnome and Mate. I'd say that Solus Kde is as fast as KaOS. These are only overall personal impressions, without performance analysis.

        Some quick figures, on 8yo laptop, HDD:

        1. Boot time (systemd-analyze)

          • Plasma: 19.872s
          • Mate: 22.371s
          • Gnome: 19.528s
        2. Memory used (free command)

          • Plasma: 969592
          • Mate: 468452
          • Gnome: 667320
        3. Memory used (KSysGuard | System Monitor)

          • Plasma: 0.84 GiB of 11.6 GiB
          • Mate: 846.6 MiB (7.1%) of 11.6 GiB
          • Gnome: 997,0 MiB (8.4%) of 11.6 GiB

          just Thanks for the in depth info on the DEs resource usage but I was actually asking about using "Kapps" on budgie and how well would they perform.

            Zenurik That's going to depend on a system-by-system basis, doubt you're going to see any actual applicable, reproducible benchmarks for KDE apps of all things. Just install and find out.

            Zenurik I assume this works like Ubuntu where you have to manually add an external repository. How do I do it?

            I have my own repository, in which, beside some custom packages, I host additional DEs such as Pantheon, XFCE4, Cinnamon and LXQt.
            Enabling my repository is pretty easy: REDACTED BY CORE TEAM, PUTS USERS IN LEGAL JEOPARDY.
            Installing a custom DE follows the same instructions as for any other component (in your case: eopkg it -c desktop.xfce).

            JoshStrobl It'd still require someone to actually package XFCE under Solus using our build system and maintain it in their own separate repo

            Well, it seems you don't require it anymore, then 🙂 .

              streambinder Well, it seems you don't require it anymore, then 🙂 .

              No offense but I kinda assumed it be done properly. You're not, like at all, and I do not want to put our users in legal jeopardy (especially with point #3 below) so refrain in the future from sharing that on our official mediums. I've edited your post to not disclose the URL.

              1. You're serving a bunch of eopkg binary files over GitHub per your doc. Not really proper.
              2. You're providing a bunch of eopkgs for packages we already have in the repository (e.g. appstream, awesomewm, etc.), which will cause conflicts and you're already introducing a bunch of issues with ABI providers with stuff like Mutter. Not proper either.
              3. You're violating copyrights, intellectual properties, EULAs, licenses, etc. by shipping software like Megasync when it is clearly not redistributable, which is why it's not in our repo. God knows what other stuff you're shipping here in clear violation of software licenses.

                streambinder wow you really made all those packages. I have my own repository with 4 or 5 packages for my own need but you really took this seriously 😮
                I'm gonna try some packages, but of course, not on my main rig, cause I don't want to break something.

                Thanks a lot

                  JoshStrobl No offense but I kinda assumed it be done properly. You're not, like at all, and I do not want to put our users in legal jeopardy (especially with point #3 below) so refrain in the future from sharing that on our official mediums. I've edited your post to not disclose the URL.

                  Sounds like you're taking it way too seriously.

                  You're serving a bunch of eopkg binary files over GitHub per your doc. Not really proper.

                  Who decided what's the proper way of distributing binaries?
                  I don't just disagree with you, but I'd also encourage people to do stuff like that, finding ploys to make something work flawlessly even without spending a penny for it.

                  You're providing a bunch of eopkgs for packages we already have in the repository (e.g. appstream, awesomewm, etc.), which will cause conflicts and you're already introducing a bunch of issues with ABI providers with stuff like Mutter. Not proper either.

                  Really? Lot of stuff you distribute isn't built the way it's needed for lot of packages. I don't criticize this, additional stuff is not needed if you don't need to build other package which are in the need of it. On the other hand, I criticize the way you're absolutely kicking out everyone else who's actually trying to make your distribution even bigger. Keep on doing and you'll be the only developers to carry on the whole wheel, with a community made of only enthusiasts which don't even know what Linux is.

                  You're violating copyrights, intellectual properties, EULAs, licenses, etc. by shipping software like Megasync when it is clearly not redistributable, which is why it's not in our repo. God knows what other stuff you're shipping here in clear violation of software licenses.

                  You got your point, here.
                  How about hey, you can not do that, suggest you to drop this package? . Obviously not, too collaborative.
                  There was an issue opened by @DataDrake (https://github.com/streambinder/ashtray/issues/4) which actually pointed that out to me and that's the reason why I'm in contact with MEGA to get the thing sorted out.

                    streambinder Really? Lot of stuff you distribute isn't built the way it's needed for lot of packages.

                    Got any examples? And if that's the case, file an issue at https://dev.getsol.us.

                    streambinder On the other hand, I criticize the way you're absolutely kicking out everyone else who's actually trying to make your distribution even bigger.

                    Maybe because when a user who may or may not entirely know what they're doing uses a package from a third-party repository and it breaks things for them, they're going to come here blaming Solus for breaking things. This both increases support burden (even if it's just telling them not to use broken third-party packages) and makes Solus look bad.

                    streambinder Sounds like you're taking it way too seriously.

                    Yes, I take the security and stability of our user's systems seriously, as well as ensuring they're not being put in legal jeopardy. Like many, I use Solus on production systems, where the expectation is the software being delivered is being as well tested and stable as possible, with QA by the developers of the project. You're introducing packages which present possible ABI conflicts, which will result in breakages on user systems, that's not acceptable to me.

                    streambinder Who decided what's the proper way of distributing binaries?

                    We hold user-provided repositories to the same standards as our own repository.

                    streambinder I don't just disagree with you, but I'd also encourage people to do stuff like that, finding ploys to make something work flawlessly even without spending a penny for it.

                    Finding "ploys" very much sounds like to me like "find ways to potentially skirt or violate copyrights, intellectual properties, software licenses, EULAs / ToSes without bringing attention to oneself", which is absolutely not something I condone.

                    streambinder Really? Lot of stuff you distribute isn't built the way it's needed for lot of packages.

                    They're built with specific usecases in mind and we don't enable configuration options excessively.

                    streambinder On the other hand, I criticize the way you're absolutely kicking out everyone else who's actually trying to make your distribution even bigger.

                    On the contrary, we've brought on board more global contributors, have more regular contributors, have more people empowered to contribute and engage. What I do care about is ensuring that everybody is held to high standards.

                    streambinder Keep on doing and you'll be the only developers to carry on the whole wheel, with a community made of only enthusiasts which don't even know what Linux is.

                    That argument would maybe carry more weight if we weren't working on tooling like ypkg3, improved ferryd, etc. to make it easier to onboard more developers. I would like however to mention that we do not target the Linux community as our general userbase, that's 2% of the global computing market at best, so having people use Solus and not know what Linux is would be an honor. Because they shouldn't need to know the kernel they're running, the init system, various libraries, etc.

                      JoshStrobl They're built with specific usecases in mind and we don't enable configuration options excessively.

                      We also are usually pretty responsive to requests to enable things if there's good reason.

                        streambinder How about hey, you can not do that, suggest you to drop this package? . Obviously not, too collaborative.
                        There was an issue opened by @DataDrake (https://github.com/streambinder/ashtray/issues/4) which actually pointed that out to me and that's the reason why I'm in contact with MEGA to get the thing sorted out.

                        Building on "ploys", your way of getting it "sorted" was repackaging their deb file, which is still putting it into a binary and redistributing their files. This is still in violation of their Code Review License, not to mention their Terms. Their Code Review License is for review-purposes only and is non-transferable, and their Terms clearly state that you shall not "resell or otherwise supply our services to anyone else without our prior written consent", consent which you obviously didn't have, and services including the redistribution of their software.

                          JoshStrobl Yes, I take the security and stability of our user's systems seriously, as well as ensuring they're not being put in legal jeopardy. Like many, I use Solus on production systems, where the expectation is the software being delivered is being as well tested and stable as possible, with QA by the developers of the project. You're introducing packages which present possible ABI conflicts, which will result in breakages on user systems, that's not acceptable to me.

                          It's not acceptable to me neither, that's why I'd expect you to be collaborative and give meaningful hints on how things could be improved. And that's definitely not discouraging people from using others works case.

                          JoshStrobl We hold user-provided repositories to the same standards as our own repository.

                          Which means costs. I agree with the fact that standards should be followed, but if the standard is way to strict and does not allow further implementations, well, it just cannot represent a standard, but a single implementation.

                          JoshStrobl Finding "ploys" very much sounds like to me like "find ways to potentially skirt or violate copyrights, intellectual properties, software licenses, EULAs / ToSes without bringing attention to oneself", which is absolutely not something I condone.

                          Really? You really think my work is relying on finding way to fool the system ? I my opinion it's just pushing people and developers to find ways to invent some solutions, as a chance to learn and practice with something new. That's the same thing that led me to host a eopkg repository without even get any help from you. And I don't mean to criticize here, it's just a matter of fact.

                          JoshStrobl They're built with specific usecases in mind and we don't enable configuration options excessively.

                          Exactly. Then read my next answer to @DataDrake.

                          JoshStrobl On the contrary, we've brought on board more global contributors, have more regular contributors, have more people empowered to contribute and engage. What I do care about is ensuring that everybody is held to high standards.

                          I'm sure of that and I really hope you handle things differently there, then.

                          JoshStrobl That argument would maybe carry more weight if we weren't working on tooling like ypkg3, improved ferryd, etc. to make it easier to onboard more developers. I would like however to mention that we do not target the Linux community as our general userbase, that's 2% of the global computing market at best, so having people use Solus and not know what Linux is would be an honor. Because they shouldn't need to know the kernel they're running, the init system, various libraries, etc.

                          Please, romanticism apart. That's exactly the reason why I chose Solus. Everyone here is expected to know what Linux - cause otherwise they'd be sticking to Windows/MacOS -, not everyone to know how it's done internally, though. What I mean? Maybe it's just my case, but you're not anyhow encouraging me to help you in any way getting Solus better. And that's basically what's relying on a community is for, right?

                          DataDrake We also are usually pretty responsive to requests to enable things if there's good reason.

                          Exactly, again. Is is needed for Pantheon dependencies a good reasoning, if everytime Pantheon word pops out you all get out of your mind?

                          JoshStrobl Building on "ploys", your way of getting it "sorted" was repackaging their deb file, which is still putting it into a binary and redistributing their files. This is still in violation of their Code Review License, not to mention their Terms. Their Code Review License is for review-purposes only and is non-transferable, and their Terms clearly state that you shall not "resell or otherwise supply our services to anyone else without our prior written consent", consent which you obviously didn't have, and services including the redistribution of their software.

                          Dude, seriously. Ploy was about making redirections over a virtualhost to make traffic be generated just over GitHub infrastructure, relying on their Releases functionality.
                          Speaking of MEGAsync case, which is the only one which seems to be the only package not compliant to the license, I thank you for the advise. Will proceed on removing that one from the repository if there's no way to get it. That's a way to help.

                          v3l0ct Awkward

                          Your technical skills impressed me.

                            streambinder Exactly, again. Is is needed for Pantheon dependencies a good reasoning, if everytime Pantheon word pops out you all get out of your mind?

                            That's not good reasoning. We don't wish to support Pantheon and enabling features so you can defeats the purpose of curation. I let you get away with it because I thought you were just hosting these packages for yourself. Doing it for others is no different than a Community repo which we do not want.

                            streambinder Really? You really think my work is relying on finding way to fool the system ?

                            They were your words, not mind.

                            streambinder I my opinion it's just pushing people and developers to find ways to invent some solutions, as a chance to learn and practice with something new.

                            "Inventing" some solutions sounds exactly like circumvention. Like your GitHub projct which circumvents / violates copyright law for music by downloading them even when you don't own it.

                            streambinder hat's the same thing that led me to host a eopkg repository without even get any help from you.

                            And clearly by doing so, it has resulted it being done to lower standards than expect that could or will result in user breakages and the other items I've addressed multiple times now.

                            streambinder Please, romanticism apart.

                            Nothing is being romanticized and I don't really appreciate the snark. We have realistic expectations for Solus and what we want our market to be.

                            streambinder Everyone here is expected to know what Linux

                            No, they're not, at all. I guarantee you there are people that are using Solus which have absolutely no idea what Linux is.

                            streambinder but you're not anyhow encouraging me to help you in any way getting Solus better

                            You initiated the conversation with snark and I simply researched your current setup to see how you were doing it, which is what lead me to the discovery that it was not at all via proper processes, as well as the other issues I mentioned.

                            streambinder Is is needed for Pantheon dependencies a good reasoning, if everytime Pantheon word pops out you all get out of your mind?

                            There is a difference between enabling features and functionality in libraries which exist in our repository for various other reasons / stacks than accepting libraries for desktop environments which are not part of any stack and would not pass our inclusion policy.

                            streambinder Your technical skills impressed me.

                            Okay, now you're just being rude. Locking thread since you can't seem to be constructive and only presenting attitude.